Cloud capacity panic has gotten out of hand: 'sold out' is not the same as 'scarce'

David Linthicum, writing in his Cloud Insider blog at InfoWorld (an opinion piece dated November 10, 2026), argues that the debate over AI compute capacity has become muddled and overhyped. His starting point is a recent article claiming that AWS capacity is "practically sold out" through 2027. His ironic reaction is that, if taken literally, he would stop recommending AWS for AI workloads. But he points out that he can probably still log into the AWS console and provision some kind of AI compute.

His central thesis is that "capacity is limited" and "capacity is sold out" are not the same thing. The author acknowledges that demand is high, supply is constrained, GPUs are expensive, power is a problem and data centers do not appear by magic. What does not exist, in his view, is zero capacity: there may be no large, multi-year, hyperscaler-scale GPU allocations suitable for training a frontier model, or specific reserved-capacity blocks that a major AI lab wants to lock in through 2028. That, he stresses, does not mean the provider is "sold out."

Linthicum reads it as many cloud and infrastructure providers having an incentive to say their AI capacity is committed for years: it signals demand, reassures investors and reinforces the AI boom narrative. He likens it to a restaurant announcing it is booked for months: it impresses, creates urgency and discourages anyone who was thinking of making a reservation. The problem is that business leaders understand something different from what was meant: that they cannot run AI workloads, that their projects are blocked or that they have missed their chance if they have not already signed a large reserved-capacity deal. It then falls to him to explain what was really meant and what matters for their architecture.

The author notes that enterprise architects are already grappling with model selection, data governance, security, integration, latency, uncertain costs and a shortage of experienced staff. Adding vague claims about capacity makes the picture worse. Moreover, most companies are not training frontier models from scratch: they are building RAG systems, fine-tuning small models, deploying inference, testing copilots and agents and looking for value without creating a governance disaster. Those workloads need capacity, but not of the same kind. A bank running inference on a governed in-house model does not have the same profile as a startup training a giant model on thousands of GPUs, nor does a manufacturer integrating AI into its supply chain resemble a lab pretraining from scratch. Reducing everything to "AI capacity is sold out" is, in his words, "fog," not analysis.

Linthicum compares the current moment to the dot-com era, but believes the AI market has taken hype to a level he has rarely seen: every product is "AI-powered," every vendor has a platform and every infrastructure company is "sold out." Companies make real decisions with real money and need to know what capacity exists, what it costs, what commitments it requires, what performance to expect and what alternatives to evaluate, not "market theater" dressed up as infrastructure guidance. He calls for precision: if there is limited availability of certain GPU instance types in certain regions and commitment models, or if long-term reserved capacity for training clusters is mostly committed, or if on-demand capacity exists but may be constrained at peak times, say so.

He also warns that ignoring the constraints would be equally irresponsible. Some workloads require advance planning, some GPU types may be hard to obtain, certain regions may not have what is needed and some providers may impose commitments that change a project's economics. Both things can be true: the market is constrained and the headlines are overheated. That is why he has to explain to his clients that AWS is not closed to AI, that they should not abandon their cloud strategy, that not every workload should move to another provider and that they should not sign the first capacity reservation out of fear of missing out.

By way of recommendations, he proposes three steps. First, separate workload types before talking about capacity: training, fine-tuning, inference, development, testing, batch processing, real-time applications and data movement, each with its own capacity profile, cost model and architectural pattern. Second, validate availability directly with providers and partners, rather than relying on public statements, analyst commentary or executive bluster, asking about instance types, regions, service quotas, reservation options, pricing, timelines and alternatives, and getting the answers in writing when the workload is critical. Third, design for flexibility: avoid unnecessary lock-in at the capacity layer, use abstraction where it helps, keep the data architecture portable where practical, evaluate multiple deployment models and avoid panic-driven commitments that will look absurd 12 months from now.

His conclusion is that AI infrastructure, capacity planning and provider signals matter, but the market needs fewer "victory laps" and more clarity: facts, context and architectures that survive contact with reality. It is worth noting that this is an opinion piece: it provides no figures of its own on any provider's actual capacity and relies on another, unspecified text for the claim about AWS.