Authors - Aditi Singh (Sr. Technical Account Manager) , Aneesh Varghese (Sr. Technical Account Manager)

Electronic Design Automation (EDA) workloads; simulation, synthesis, place-and-route, Design rule checking(DRC), Layout versus schematic(LVS) and tapeout, are among the cloud's most compute-intensive and variable workloads. A design team may need thousands of cores for a multi-week tapeout sprint, then scale back dramatically for regression runs. This burst pattern makes capacity planning critical. Amazon EC2 On-Demand Capacity Reservations (ODCRs) and EC2 Capacity Blocks for ML provide guaranteed compute access when needed. In this post, you will learn how to plan and create Amazon EC2 Capacity Reservations tailored to EDA workloads. A companion post covers managing and retiring reservations as your design project progresses.

Understanding your options

Before diving into the lifecycle, it is important to understand the two capacity reservation mechanisms and when to use each.

Option 1 - On-Demand Capacity Reservations (ODCRs) - reserve compute capacity for Amazon EC2 instances in a specific Availability Zone for any duration.

Option 2 - Capacity Blocks for ML - reserve GPU-based instances on future dates for defined durations.

The following table summarizes key characteristics of the 2 options:

Feature	On-Demand Capacity Reservations (ODCRs)	Capacity Blocks for ML
Instance types	General purpose, compute, memory, storage	GPU instances (P5, P5e, P5en, P4d, Trn1, and others)
Duration	No fixed term (immediate) or 14+ days (future-dated)	1 day to 6 months
Future-Dated	Up to 120 days for future-dated	Up to 8 weeks
Modifiable	Yes (scale, split, move)	No
Cancellable	Yes (immediate ODCRs)	No
Workload type	Steady-state pools, tapeout bursts, regression farms	ML-assisted design (yield prediction, lithography simulation)
Billing discount	Savings Plans and Regional Reserved Instance discounts can be applied to Capacity Blocks.	Savings Plans and Reserved Instance discounts don't apply to Capacity Blocks.

Phase 1: Plan

Effective capacity planning starts well before you create a reservation. For EDA workloads, this means understanding your compute demand profile and aligning it with the chip design schedule.

Map your workload patterns

EDA workloads have distinct capacity profiles. Before creating reservations, characterize your demand across these common patterns:

Workload	Pattern	Typical duration	Recommended strategy
Regression runs	Recurring, predictable	Hours to days	ODCR steady-state pool
Place-and-route	Burst, semi-predictable	Days to weeks	ODCR scheduled scale-up
Tapeout	Large burst, deadline-driven	2–6 weeks	Future-dated ODCR
DRC/LVS	Burst, follows place-and-route	Days	Split from place-and-route ODCR
ML/AI training	Periodic, GPU-intensive	Days to weeks	Capacity Blocks

Choose the right instance types

EDA workloads benefit from high, single-thread performance and large memory. Common choices by workload type include:

• Compute-intensive (synthesis, simulation): Instance families in the C and HPC series, such as c7i.metal-48xl or hpc7a.96xlarge
• EDA-optimized: x8aedz.metal-48xl, purpose-built for EDA with high clock speed and large memory
• Memory-intensive (place-and-route, physical verification): Instance families in the R and M series, such as r7i.24xlarge or m7i.metal-48xl
• GPU (ML-assisted design): P5, P5e, Trn1 series for yield prediction, design-for-test optimization, and generative AI for circuit design

If your primary instance type is capacity-constrained, identify fallback types and build this flexibility into your job scheduler configuration. A practical fallback hierarchy for EDA workloads:

1. Same instance type, different AZ - Easiest fallback if your storage supports cross-AZ access. Example: x8aedz.metal-48xl in us-west-2b instead of us-west-2a.

2. Same family, smaller size (scale horizontally) - Use more instances of a smaller size. Example: 2× r7i.24xlarge (96 vCPU each) instead of 1× r7i.metal-48xl (192 vCPU). Requires your workload to distribute across nodes.

3. Adjacent family - Switch to a different family with similar characteristics. Example: r7a.48xlarge instead of r7i.48xlarge (AMD vs. Intel). Verify EDA tool licensing compatibility with the alternative processor architecture.

4. Previous generation - Older instance types often have deeper capacity pools. Example: x2iedn.32xlarge as fallback for x8aedz.metal-48xl. Performance may differ; validate with a benchmark run before committing to production workloads.

