How to Share EC2 Capacity Reservations and Offset Costs?

Unused capacity in an Amazon EC2 Capacity Reservation can be managed and optimized in two primary ways: sharing the reservation across multiple AWS accounts using AWS Resource Access Manager, and offsetting the cost of unused capacity with Zonal Reserved Instances or Savings Plans. Because you are billed for the full capacity of an active On-Demand Capacity Reservation regardless of whether instances are running in it, combining cross-account sharing with billing discounts ensures both high resource utilization and cost efficiency across your organization.

Understanding Unused Capacity Billing

When you create an On-Demand Capacity Reservation (ODCR), AWS sets aside the specified compute capacity in a specific Availability Zone for your exclusive use. You pay the equivalent On-Demand rate for the total reserved capacity from the moment the reservation becomes active until you cancel it or it expires.

If a Capacity Reservation is created for \(N_{total}\) instances and you are currently running \(N_{used}\) matching instances, the unused capacity \(N_{unused}\) is calculated as:

\[N_{unused} = N_{total} - N_{used}\]

Without discounts or cross-account consumption, the hourly cost \(C_{unused}\) for this idle capacity is billed at the standard On-Demand hourly rate \(R_{OD}\):

\[C_{unused} = N_{unused} \times R_{OD}\]

To eliminate or reduce \(C_{unused}\), you can either increase \(N_{used}\) by allowing other AWS accounts to launch instances into the reservation, or reduce the effective hourly rate by applying Zonal Reserved Instances.

Sharing Capacity Reservations Across AWS Accounts

AWS Resource Access Manager (AWS RAM) allows an owner account to share an On-Demand Capacity Reservation with other individual AWS accounts, Organizational Units (OUs), or an entire AWS Organization. When shared, consumer accounts can launch instances with matching attributes (instance type, platform, tenancy, and Availability Zone) that automatically utilize the available capacity in the shared reservation.

Step 1: Create a Resource Share in AWS RAM

In the account that owns the Capacity Reservation, you can create a resource share using the AWS Management Console or AWS CLI:

aws ram create-resource-share \
    --name "Shared-EC2-Capacity" \
    --resource-arns arn:aws:ec2:us-east-1:123456789012:capacity-reservation/cr-0123456789abcdef0 \
    --principals 210987654321

If sharing outside of your AWS Organization, the recipient account must accept the resource share invitation via AWS RAM before the capacity becomes visible to them.

Step 2: Launch Instances in Consumer Accounts

Once shared, consumer accounts can launch instances into the Capacity Reservation depending on the reservation's eligibility setting:

  • Open Capacity Reservations: Any instance launched in the consumer account with matching attributes in the same Availability Zone will automatically consume the shared capacity if local capacity reservations are not targeted first.
  • Targeted Capacity Reservations: The consumer account must explicitly specify the Capacity Reservation ARN or ID during instance launch:
aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type m5.xlarge \
    --placement AvailabilityZone=us-east-1a \
    --capacity-reservation-specification CapacityReservationTarget={CapacityReservationId=cr-0123456789abcdef0}

Step 3: Assign Billing of Shared Capacity Reservations

By default, the account that owns the Capacity Reservation pays for any unused capacity, while the consumer account pays for the running instances it launches into the shared reservation. However, if you want a single consumer account to take over the financial responsibility for the unused capacity, the owner can assign billing to a consumer account within the same AWS Organization:

aws ec2 assign-capacity-reservation-billing-owner \
    --capacity-reservation-id cr-0123456789abcdef0 \
    --unused-reservation-billing-owner-id 210987654321

The target account must accept the billing transfer request before the billing ownership shifts.

Offsetting Unused Capacity with Zonal Reserved Instances

A Zonal Reserved Instance (RI)—a Reserved Instance that specifies a particular Availability Zone rather than being regional—actually includes both a billing discount and a built-in Capacity Reservation. However, if you use explicit On-Demand Capacity Reservations alongside Zonal Reserved Instances, AWS automatically applies the billing discount of an unused Zonal Reserved Instance to cover the charges of an unused On-Demand Capacity Reservation when all attributes match.

Matching Attributes Required for Offset

For a Zonal Reserved Instance to offset the cost of unused capacity in an On-Demand Capacity Reservation, the following attributes must match exactly:

  1. Instance Type: Both must specify the exact same instance size and family (instance size flexibility does not apply to Zonal RIs or Capacity Reservations).
  2. Availability Zone: Both must reside in the same Availability Zone (mapped by Availability Zone ID across accounts).
  3. Platform: Both must share the same operating system platform (e.g., Linux/UNIX, Windows).
  4. Tenancy: Both must have the same tenancy (e.g., default or dedicated).

When \(N_{RI}\) matching Zonal Reserved Instances are unutilized by running instances, the billable On-Demand unused capacity \(N_{billed\_OD}\) is reduced to:

\[N_{billed\_OD} = \max(0, N_{unused} - N_{RI})\]

Cross-Account RI Discount Sharing in AWS Organizations

If your AWS accounts are part of an AWS Organization with consolidated billing and Reserved Instance discount sharing enabled, the billing benefit of a Zonal Reserved Instance in one account can offset the unused capacity charges of an On-Demand Capacity Reservation in another member account.

When AWS calculates your organization's hourly bill, it applies the Zonal RI discount in the following priority order:

  1. Same-Account Usage: The Zonal RI first covers matching running instances or unused ODCR capacity within the account that purchased the Zonal RI.
  2. Cross-Account Running Instances: Any remaining Zonal RI discount is applied to matching running EC2 instances in other accounts within the AWS Organization.
  3. Cross-Account Unused Capacity Reservations: If the Zonal RI discount is still unutilized, it is applied to matching unused On-Demand Capacity Reservations in other accounts within the AWS Organization.

Comparing Zonal RIs, Regional RIs, and Savings Plans

Understanding how different AWS commitment models interact with unused On-Demand Capacity Reservations is critical for accurate cost planning:

Commitment Type Reserves Capacity? Offsets Unused ODCR? Instance Size Flexibility
Zonal Reserved Instance Yes (automatically) Yes, if attributes match No
Regional Reserved Instance No No (only covers running instances) Yes (for Linux/UNIX default tenancy)
EC2 Instance Savings Plan No Yes, up to commitment amount Yes (within family and region)
Compute Savings Plan No Yes, up to commitment amount Yes (across families and regions)

Unlike Regional Reserved Instances—which only apply discounts to actively running instances and cannot cover unused capacity in an ODCR—both Zonal Reserved Instances and AWS Savings Plans (Compute and EC2 Instance Savings Plans) can cover the cost of unused On-Demand Capacity Reservations.

Best Practices for Capacity and Cost Optimization

  • Monitor Unused Capacity: Use Amazon CloudWatch metrics such as UnusedInstanceCount under the AWS/EC2CapacityReservations namespace or AWS Cost Explorer to identify idle reservations.
  • Use Open Eligibility for Shared Pools: Configure shared Capacity Reservations as open so instances across member accounts automatically absorb available capacity without requiring changes to deployment templates.
  • Align AZ IDs Across Accounts: Because Availability Zone names (such as us-east-1a) can map to different physical locations across different AWS accounts, always verify the AZ ID (such as use1-az1) when purchasing Zonal RIs in one account to offset Capacity Reservations in another account.