Why your EC2 quota doesn't guarantee capacity

Andy Jassy said something on an a16z podcast last week that got compressed into a headline it does not support. DatacenterDynamics, which covered the episode, quotes him saying 2026 is sold out, that "'2027 is largely sold out", and "a good chunk of 2028" with it.

The clause in between is the one that got dropped: "We always leave a certain amount for On Demand, and our inference service Bedrock or EC2."

On-demand capacity is still held back, and the big multi-year blocks are what sold. Amazon has published no contracted-capacity number behind the word "sold out", making this the CEO's characterisation rather than a disclosure.

You will not open the console tomorrow and find EC2 out of stock. What has gone is the slack. For fifteen years there was enough invisible surplus in every region that "which region" and "which instance family" could be filled in once, at the start of a project, and never revisited. Those two fields are design decisions again.

Does this reach you at all

If you run a web tier, an API and a Postgres database on general-purpose instances, mostly not. You will meet this as pricing and occasional instance-family availability, a budget conversation rather than an availability one. If you run anything touching a GPU, meaning an inference endpoint, an embedding pipeline, a nightly batch job or a recommendation service, yes, and it shows up as failed launches in a specific zone rather than as an outage. If you are negotiating a multi-year accelerated deployment you already know, since the lead times are in your contract.

Most of what follows costs a day or two and is worth doing regardless.

Quota is not capacity, and the providers say so

I would rather quote Microsoft on this than a CEO, since product docs do not decay with a news cycle. From Azure's capacity reservation overview:

Quota and capacity are separate checks. Quota is your subscription's permission to deploy resources, while capacity is the underlying infrastructure available in a specific region or zone.

An approved quota increase gets you permission to ask. It buys no hardware. The two failures have separate error codes on the same AWS page. InstanceLimitExceeded means "you have reached the limit on the number of instances that you can launch in a Region", and a support ticket fixes it. InsufficientInstanceCapacity means "AWS does not currently have enough available On-Demand capacity to fulfill your request", and no ticket fixes that.

Read AWS's own remedies for that second error: wait and retry, ask for fewer instances, drop the Availability Zone from the request, or try a different instance type. Three of those four only work if your architecture was already flexible before the error arrived, and you cannot acquire that flexibility during an incident. A line on the same page is easy to miss too: "If you are launching instances into a cluster placement group, you can get an insufficient capacity error."

Your SLA probably does not cover it either. Google's GPU machine documentation states that the Compute Engine SLA "doesn't apply to the A4X machine series", and says the same separately for A4X Max. A failed launch is not an availability event.

A discount is not a reservation

AWS settles this in one table in the Capacity Reservations documentation. Regional Reserved Instances and Savings Plans reserve no capacity. On-Demand Capacity Reservations and zonal RIs reserve capacity in a specific Availability Zone, and the Capacity Reservation comes with no billing discount at all.

Which makes the commitment question answerable. Compute Savings Plans go up to 66% off on-demand and flex across instance family, size, Region, operating system and tenancy. EC2 Instance Savings Plans go up to 72% but pin you to one instance family in a chosen Region, and "the terms of the commitment can't be changed after purchase." Six percentage points is the price of that flexibility, and where a family might not be launchable in your Region on the day you need it, those six points buy a commitment to something you may not be able to start. I would take the Compute plan, commit only the baseline I am confident about in a year, and leave the rest on demand. That is the opposite of what your account rep will propose.

For actual capacity the instruments are ODCRs, zonal RIs, and Capacity Blocks for ML, where a block can start up to 8 weeks out, "cancellations aren't allowed", and "Capacity Blocks do not support placement groups." That last one is not academic. A fix merged into terraform-aws-eks on 7 October describes how it bites. The module "unconditionally creates a Cluster Placement Group", which "causes InsufficientInstanceCapacity errors when launching instances against" ODCRs or Capacity Blocks provisioned without a matching group. Reserved capacity, paid for, unlaunchable, from a placement-group mismatch two layers down a module.

How this reaches you with no GPUs anywhere

Through memory. A 64GB RDIMM DDR5 module went from $450 in Q4 2025 to over $900 in Q1 2026 on Counterpoint Research's fixed contract pricing, ending that quarter at $927. For a 1TB server built from sixteen of them, the memory goes from about $7,200 to $14,832.

TrendForce has conventional DRAM contract prices rising another 10-15% in 4Q26 with server DRAM still undersupplied, and Micron told investors in September that "we do not have line of sight to when supply and demand will return to balance."

Then the asymmetry that determines what you pay. The analysts behind that 10-15% forecast reported in July that "several U.S.-based CSPs have entered into multi-year long-term agreements (LTAs), which restrict suppliers from raising prices for these clients", and that from Q3 2026 onward the increases shift toward customers without such agreements. The hyperscalers hedged their memory supply and you did not, so you meet the shortage second-hand, as instance pricing, and as which RAM-heavy families exist in your Region, on their schedule. Which also disposes of the repatriation instinct, since buying your own servers now means buying server DRAM at the worst point in its cycle with no LTA. You do not escape the shortage by owning the hardware, since the shortage is the hardware.

What to change, cheapest first

Stop pinning one instance type. In an Auto Scaling group, use mixed instance types or attribute-based selection, so you describe what you need instead of naming one answer. Karpenter's NodePool docs agree. "Generally, instance types should be a list and not a single value." A threshold hides in that advice, since Karpenter "requires a minimum instance type flexibility of 15 instance types when performing single node spot-to-spot consolidations", so narrowing the requirements block below fifteen switches off, without any warning, consolidation you think you have. For GPU inference, ask for a range of shapes with more replicas rather than one large shape.

Get a second Region warm, not active-active. Multi-AZ you already have, and dropping the AZ constraint is AWS's own first remedy. A second Region holding your IaC, images and approved quota but little running is the version worth doing; active-active with replicated state is expensive and this does not justify it, and multi-cloud is a tax rather than a hedge. The piece people skip is the quota. Request it in your second Region now, since approval is a support ticket with a human in the loop, and filed during an incident it may not land in time to matter.

Make capacity failure its own error path. Alert on the quota codes and the capacity codes separately, since the remediations have nothing in common. On a capacity error, shift traffic with DNS or load-balancer weights rather than waiting for instances that are not coming. Create reservations before the resources that depend on them, so a capacity failure happens first and cheaply.

Both futures, one architecture

Two readings are live at once. David Linthicum argued on 19 October that the biggest deals are sold out rather than capacity, and that some demand is a land rush which will normalise. Jassy points the other way. The middle of ordinary business software has not arrived because inference is, as he put it, still an order of magnitude too expensive, and if that cost falls the squeeze gets worse first.

I do not know which happens and I do not think you need to. Note what the providers have already shipped... Capacity Blocks bookable eight weeks out and non-cancellable, Azure billing VM rates for capacity you are not using, memory contracts that protect some buyers by name and nobody else. Those exist because capacity stopped being fungible. Instance-family breadth and a warm second Region keep you launching if scarcity holds, and cost little if it eases.

This week, open the ASG or NodePool config for your most important service and count the instance types it is allowed to use. If the answer is one, you have found the cheapest item on this list. Then check whether the quota you would need in a second Region is already approved.

Figures as of 27 October 2026.