“Sold out” is something you expect to hear about concert tickets, a popular restaurant or the hotel next to a major technology conference. Hearing it about the cloud takes a little more getting used to.

Yet that is how Amazon CEO Andy Jassy recently described AWS capacity. In an October 23 interview with Andreessen Horowitz, he said 2026 was sold out, 2027 was largely committed and a significant portion of 2028 was already booked.

There is an important qualification. Jassy said AWS holds capacity back for on-demand customers, including EC2 and Bedrock. He was discussing the large blocks being committed ahead of time. Your development team has not suddenly lost the ability to launch an instance.

Still, the implications deserve more attention than another round of headlines celebrating AI demand.

One of the great achievements of cloud computing was changing our relationship with infrastructure. Teams could build without first navigating a hardware purchasing cycle. Capacity became something you consumed as the business required it.

For large AI deployments, that assumption now needs examination. The cloud remains available, but the particular infrastructure you need, at the scale you need, may require a reservation made long before your application starts generating revenue.

The Infrastructure Never Disappeared

The cloud always depended on physical equipment. We simply became accustomed to someone else worrying about it.

That arrangement worked remarkably well. Developers gained speed, businesses gained flexibility and infrastructure teams could spend more time on architecture and reliability. Nobody missed waiting for a server shipment before getting a project moving.

Large AI clusters expose the limits of that abstraction.

Thousands of accelerators have to work together, supported by sufficient memory, networking, power and cooling. Available machines scattered across different facilities are not automatically a substitute for a coordinated cluster. Microsoft’s own infrastructure risk disclosures describe dependencies ranging from electricity and grid connections to servers, cooling equipment and construction labor.

This is why announcements require careful reading. Contracted power is not the same as energized power. A building is not a functioning cluster. A future customer commitment is not current utilization.

We should also resist treating every AI project as if it requires a frontier training facility. An enterprise using a managed model service faces a different procurement problem from a company reserving thousands of accelerators. Those distinctions matter more than the broad declaration that the cloud is running out.

What Jassy’s comments suggest is that the largest deployments increasingly require coordinated planning between the customer and infrastructure provider. That planning introduces obligations on both sides.

A Reservation is Not a Victory Lap

AWS has a credible story here. Its infrastructure business, enterprise relationships and custom silicon give it several ways to serve growing demand.

Amazon says Trainium demand extends across successive chip generations, with customers reserving future capacity. It also continues to offer NVIDIA infrastructure. That combination gives AWS additional control over its architecture and economics while preserving options for customers with different requirements.

I would take those commitments seriously. Customers willing to plan around future infrastructure are sending a stronger signal than customers expressing interest in a sales meeting.

But “sold out” needs a denominator. A provider that books its planned supply has demonstrated demand relative to that supply. It has not, through those words alone, established that it offers the best performance, the lowest costs or the strongest customer experience.

It has also assumed a delivery obligation.

The competitive question is how much useful capacity AWS can bring online, how reliably it meets commitments and whether customers produce enough value to keep buying. Custom chips can improve that equation. They cannot manufacture electricity or eliminate construction delays.

Nor is AWS operating in isolation.

Microsoft said in its April earnings commentary that it expected constraints across GPU, CPU and storage capacity to persist at least through 2026. Google Cloud and Oracle have reported enormous future revenue commitments. Those disclosures point to substantial demand, but they measure different things and cannot be converted into a tidy ranking of who is “most sold out.”

Backlog is a financial measure. Availability is an operational question. Buyers need an answer to the second even when investors are cheering the first.

That creates an opening for neoclouds.

A specialist does not have to replace a customer’s entire AWS or Azure environment to win a valuable workload. It needs to deliver the appropriate infrastructure, with acceptable performance, service and terms, when the customer needs it.

For a time-sensitive project, an earlier credible delivery date can matter enormously. That is a competitive opportunity, not proof that every neocloud is faster or cheaper.

The specialists also deserve scrutiny. Nebius’s second-quarter shareholder letter described major contracts whose customer prepayments would cover 50–60% of associated capital expenditure. Its disclosures explicitly included capacity not yet built. CoreWeave’s backlog definition similarly makes future revenue dependent on delivery and service availability.

These arrangements can help finance expansion. They also make the customer’s commitment part of the infrastructure development process.

The relevant comparison is therefore more demanding than hyperscaler versus neocloud. Who can deliver? What is already operating? What still requires financing, equipment or a utility connection? What happens if the promised date slips?

Procurement Returns to the Architecture Meeting

For enterprise leaders, this is where the story becomes practical.

Consider a hypothetical company planning a substantial AI deployment next year. Its developers are testing models, its business team is estimating demand and its finance team wants a credible return on investment.

Now add a capacity decision that must be made before those estimates are settled.

Reserve too little and the company may struggle to expand on schedule. Reserve too much and it may carry commitments for resources it does not need. Choose specialized infrastructure and the economics may improve, while moving the workload elsewhere may require additional engineering.

Those are architecture, procurement and business decisions wrapped together.

I believe capacity planning deserves a more prominent place in enterprise AI discussions. We spend considerable time debating model quality, governance and security. For projects requiring dedicated infrastructure, the delivery assumptions belong in that same conversation.

A sales assurance that capacity will be available should become a specific commitment: hardware, location, quantity, delivery date and remedies if the provider falls short. Customers should understand minimum spending obligations and the conditions under which they can change course.

Platform teams should also identify which workloads can move and what moving them would actually require. A second provider’s name on a presentation does not create portability. Data movement, software dependencies, operational skills and performance requirements determine whether an alternative is usable.

None of this means every enterprise needs to start reserving giant clusters. Many organizations will consume AI through managed services, leaving much of this planning to their suppliers. They should still understand how service quotas and expansion commitments fit their needs.

The point is to match the planning discipline to the deployment.

Cloud computing gave businesses extraordinary flexibility, and that achievement remains intact. But large-scale AI introduces circumstances where access to infrastructure must be negotiated well before it is consumed.

Providers will understandably celebrate full order books. Customers should celebrate infrastructure that arrives on time and helps their businesses accomplish something worth paying for.

Before approving the AI roadmap, ask who has secured the compute—and what they had to promise to get it.