Most EDA grid schedulers — including IBM Spectrum LSF, Slurm, and PBS Pro — support ordered resource definitions that automatically try the next type when the preferred type returns InsufficientInstanceCapacity. Refer to your scheduler's documentation for the exact configuration syntax for instance type priority lists. This eliminates manual intervention during tapeout crunches when capacity is most constrained.

Plan Availability Zone placement

For EDA workloads, Availability Zone selection depends on your workload characteristics:

1. Co-locate with storage If you use Amazon FSx for NetApp ONTAP or Amazon EFS, place compute in the same Availability Zone as your storage filesystem's preferred subnet. Cross-AZ data transfer adds latency that is significant for I/O-intensive EDA simulation.

2. Spread across Availability Zones for resilience For non-latency-sensitive workloads such as batch regression, distribute ODCRs across two or three Availability Zones to reduce single-AZ risk.

3. Use cluster placement groups for tightly coupled jobs If your EDA workload requires low-latency inter-node communication (for example, distributed simulation), create ODCRs within a cluster placement group.

Lead Time Considerations

Different reservation types have different lead times:

• Immediate ODCRs are subject to current Availability Zone capacity. Common instance types are typically available instantly, while specialized types might require planning.
• Future-dated ODCRs can be requested 5–120 days in advance. We recommend requesting at least 56 days in advance for best supportability. A minimum of 32 vCPUs and a 14-day commitment duration are required.
• Capacity Blocks can be reserved for up to 8 weeks in the future. Availability is dynamic, so check early and often.

Handle InsufficientInstanceCapacity errors

If you attempt to launch instances without a Capacity Reservation and the Availability Zone capacity pool is exhausted, you receive an InsufficientInstanceCapacity error. This is common for EDA workloads because:

• EDA-optimized instance types (x8aedz, high-memory X and R series) have smaller regional pools than general-purpose types
• Tapeout bursts request hundreds of instances simultaneously, competing with other large consumers in the same AZ
• Newer-generation instances may have limited initial deployment in specific Availability Zones

Why Capacity Reservations prevent this: An active ODCR guarantees that capacity is allocated to your account regardless of current pool availability. With a targeted ODCR, instances launched against that reservation will never receive InsufficientInstanceCapacity for that instance type in that Availability Zone.

If you encounter InsufficientInstanceCapacity without a reservation in place:

1. Try an alternative Availability Zone in the same Region where your storage (FSx for NetApp ONTAP, EFS) has cross-AZ access configured
2. Fall back to a different instance type in the same family (for example, r7i.24xlarge instead of r7i.metal-48xl) or an adjacent family (r7a instead of r7i)
3. Create a future-dated ODCR to secure capacity for your next milestone rather than competing in the on-demand pool. You can request a future-dated Capacity Reservation between 5 and 120 days in advance — AWS recommends requesting at least 56 days (8 weeks) in advance for the best chance of fulfillment. The minimum commitment duration is 14 days for most instance types, or 12 weeks for U and X instances.
4. Contact your AWS account team to discuss assisted capacity options for large-scale requirements
5. Configure your EDA job scheduler (LSF, Slurm, PBS Pro) with an ordered instance type preference list so it automatically falls back to available types without manual intervention. Refer to your scheduler's documentation for the exact configuration syntax for instance type priority lists.

If your plans change after creating a future-dated ODCR, you can generate a cancellation quote (CreateCapacityReservationCancellationQuote) to understand exact charges before committing to cancel. See Part 2, "Cancel a future-dated ODCR" for details on cancellation timing and charges.

The best practice is to proactively create ODCRs aligned to your chip design schedule rather than relying on on-demand availability during critical deadlines.

Size with a buffer

EDA workloads have variable parallelism. Reserve above your expected peak to account for re-runs and unexpected job failures:

• Regression farms: Reserve your 75th–90th percentile peak, not the 50th percentile average. Use open eligibility, so idle capacity is available to other workloads.
• Tapeout bursts: Reserve 20–30 percent above your estimated peak.
• ML training: Match Capacity Block size to your training cluster size. Consider starting with smaller sizes such as p5.4xlarge for proof of concept before committing to a full p5.48xlarge cluster. Capacity Blocks cannot be modified after purchase.

Phase 2: Create

