Skip to content

Capacity Reservations and Capacity Blocks

Note

Capacity Reservation can be enabled or disabled using /configuration/FeatureFlags/EnableCapacityReservation configuration flag.

Capacity Reservations in AWS allow you to reserve a specific number of instances of a particular type in a specific Availability Zone, ensuring that the capacity you need is available when you launch your instances. By reserving capacity in advance, you can avoid InsufficientInstanceCapacity errors that occur when AWS doesn’t have enough available instances of the desired type at launch time.

EDH handles Capacity Reservations differently depending on the workload type.

VDI Workloads (Capacity Probing)

For Virtual Desktop Infrastructure (VDI), EDH performs capacity probing only. It does not hold a reservation for the life of your desktop.

When you launch a virtual desktop, your request is accepted right away and the desktop is shown as being placed while EDH does the capacity check in the background. This keeps the web interface responsive, even when many desktops are launched at once.

  1. EDH accepts your request immediately and marks the desktop as being placed.

  2. In the background, EDH checks EC2 capacity across the candidate subnets at the same time and selects the first one with capacity.

  3. To confirm availability, EDH briefly reserves capacity in that subnet.

  4. Once capacity is confirmed, the desktop is provisioned and the brief reservation is released.

If no capacity is available, the request fails and no desktop is launched. No Capacity Reservation remains active after the desktop is launched.

VDI Capacity Probing Flow

graph TD
    A[User requests Virtual Desktop]
    B[Request accepted: desktop marked as placing]
    C[Background: check capacity across subnets in parallel]
    D[Briefly reserve capacity in the chosen subnet]
    E[Capacity confirmed, release the brief reservation]
    F[Provision Virtual Desktop]
    G[Request fails]

    A --> B
    B --> C
    C -->|Capacity available| D
    D --> E
    E --> F
    C -->|No capacity| G

HPC Workloads (Actual Capacity Reservation)

Warning

EDH does NOT support Capacity Reservations when jobs are submitted with multiple subnet IDs and/or instance types. In this scenario, EDH attempts to provision the full capacity within a single subnet. If no reservation succeeds, EDH proceeds will continue to host provisioning without enforcing the reservation, as EC2 Fleet may still be able to fulfill the capacity by distributing instances across multiple subnets. Enable /configuration/FeatureFlags/EnforceStrictCapacityReservation is you want to block the host provisioning unless EDH can confirm capacity is fully available (e.g: if 100% of instance_type1 is available in subnet1)

Capacity Reservations can only be enforced when a job is submitted with a single subnet ID

The provisioning workflow is:

  1. EDH checks EC2 capacity availability in the specified subnet(s).
  2. If capacity is available, EDH creates a Capacity Reservation and retrieves a Reservation ID.
  3. In case of job submitted with multiple subnet IDs, EDH will rewrite the subnet_id attributes to only include the subnet id where the capacity is available
  4. The Reservation ID is mapped to the EC2 Launch Template.

EC2 Fleet provisions the required instances using the reservation.

After successful provisioning, the Capacity Reservation is canceled.

HPC Capacity Reservation Flow

graph TD
    A[User submits HPC job]
    C[Check EC2 capacity in subnet]
    D[Create Capacity Reservation]
    E[Attach Reservation ID to Launch Template]
    F[EC2 Fleet provisions instances]
    G[Instances running]
    H[Cancel Capacity Reservation]
    I[Job stays in queue]

    A --> C
    C -->|Capacity available| D
    D --> E
    E --> F
    F --> G
    G --> H
    C -->|No capacity| I

Existing Capacity Reservations or Capacity Blocks for ML

You can reference an existing Capacity Reservation / Capacity Blocks for ML created outside of EDH while submitting your HPC job via -l capacity_reservation_id (Learn more).

Capacity Reservation Cleanup and Cost Control

AWS charges for Capacity Reservations even when no EC2 instances are running. EDH includes multiple safeguards to minimize unnecessary costs by ensuring reservations are canceled as quickly as possible.

Automatic EndDate

Each Capacity Reservation is created with an EndDate to enforce automatic expiration:

  • VDI capacity probing: now + 2 minutes
  • HPC capacity provisioning: now + 5 minutes

For additional details, see the AWS documentation: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cr-concepts.html#cr-end-date

Immediate Cancellation After Probing

For VDI capacity probing, EDH explicitly attempts to cancel the Capacity Reservation immediately after the capacity check completes, without waiting for the EndDate.

Automated Cleanup with ODCRCleaner Lambda

EDH includes a Lambda function (ODCRCleaner) that continuously cleans up idle or orphaned Capacity Reservations associated with a EDH cluster.

The Lambda function is triggered:

  • On a scheduled interval (every 5 minutes)
  • On CloudFormation stack events

This guarantees that unused Capacity Reservations are removed promptly.

Capacity Reservation Cleanup Flow

graph TD
    A[Capacity Reservation created]
    B[EndDate applied]
    C[EDH attempts early cancellation]
    D[ODCRCleaner Lambda triggered]
    E[Identify idle/orphaned reservations]
    F[Cancel reservations]
    G[EndDate reached]
    H[Capacity Reservation is cancelled]

    A --> B
    B --> C
    C -->|Cancellation fails for any reason| D
    D --> E
    E -->|Cancellation fails| G
    E -->|Success| H
    G --> H