When to Use Targeted vs Open EC2 Capacity Reservations?

A team should use a targeted Capacity Reservation in Amazon EC2 when specific, critical workloads require guaranteed compute capacity and must be protected from other instances launching into that reserved pool. While open Capacity Reservations automatically fulfill any matching instance launch in an Availability Zone, targeted reservations require explicit assignment at launch time. This distinction allows engineering and cloud operations teams to isolate mission-critical infrastructure, enforce strict budget boundaries, and prevent accidental consumption of reserved capacity by non-essential services.

Understanding Amazon EC2 Capacity Reservations

Amazon EC2 On-Demand Capacity Reservations enable organizations to reserve compute capacity for Amazon EC2 instances in a specific Availability Zone for any duration. When creating a reservation, you specify the instance type, platform, tenancy, and Availability Zone. AWS holds that capacity for your account as long as the reservation remains active, ensuring you can launch instances whenever needed, even during periods of high regional demand or hardware constraints.

Capacity Reservations offer two distinct instance eligibility options: open and targeted. Both options reserve the exact same underlying hardware and incur identical billing rates, where you pay for the total reserved capacity \(C_{\text{reserved}}\) regardless of whether instances are actively running. If \(N_{\text{running}}\) represents the number of running instances matching the reservation attributes, the unused billed capacity \(C_{\text{unused}}\) is defined as:

\[C_{\text{unused}} = C_{\text{reserved}} - N_{\text{running}}\]

The difference between open and targeted reservations lies entirely in how new or existing EC2 instances consume \(C_{\text{reserved}}\).

How Open Capacity Reservations Work

An open Capacity Reservation is the default configuration when reserving capacity in Amazon EC2. Any instance launched in the same AWS account—or shared accounts via AWS Resource Access Manager (AWS RAM)—that matches the reservation attributes (Availability Zone, instance type, platform, and tenancy) automatically runs in the open Capacity Reservation.

Open reservations require zero modifications to existing launch templates, Auto Scaling configurations, or deployment scripts. If a developer launches a matching instance manually via the AWS Management Console or through an automated pipeline without specifying a reservation setting, EC2 automatically places the instance into the open reservation pool until the capacity is full.

How Targeted Capacity Reservations Work

A targeted Capacity Reservation restricts capacity access exclusively to instances that explicitly target that specific reservation ID or a Capacity Reservation group at launch. If an instance launches with matching attributes (same Availability Zone, instance type, and platform) but does not explicitly specify the targeted Capacity Reservation ID, it will not consume the reserved capacity. Instead, it launches into the standard public On-Demand pool.

Furthermore, you can configure instances to launch only if they can be placed into a targeted reservation, preventing workloads from accidentally overflowing into unreserved On-Demand capacity.

Key Scenarios for Choosing Targeted Capacity Reservations

1. Protecting Mission-Critical Workloads in Shared Accounts

In many cloud environments, multiple applications, microservices, and teams share the same AWS account and Availability Zones. They also commonly standardize on popular instance families, such as m6i.xlarge or c7g.2xlarge.

If you create an open Capacity Reservation for m6i.xlarge to guarantee capacity for a tier-1 payment processing service, a developer running an ad-hoc testing cluster or a background batch job using the same m6i.xlarge instance type in that Availability Zone can inadvertently consume your reserved capacity. When the payment processing service scales out, the reserved capacity is already exhausted, potentially resulting in an InsufficientInstanceCapacity error. Targeted Capacity Reservations eliminate this risk by ensuring only the payment service—configured with the reservation ID in its launch template—can claim those reserved instances.

2. Disaster Recovery and High-Availability Failover

Disaster recovery (DR) architectures often rely on pilot-light or warm-standby strategies where core capacity is reserved in a secondary Availability Zone or region, waiting to scale up immediately during an outage.

Using a targeted Capacity Reservation ensures that your failover capacity remains strictly untouched during normal day-to-day operations. When a failover event triggers, your automated recovery runbooks or Auto Scaling groups target the specific reservation ID, guaranteeing that the exact compute footprint required for recovery is immediately available.

3. Strict Regulatory, Licensing, or Compliance Placement

Workloads subject to strict licensing agreements (such as bring-your-own-license software bound to specific hardware footprints) or regulatory frameworks often require deterministic infrastructure placement. By pairing targeted Capacity Reservations with specific launch templates and IAM policies, administrators can enforce that sensitive workloads only run inside designated, pre-allocated reservations, and conversely, that unapproved workloads cannot enter those reservations.

4. Multi-Account Sharing and Departmental Chargebacks

When using AWS Resource Access Manager (AWS RAM) to share Capacity Reservations across an AWS Organization, an open reservation allows any participating account within the organization to consume the capacity on a first-come, first-served basis.

If a central platform team purchases capacity specifically for two different business units, targeted reservations allow the platform team to allocate distinct reservation IDs or Capacity Reservation groups to each department. This ensures one business unit cannot starve another of its allocated and budgeted compute resources.

5. Specialized Hardware and GPU Allocation

High-demand instance families—such as GPU-accelerated instances (p4d, p5, g5) used for machine learning training and inference—frequently experience capacity constraints. When an organization secures a Capacity Reservation for accelerated computing, different ML teams often compete for those nodes. By using targeted Capacity Reservations, MLOps platforms can orchestrate job queues and explicitly assign specific training jobs to specific reservations, preventing lower-priority experiments from monopolizing scarce GPU instances.

Grouping Targeted Reservations for Flexibility

A common concern with targeted Capacity Reservations is the operational overhead of hardcoding specific Capacity Reservation IDs into launch templates or Auto Scaling groups. To solve this, AWS provides Capacity Reservation groups via AWS Resource Groups.

Teams can add multiple targeted Capacity Reservations to a logical group and configure their EC2 launch templates to target the group ARN rather than an individual reservation ID. This approach preserves the strict access controls of targeted reservations while allowing cloud administrators to add, modify, or replace underlying reservations without updating application deployment templates.

Summary of Selection Criteria

Enforcing Governance with IAM

To maximize the effectiveness of targeted Capacity Reservations, teams should pair them with AWS Identity and Access Management (IAM) condition keys. Specifically, using the ec2:CapacityReservationId condition key in IAM policies allows security engineers to control which IAM roles or users are permitted to launch instances into a specific targeted reservation. Combining targeted reservations with IAM policies provides a complete governance boundary, guaranteeing that reserved compute capacity is always available for the exact workload it was provisioned to support.