Once your plan is in place, create reservations that match your workload requirements. Create an ODCR for immediate use The following example creates a targeted ODCR for 1 instance of r7i.24xlarge in us-west-2a:

aws ec2 create-capacity-reservation \
  --availability-zone us-west-2a \
  --instance-type r7i.24xlarge \
  --instance-count 1 \
  --instance-platform Linux/UNIX \
  --instance-match-criteria targeted \
  --tag-specifications 'ResourceType=capacity-reservation,Tags=[{Key=Project,Value=TapeoutQ3},{Key=Team,Value=PhysicalDesign},{Key=CostCenter,Value=ASIC-Design}]'

Follow these best practices when creating ODCRs:

• Use targeted for dedicated pools. If specific teams or job queues should use the capacity, use targeted eligibility. This prevents other workloads from consuming reserved capacity.
• Use open for shared pools. If you want matching instances to automatically use the reservation, use open eligibility. This maximizes utilization but reduces control.
• Tag consistently. Include Project, Team, CostCenter, and EndDate tags. EDA organizations often have multiple design projects running simultaneously, and tags are essential for cost allocation and lifecycle management.
• Match the platform exactly. A mismatch between the ODCR instance platform (for example, RHEL versus Linux/UNIX) and your AMI causes the reservation to go unused while you still pay for it. Verify your AMI platform before creating the ODCR:

aws ec2 describe-images \
  --image-ids ami-0abcdef1234567890 \
  --query 'Images[].PlatformDetails'

Align Savings Plans or Reserved Instances before the ODCR becomes active. If you plan to pair the ODCR with a Savings Plan or Reserved Instance for discounted pricing, confirm that the commitment is active in the account first. Without an active commitment, you are billed at full On-Demand rates from the moment the ODCR enters the active state.

Create a future-dated ODCR

For planned tapeout bursts, future-dated ODCRs provide advance capacity assurance:

aws ec2 create-capacity-reservation \
  --availability-zone us-west-2a \
  --instance-type x8aedz.metal-48xl \
  --instance-count 1 \
  --instance-platform Linux/UNIX \
  --instance-match-criteria targeted \
  --start-date 2026-07-01T00:00:00Z \
  --commitment-duration 30 \
  --tag-specifications 'ResourceType=capacity-reservation,Tags=[{Key=Project,Value=TapeoutAlpha}]'

Keep the following considerations in mind when creating future-dated ODCRs:

• The minimum instance count must total at least 32 vCPUs (for example, 8 instances of m5.xlarge)
• The minimum commitment duration is 14 days. The --commitment-duration value is specified in days
• Request at least 56 days in advance for best supportability.
• You cannot decrease the instance count below your commitment during the commitment period.
• Future-dated ODCRs are supported for C, G, I, M, R, and T series instances.

Purchase a Capacity Block

For GPU-based ML workloads in your EDA pipeline, search for available Capacity Blocks and purchase one:

Search for available Capacity Blocks

aws ec2 describe-capacity-block-offerings \
  --instance-type p5.48xlarge \
  --capacity-duration-hours 168 \
  --instance-count 1

Purchase a Capacity Block

Use the purchase-capacity-block command with the offering ID of the Capacity Block from the output of the previous example. Refer this document for more details

aws ec2 purchase-capacity-block \
  --capacity-block-offering-id cbo-0123456789abcdef0 \
  --instance-platform Linux/UNIX \
  --tag-specifications 'ResourceType=capacity-reservation,Tags=[{Key=Project,Value=YieldML}]'

Keep the following considerations in mind when purchasing Capacity Blocks:

• Capacity Blocks cannot be canceled after purchase.
• Support only selected Amazon EC2 instance families, such as P5, Trn1 and Trn2, and do not cover every GPU instance type.
• Instances must explicitly target the reservation ID.
• Blocks end at 11:30 AM UTC on the final day, with instance termination beginning at 11:00 AM UTC. Save your work before expiration by checkpointing ML training jobs and persisting results to Amazon S3 or Amazon EBS.
• Capacity Block can't be moved or split.

Next steps

In Part 2: Manage and retire EC2 Capacity Reservations for EDA workloads, you learn how to scale, split, share, and cancel reservations as your design project progresses through synthesis, place-and-route, and signoff.

To get started with Capacity Reservations, see the Amazon EC2 On-Demand Capacity Reservations documentation. For Capacity Blocks, see Capacity Blocks for ML.