AWS Has Reserved Capacity Sold Out Through 2027, But Sets Aside a Share for On-Demand Use

AWS Has Reserved Capacity Sold Out Through 2027, But Sets Aside a Share for On-Demand Use

Andy Jassy confirms that large blocks of AWS capacity are largely sold out through 2027, with part of 2028 already allocated. The company says it keeps room for on-demand EC2 and Bedrock, but developers are already reporting queues for common instances.

Editor's note: the description of how EC2 Capacity Manager works in this article (cross-account/cross-region aggregation and the calculation of reserved-capacity usage ratio) is based solely on secondary reporting from InfoQ, without confirmation in official AWS documentation reviewed by this newsroom. Readers should treat this section as secondhand information about the tool's exact behavior, unverified against the primary source.

What Jassy Said

In a video podcast with Andreessen Horowitz co-founder Ben Horowitz and general partner Erik Torenberg, Amazon CEO Andy Jassy said that AWS's large blocks of reserved capacity are largely sold out through 2027, with a significant portion of 2028 already committed. The statement was reported by Reuters on October 23 and picked up by InfoQ.

According to Jassy, 2026 capacity has already sold out completely, and AWS could invest well more than the roughly 220 billion dollars in capital expenditures (capex) planned for this year without it being a poor use of capital.

2027 is largely sold out. We always leave a certain amount for on demand and our inference service bedrock, or EC2, but largely sold out all the big chunks. A good chunk of 2028 is sold out.

Andy Jassy, CEO of Amazonfoto: Lisi Mezistrano Wolf · CC BY-SA 4.0

How AWS's Capacity Reservation Works

According to InfoQ's reporting, AWS sells capacity guarantees through two mechanisms: On-Demand Capacity Reservations, in which the customer reserves instances in a named Availability Zone, and Capacity Blocks for ML, aimed at machine learning workloads, in which the reservation covers a fixed window starting from a future date. In January, AWS had already raised prices for Capacity Blocks for ML by about 15% uniformly across all regions, covering the P5en, P5e, P5, and P4d GPU instances, as well as the Trn2 and Trn1 instances, as InfoQ itself had previously reported.

It's this pre-reservation model, aimed at large model providers and companies with long-term capacity planning, that is "sold out" according to Jassy. The concept is different from simply not being able to spin up an instance in the console today.

The Skeptical Reaction: 'Sold Out' Isn't Quite That

Cloud analyst David Linthicum pushed back on the more alarmist reading of the news, separating the pre-reserved blocks described by Jassy from what a company can actually allocate day to day.

Of course, I suspect I can still go into the AWS console today and allocate GPU capacity for AI workloads. Maybe not the exact massive, pre-reserved, hyperscale capacity block some large model provider wants for the next three years, but that's not exactly the same thing as "AWS is sold out.

David Linthicum, cloud analyst

For Linthicum, the market already carries enough confusion between reserved instances, on-demand services, and committed capacity, and headlines like this lead to wrong assumptions and poor planning strategies.

What Developers Are Seeing in Practice

While Jassy talked about contracts through 2027 and 2028, discussion in developer forums revolved around a more immediate problem: availability right now, for common EC2 instances. The top-voted comment in a Reddit thread, signed by a developer identified as cbigsby, describes the scenario.

We've been seen a big rise in compute capacity issues the past month or so at work, just for regular ec2 instances. Forget spot instances we have trouble getting enough on demand. Luckily mostly tied to CI but there have been a few days where the production k8s clusters have been concerningly constrained.

cbigsby, developer, in a Reddit comment

Similar reports surfaced elsewhere. Richard T., a technical operations manager, commented on Linthicum's post that Microsoft disclosed limited information about capacity constraints in the Azure East US region, and that his team had started adopting reserved instances to secure capacity ahead of projected growth. In a parallel thread, another commenter reported difficulty getting enough compute from all three major cloud providers, and said the constraint isn't limited to GPUs.

The Anti-Cloud Pattern This Could Create

The architectural consequence of this scenario was pointed out by Ian Rae, in response to Linthicum.

next thing you know, folks reserve cloud resources they are worried they might need, which is an anti-cloud pattern

Ian Rae

Rae's point is direct: reserving capacity "just in case" reintroduces the same problem elastic cloud promised to solve, only now in contractual form instead of physical hardware bought upfront. Those who over-reserve pay for idle capacity; those who under-reserve end up in the queue cbigsby described.

The Tool AWS Already Offers

As InfoQ had already reported in October of the previous year, EC2 Capacity Manager aggregates capacity data in a cross-account and cross-region dashboard, and reports the ratio between used and unused reserved capacity as a measure of reservation efficiency.

In practice, for those already operating with Capacity Reservations or Capacity Blocks, this dashboard works as a natural first place to check before deciding to reserve more, since it shows whether the contracted capacity is actually being consumed or sitting idle.

What Changes for Developers in Brazil

The practical takeaway from this episode is to separate two time horizons. Long-term contracts for massive GPU blocks (the ones meant for training large models) are a negotiation between AWS and a handful of very large customers; this doesn't directly affect someone spinning up a t3.medium instance or a small EKS cluster in sa-east-1.

What affects the infrastructure team day to day is the second horizon, what the Reddit reports describe: spikes of contention in common on-demand instances, especially when the CI pipeline depends on scaling quickly. In short: if your team has already seen an InsufficientInstanceCapacity failure when scaling a Kubernetes cluster or a CI runner, it's not your imagination, and the phenomenon tends to keep recurring as AI capacity demand keeps pressuring the same regions.

A few points are worth reviewing before the end of the year:

• Check, in the console or via EC2 Capacity Manager, the usage rate of existing reservations before buying more reserved capacity.
• For AI workloads (training or inference via Bedrock), consider reserving Capacity Blocks further in advance than usual, since 2026 is sold out and 2027 is heading the same way.
• For CI/CD and common elastic workloads, test multiple instance types and multiple availability zones within the same region as mitigation, instead of depending on a single on-demand instance type.
• Follow Amazon's quarterly report (third-quarter results came out on October 29) to understand how much of the committed capacity has already turned into contracted revenue via the remaining performance obligations (RPO) indicator.

The episode is also a reminder that "elastic cloud" always had a physical limit behind the talk of infinite capacity. The difference now is that this limit has become visible both to those buying GPU blocks for 2028 and to those who just wanted to spin up one more m5.large on a peak day.