What EC2 Capacity Reservation Attributes Must Match?

To utilize an existing Amazon EC2 On-Demand Capacity Reservation when launching a new instance, four core attributes must match exactly: the instance type, the operating system platform, the Availability Zone, and the tenancy. Additionally, if the Capacity Reservation is configured as targeted rather than open, the instance launch request must explicitly specify the reservation ID or target a Capacity Reservation group. When all required criteria align and sufficient capacity is available, Amazon EC2 automatically applies the reservation to the new instance, ensuring compute availability and preventing duplicate billing for unused reserved capacity.

The Four Required Matching Attributes

When you create an On-Demand Capacity Reservation, AWS sets aside specific hardware resources in a chosen data center. For a newly launched instance to consume those exact resources, its launch parameters must match the reservation parameters without exception.

1. Instance Type

The instance type defines the hardware family, generation, and size of the virtual machine, such as m5.xlarge or c6i.2xlarge. Unlike Regional Reserved Instances or Compute Savings Plans, which offer instance size flexibility within the same family, On-Demand Capacity Reservations require an exact instance type match. For example, a reservation for one c5.2xlarge instance cannot be consumed by launching two c5.xlarge instances.

2. Platform (Operating System)

The software platform specified in the Amazon Machine Image (AMI) used to launch the instance must match the platform configured on the Capacity Reservation. AWS categorizes platforms into specific billing and licensing tiers, including:

  • Linux/UNIX
  • Red Hat Enterprise Linux (RHEL)
  • SUSE Linux
  • Windows
  • Windows with SQL Server (Standard, Web, or Enterprise)
  • Linux with SQL Server (Standard, Web, or Enterprise)

If your Capacity Reservation is configured for standard Linux/UNIX, launching an instance with a Red Hat Enterprise Linux AMI will not match the reservation, even if the underlying hardware requirements are identical.

3. Availability Zone

Capacity Reservations are zonal resources rather than regional ones. You must launch the instance into the exact Availability Zone where the Capacity Reservation resides. To prevent discrepancies across different AWS accounts—where Availability Zone names like us-east-1a might map to different physical locations—it is best practice to verify the Availability Zone ID, such as use1-az1.

4. Tenancy

The hardware isolation level of the instance must align with the reservation. Capacity Reservations support two tenancy options:

  • Default (default): The instance runs on shared hardware alongside instances from other AWS accounts.
  • Dedicated (dedicated): The instance runs on single-tenant hardware dedicated to your AWS account.

Note that On-Demand Capacity Reservations are not supported on Dedicated Hosts (host tenancy), which use a separate host-level reservation model.

Matching Criteria: Open vs. Targeted Reservations

In addition to the four hardware and software attributes, every Capacity Reservation has an instance eligibility setting that dictates how instances match to it.

Open Capacity Reservations

When a Capacity Reservation is set to open, any new instance launched in your account (or shared with your account via AWS Resource Access Manager) that matches the four core attributes will automatically consume the reserved capacity. This happens provided the instance launch setting has its Capacity Reservation preference set to open (which is the default for EC2 launches).

Targeted Capacity Reservations

When a Capacity Reservation is set to targeted, matching the four attributes is necessary but not sufficient. An instance with default launch settings will ignore a targeted reservation and launch into the public On-Demand pool instead. To consume a targeted reservation, the instance launch request must explicitly reference either the specific Capacity Reservation ARN/ID or a Capacity Reservation resource group containing that reservation. This configuration is ideal for reserving capacity strictly for mission-critical workloads while preventing non-critical workloads in the same Availability Zone from accidentally consuming it.

Placement Group Considerations

By default, open Capacity Reservations do not restrict placement groups. However, if you configure a Capacity Reservation to be tied to a specific cluster placement group, only instances launched into that exact cluster placement group can use the reserved capacity. Conversely, if an instance is launched into a cluster placement group, it will only match an open Capacity Reservation that either specifies the same placement group or has no placement group restriction and happens to have hardware aligned with the group's topology.