This chapter covers On-Demand Capacity Reservations (ODCRs), a powerful feature for guaranteeing EC2 capacity in a specific Availability Zone. For the SAA-C03 exam, understanding ODCRs is crucial for questions about ensuring capacity for critical workloads, especially during major events or migrations. While not a primary topic, it appears in roughly 5-10% of exam questions, often as a distractor or correct answer when the scenario demands capacity assurance without long-term commitments. This chapter will explain what ODCRs are, how they work, their pricing, and how they differ from other capacity options like Reserved Instances and Savings Plans.
Jump to a section
Imagine you are organizing a critical business trip for your team to a major conference. You know you need exactly 10 seats on a specific flight, but you don't want to buy all 10 tickets in advance because team members might drop out. You can buy a flexible ticket that guarantees 10 seats are held for you, but you only pay for the seats you actually use. This is like an On-Demand Capacity Reservation. The airline (AWS) reserves physical seats (EC2 capacity) on the plane (in a specific Availability Zone) for you. You are not charged for the reservation itself, only for the seats you occupy (when you launch instances into the reservation). If you don't use a seat, it remains empty but available for you at a moment's notice. Unlike a standard ticket (On-Demand instance), you are guaranteed that seat even if the flight is overbooked. However, you cannot sell that empty seat to another passenger (you cannot share the reservation across accounts unless using a Capacity Reservation in a resource share via AWS RAM). This mechanism ensures that when your team finally confirms, you have capacity exactly where you need it, without paying a premium for an entire block of prepaid tickets (like with Regional Reserved Instances or Savings Plans).
What is an On-Demand Capacity Reservation?
An On-Demand Capacity Reservation (ODCR) is a feature that allows you to reserve compute capacity for EC2 instances in a specific Availability Zone for any duration. Unlike Reserved Instances (RIs) or Savings Plans (SPs), which provide a billing discount but no capacity guarantee, an ODCR guarantees that when you need to launch instances, the capacity will be available. You do not pay any upfront or recurring fee for the reservation itself; you only pay for the instances you actually run in the reservation.
Why On-Demand Capacity Reservations Exist
ODCRs address a fundamental problem: AWS is a shared infrastructure. During peak times (like Black Friday for e-commerce, or a major product launch), AWS may not have enough capacity in a specific Availability Zone to launch your desired instance type. This is rare but can be catastrophic for time-sensitive workloads. ODCRs give you a capacity guarantee without requiring you to commit to a 1- or 3-year term like with RIs.
How It Works Internally
When you create an ODCR, you specify:
Instance type (e.g., m5.large)
Platform (e.g., Linux/UNIX, Windows, Red Hat, SUSE)
Availability Zone (e.g., us-east-1a)
Number of instances to reserve (e.g., 10)
Tenancy (shared or dedicated)
(Optional) Placement group
AWS then sets aside that capacity in that AZ. This capacity is not shared with other customers. You can launch instances into this reservation at any time. The reservation remains active until you explicitly cancel it. There is no minimum duration; you can cancel it at any time.
Key Components and Defaults
Instance Type: Must be exact, e.g., t3.medium. You cannot reserve a 'family' like t3. You can only reserve specific sizes.
Availability Zone: Must be specific, e.g., us-east-1a. You cannot reserve across multiple AZs. To cover multiple AZs, you must create separate reservations.
Platform: Determines the operating system. Important for pricing because Windows instances cost more.
Tenancy: Default is 'default' (shared tenancy). You can also choose 'dedicated' but that increases cost.
Placement Group: Optional. If you specify a placement group, the capacity is reserved within that group.
Capacity Reservation ID: A unique identifier like cr-0123456789abcdef0.
State: A reservation can be in 'active', 'pending', 'cancelled', 'expired', or 'failed'.
End Date: You can optionally set an end date. If not set, the reservation runs indefinitely until cancelled.
Instance Eligibility: Instances launched into the reservation must exactly match the specified attributes. If you try to launch a different instance type, it will not use the reservation.
Pricing Model
This is a critical exam point: You are not charged for the reservation itself. You only pay for the instances you run in the reservation. The instances are billed at On-Demand rates. However, if you have a Reserved Instance or Savings Plan, the billing discount can apply to instances launched into the reservation, but the capacity guarantee comes from the ODCR, not the RI/SP.
Interaction with Related Technologies
Reserved Instances: RIs provide a billing discount but do not guarantee capacity. ODCRs guarantee capacity but do not provide a discount. They complement each other: you can combine an RI (for discount) with an ODCR (for capacity guarantee).
Savings Plans: Similar to RIs, SPs provide a discount but no capacity guarantee. You can use SPs with ODCRs.
Capacity Blocks: These are for future-dated reservations for GPU instances (like p4d) for ML workloads. They are different from ODCRs.
Regional vs. Zonal Reservations: RIs can be regional (discount applies to any AZ in the region) or zonal (discount applies to a specific AZ). ODCRs are always zonal.
Capacity Reservations for EC2 Fleet: When using EC2 Fleet, you can specify a Capacity Reservation to launch instances into.
Creating and Managing ODCRs
You can create ODCRs via AWS Management Console, AWS CLI, or SDK.
CLI Example:
aws ec2 create-capacity-reservation \
--instance-type m5.large \
--instance-platform Linux/UNIX \
--availability-zone us-east-1a \
--instance-count 10Verification:
aws ec2 describe-capacity-reservations --capacity-reservation-ids cr-1234567890abcdef0Launching an instance into a reservation: When launching an instance, you can specify the Capacity Reservation ID. If you don't, the instance will launch into On-Demand capacity, not the reservation.
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--instance-type m5.large \
--key-name MyKeyPair \
--subnet-id subnet-12345678 \
--capacity-reservation-id cr-1234567890abcdef0Capacity Reservation Groups (CRGs)
You can group multiple ODCRs into a Capacity Reservation Group. This is useful when you need a set of instances with different types or across multiple AZs. EC2 Fleet can then launch instances into any reservation in the group.
Sharing Capacity Reservations
By default, ODCRs are private to your account. You can share them with other AWS accounts using AWS Resource Access Manager (RAM). This is useful for shared services environments.
Monitoring and Notifications
You can monitor the utilization of your ODCRs via CloudWatch metrics:
- AvailableInstanceCount - number of instances currently available in the reservation.
- UsedInstanceCount - number of instances currently using the reservation.
- TotalInstanceCount - total number of instances reserved.
You can also set up EventBridge events for state changes.
Limits and Quotas
By default, you can have up to 100 active ODCRs per region. You can request a limit increase. Each reservation can have up to 1000 instances (default limit).
Use Cases
Critical Workloads: Ensures capacity for mission-critical applications during peak times.
Disaster Recovery: Guarantees capacity for failover instances.
Migrations: Reserves capacity in the target AZ before migrating workloads.
Testing: Ensures capacity for test environments that must run at specific times.
Common Pitfalls
Forgetting to specify the capacity reservation ID when launching instances: If you don't specify, the instance will not use the reservation, and you might face capacity issues.
Confusing ODCRs with Dedicated Hosts: Dedicated Hosts give you a physical server, while ODCRs guarantee capacity on shared hardware.
Assuming ODCRs provide a discount: They do not. You pay On-Demand rates for instances launched into them.
Not cancelling unused reservations: While you don't pay for the reservation, unused capacity is wasted, and you might hit service limits.
Step-by-Step: Creating and Using an ODCR
Determine the instance type, platform, AZ, and count.
Create the reservation using CLI or console.
Verify the reservation is active.
Launch instances into the reservation by specifying the reservation ID.
Monitor usage.
Cancel the reservation when no longer needed.
Exam Tips
Remember that ODCRs are zonal, not regional.
They do not provide a discount.
They can be combined with RIs/SPs for discount + capacity guarantee.
You can share them via AWS RAM.
They are not automatically used; you must explicitly launch into them.
Determine Instance Requirements
First, you need to know exactly what EC2 capacity you need: instance type (e.g., m5.xlarge), platform (Linux/Windows), tenancy, and the specific Availability Zone (e.g., us-east-1a). The instance type must be exact; wildcards are not allowed. If you need multiple instance types, you must create separate reservations for each. The platform affects pricing; Windows instances cost more per hour. Tenancy can be 'default' (shared) or 'dedicated' (physical isolation). You also decide the number of instances to reserve. This step is critical because you cannot change the instance type or AZ after creation without cancelling and recreating.
Create the Capacity Reservation
Using the AWS Management Console, AWS CLI, or SDK, you create the capacity reservation. For example, using CLI: `aws ec2 create-capacity-reservation --instance-type m5.xlarge --instance-platform Linux/UNIX --availability-zone us-east-1a --instance-count 5`. AWS then checks if it can reserve that capacity. If successful, the reservation enters 'active' state. If not, it may be 'pending' or 'failed'. You can optionally set an end date; if not set, it runs indefinitely. You can also add tags for management.
Verify Reservation is Active
After creation, you should verify the reservation state using `aws ec2 describe-capacity-reservations --capacity-reservation-ids cr-xxxxx`. Look for 'State: active'. The output also shows 'AvailableInstanceCount' (e.g., 5) and 'UsedInstanceCount' (0). If the state is 'pending', AWS is still allocating capacity; it should become active quickly. If 'failed', you may need to try a different AZ or instance type. This step ensures that your capacity is indeed reserved before you rely on it.
Launch Instances into the Reservation
When launching EC2 instances, you must explicitly specify the Capacity Reservation ID. In the console, under 'Advanced details', select 'Launch into a Capacity Reservation' and choose the reservation. In CLI, add `--capacity-reservation-id cr-xxxxx`. If you do not specify, the instance will launch as regular On-Demand and will not use the reserved capacity. Each instance launched that matches the reservation's attributes will consume one unit of the reserved count. The instance is billed at On-Demand rates, but you have the guarantee that capacity exists.
Monitor Utilization and Cancel
You can monitor the reservation's usage via CloudWatch metrics (AvailableInstanceCount, UsedInstanceCount). If you no longer need the capacity, you can cancel the reservation using `aws ec2 cancel-capacity-reservation --capacity-reservation-id cr-xxxxx`. Cancelling does not affect running instances; they continue to run but are no longer associated with the reservation. The reservation's state changes to 'cancelled'. You can also set an end date during creation to automatically cancel at a future time. Remember that you are not charged for the reservation itself, only for instances run.
Enterprise Scenario 1: E-commerce Black Friday
A large e-commerce company expects a 10x traffic spike on Black Friday. They use a fleet of m5.large instances for their web tier. To ensure capacity, they create ODCRs for 200 m5.large instances in three AZs (us-east-1a, us-east-1b, us-east-1c). They set the end date to the day after Black Friday. They also have Reserved Instances for the baseline capacity (100 instances per AZ) to save costs. On Black Friday, they launch 200 instances into each reservation. The ODCRs guarantee capacity even if AWS is under heavy demand. After the event, they terminate the instances and the reservations auto-cancel. Common misconfiguration: not specifying the reservation ID in the launch template, causing instances to launch outside the reservation and potentially fail due to insufficient capacity.
Enterprise Scenario 2: Disaster Recovery Failover
A financial services company uses a warm standby DR strategy. They keep a small number of instances running in the DR region, but need to scale up quickly during a failover. They create ODCRs for 50 c5.2xlarge instances in the DR AZ. They do not run any instances in the reservation normally (to save cost). When a disaster is declared, they launch 50 instances into the reservation, knowing capacity is guaranteed. They also have Savings Plans to cover the compute cost. The risk: if they forget to cancel the reservation after the failover test, they might block capacity for others, but since they don't pay for the reservation, the only downside is hitting service limits.
Enterprise Scenario 3: Migration from On-Premises
A company is migrating a critical database from on-premises to AWS. They need to ensure capacity in the target AZ for a limited time. They create an ODCR for 4 r5.2xlarge instances in us-west-2a for one month. They then launch the database instances into the reservation. The migration proceeds smoothly. After the migration, they cancel the reservation. Common mistake: creating a regional reservation (not possible for ODCRs) or confusing ODCRs with Dedicated Hosts.
What SAA-C03 Tests
On-Demand Capacity Reservations fall under Domain 4: Cost-Optimized Architectures, Objective 4.1: 'Design cost-optimized compute solutions.' The exam tests your ability to choose the right capacity option based on requirements for capacity guarantee, discount, and flexibility. ODCRs are often the correct answer when the scenario explicitly requires capacity assurance in a specific AZ without a long-term commitment. They are also a distractor when the scenario asks for a discount.
Common Wrong Answers
Reserved Instances: Candidates often choose RIs because they provide a discount. But RIs do not guarantee capacity. If the question says 'guarantee capacity' or 'ensure instances launch during a flash sale', RIs are wrong.
Savings Plans: Same as RIs — discount only, no capacity guarantee.
Dedicated Hosts: Candidates think dedicated hosts provide capacity guarantee. While they do provide physical isolation, they are for licensing or compliance, not for guaranteeing a specific number of instances. Also, Dedicated Hosts are more expensive.
EC2 Fleet: Candidates might think Fleet guarantees capacity. Fleet can launch across multiple purchasing options, but it does not reserve capacity ahead of time.
Specific Numbers and Terms
'On-Demand Capacity Reservation' is the exact term.
'Capacity Reservation ID' (cr-xxxxxxxx).
'AvailableInstanceCount' and 'UsedInstanceCount' are CloudWatch metrics.
Default limit: 100 active reservations per region per account.
Maximum instances per reservation: 1000 (default).
Pricing: Pay only for instances run, at On-Demand rates.
Zonal only (not regional).
Can be shared via AWS RAM.
Edge Cases and Exceptions
ODCRs cannot be used with Spot Instances. Spot Instances are not supported.
If you cancel a reservation, running instances are not affected. They continue running but are no longer associated with the reservation.
You cannot modify a reservation after creation (except for tags and end date). To change instance type or count, you must cancel and recreate.
Reservations are not automatically used. You must explicitly launch into them.
If you set an end date, the reservation is cancelled automatically. But instances continue running.
How to Eliminate Wrong Answers
If the question says 'capacity guarantee' or 'ensure instances launch', eliminate any option that only provides a discount (RIs, SPs). If the question mentions 'specific Availability Zone', eliminate regional options. If the question says 'no upfront payment' or 'pay only for what you use', ODCRs fit. If the question mentions 'long-term commitment' (1-3 years), ODCRs are not the answer because they have no minimum term.
On-Demand Capacity Reservations guarantee EC2 capacity in a specific Availability Zone.
You are not charged for the reservation; you pay only for instances run at On-Demand rates.
ODCRs are zonal, not regional. To cover multiple AZs, create separate reservations.
You must explicitly launch instances into the reservation by specifying the Capacity Reservation ID.
ODCRs can be combined with Reserved Instances or Savings Plans for both discount and capacity guarantee.
Default limit: 100 active reservations per region, up to 1000 instances per reservation.
ODCRs can be shared across accounts using AWS Resource Access Manager.
Cancel a reservation at any time; running instances are unaffected.
Not suitable for Spot Instances; only On-Demand and Dedicated Instances.
Common exam trap: Choosing Reserved Instances when capacity guarantee is needed.
These come up on the exam all the time. Here's how to tell them apart.
On-Demand Capacity Reservation
Guarantees capacity in a specific AZ
No upfront or recurring fee; pay only for instances run
No term commitment; can cancel anytime
Instances billed at On-Demand rates
Zonal only, not regional
Reserved Instance (Standard)
Provides a billing discount (up to 72%) but no capacity guarantee
Requires 1- or 3-year term commitment
Can be regional or zonal
Discount applies regardless of instance count
Not suitable for ensuring capacity during spikes
Mistake
On-Demand Capacity Reservations provide a discount on instance pricing.
Correct
ODCRs do not provide any discount. Instances launched into the reservation are billed at standard On-Demand rates. The benefit is capacity guarantee, not cost savings.
Mistake
You are charged for the reservation even if you don't run any instances.
Correct
There is no charge for the reservation itself. You only pay for the instances you actually run in the reservation. Unused reserved capacity costs nothing.
Mistake
Capacity Reservations are regional and cover all Availability Zones in a region.
Correct
ODCRs are zonal. You must specify a single Availability Zone. To cover multiple AZs, you need separate reservations for each AZ.
Mistake
Once you create a Capacity Reservation, instances automatically launch into it.
Correct
No. You must explicitly specify the Capacity Reservation ID when launching instances. Otherwise, instances launch as regular On-Demand instances and do not use the reservation.
Mistake
You can modify a Capacity Reservation to change the instance type or count after creation.
Correct
You cannot modify the instance type, platform, tenancy, or AZ after creation. You can only modify tags and the end date. To change other attributes, you must cancel and recreate the reservation.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An On-Demand Capacity Reservation (ODCR) is a feature that lets you reserve compute capacity for EC2 instances in a specific Availability Zone for any duration. It guarantees that capacity will be available when you launch instances, without requiring a long-term commitment. You pay only for the instances you run, at standard On-Demand rates. It is ideal for ensuring capacity for critical workloads, disaster recovery, or migrations.
There is no cost for the reservation itself. You are only charged for the EC2 instances that you run in the reservation, at the standard On-Demand instance pricing. If you do not run any instances, you incur no charges. This makes it a cost-effective way to guarantee capacity without paying upfront or committing to a term.
Yes. Reserved Instances (RIs) provide a billing discount but no capacity guarantee. On-Demand Capacity Reservations provide capacity guarantee but no discount. You can combine them: use an RI to get the discount on instances launched into an ODCR. The RI's discount applies to the instance usage, while the ODCR ensures the capacity is available.
When launching an EC2 instance, you must explicitly specify the Capacity Reservation ID. In the AWS Management Console, under 'Advanced details', select 'Launch into a Capacity Reservation' and choose the reservation ID. In the AWS CLI, add the `--capacity-reservation-id` parameter to the `run-instances` command. If you do not specify, the instance will launch as a regular On-Demand instance and will not use the reservation.
Yes, you can cancel an ODCR at any time using the AWS Management Console, CLI, or API. Cancelling the reservation does not affect any running instances; they continue to run but are no longer associated with the reservation. The reservation's state changes to 'cancelled'. You can also set an end date during creation to automatically cancel the reservation at a future time.
The key difference is that an ODCR guarantees capacity in a specific AZ but does not provide a discount, while a Reserved Instance provides a discount (up to 72%) but does not guarantee capacity. ODCRs have no term commitment; RIs require a 1- or 3-year term. ODCRs are always zonal; RIs can be regional or zonal. They are complementary: you can use both together.
Yes, you can share an ODCR with other AWS accounts using AWS Resource Access Manager (RAM). This allows you to reserve capacity centrally and allow other accounts to launch instances into the reservation. The shared reservation appears in the target account's console, and they can launch instances into it, subject to your permissions.
You've just covered On-Demand Capacity Reservations — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?