Cloud Computing's Efficiency Miracle Is Also Its Throttling Machine

Based on the research ofYing-da, Stinchcombe and Whinston, "Strategic Throttling in Large Cloud Computing Platforms," Information Systems Research, 2026

Cloud economics run on a simple bet: if you aggregate enough unrelated workloads, a retailer's holiday traffic spike, a university's batch job, a startup's dev environment, a bank's overnight reconciliation, their demand for computing time stops looking chaotic and starts looking like a predictable curve. That predictability is the entire reason cloud computing is cheaper than everyone running their own data center. A provider that can forecast aggregate demand with confidence doesn't need to hold as much idle backup capacity "just in case." Pooling is the efficiency engine of the entire industry.

New research from Information Systems Research argues that this same predictability is not just an efficiency story. It is also what makes throttling low-tier customers a safe, repeatable business decision rather than a risky one. Ying-da, Stinchcombe and Whinston's "Strategic Throttling in Large Cloud Computing Platforms" models how large cloud providers use both price and service quality, slower processing, higher interruption risk, to sort customers by willingness to pay and delay sensitivity, while keeping the whole market served. The paper's core claim is uncomfortable precisely because it isn't a story about bad actors: the very pooling that lowers everyone's costs is what tells a provider, with statistical confidence, exactly how much service degradation a given customer segment will tolerate before it leaves.

Predictability Is a Two-Sided Tool

Think about what a cloud provider actually knows once it has pooled millions of workloads. It knows, within a tight confidence interval, how much spare capacity will exist at 3 a.m. on a Tuesday versus during a product launch. It knows which customer segments are latency-sensitive and which are batch-tolerant. That knowledge is what lets the provider run leaner, fewer idle servers, higher average utilization, lower marginal cost per compute-hour. That's the version of the story everyone likes.

But the same knowledge answers a second question the provider is equally motivated to ask: how much can a discount-tier customer be slowed down, or how often can their instance be interrupted, before they defect to a competitor or upgrade to a pricier tier? Once utilization is predictable, degrading service for low-tier customers is no longer a gamble, it's a calibrated policy. The provider isn't guessing how much a given workload can absorb; the pooled data tells it. This is the mechanism the paper formalizes: predictability that lowers cost also lowers the risk of price-and-quality discrimination, because the provider can throttle just enough to extract more from delay-tolerant, price-sensitive customers without pushing them out of the market entirely.

Spot Instances Show the Mechanism in Daylight

You don't need a theoretical model to see this dynamic, the major clouds sell it as a named product. AWS EC2 Spot Instances let customers rent unused compute capacity at a discount of up to 90% compared to On-Demand pricing, but AWS can reclaim that capacity essentially at any time, giving the customer a two-minute warning delivered through the instance metadata service or an EventBridge event before termination. Reserved Instances, at the other end of the spectrum, offer steadier discounts, commonly cited at up to roughly 72% off On-Demand, in exchange for a one- or three-year commitment and none of Spot's interruption risk. Google Cloud runs the same structure under a different name: Spot VMs offer discounts of 60% to 91% off on-demand pricing, with a preemption notice of only about 30 seconds before the instance can be reclaimed.

None of this is a secret or a bug. It's an explicit, published tiering system: pay more for guaranteed continuity, pay less and accept that your workload can be paused or killed when the provider needs the capacity elsewhere. That tiering only works at scale because the provider can predict, in aggregate, how much Spot capacity it can sell without jeopardizing service for On-Demand and Reserved customers. Pooling is what makes the discount safe to offer, and what makes the interruption safe to impose. The efficiency and the throttling are computed from the same demand curve.

The efficiency that makes cloud computing cheap and the throttling that makes it profitable are outputs of the same forecast.

Why the Squeezed Customer Doesn't Just Leave

Textbook competition should erode this arrangement, if a provider degrades service for underpaying customers, those customers should switch to a rival. In cloud computing, they mostly don't, and the reasons are well documented outside the theoretical literature. The UK Competition and Markets Authority spent roughly two years investigating the cloud infrastructure market and published its final decision report in July 2025, concluding that competition in UK cloud services "is not working well." It found that AWS and Microsoft Azure each account for somewhere between 30% and 40% of UK cloud spend, and that egress fees, technically incompatible architectures, and restrictive licensing terms combine to produce a durable lock-in effect, enough that the CMA recommended pursuing Strategic Market Status designations against the two largest providers.

Egress fees, the charges providers levy for moving your own data off their platform, have been one of the most concrete, quantifiable pieces of that lock-in story, which is exactly why regulators targeted them directly. Google Cloud announced in January 2024 that it would waive data-transfer-out fees for customers switching providers, a move that landed on the same day the EU's Data Act came into effect. AWS followed in March 2024 with its own free data-transfer-out policy for customers migrating away, and Microsoft Azure announced a similar policy shortly after. The EU Data Act itself, which entered into force in January 2024 and has applied since September 12, 2025, goes further on a delayed timeline: it caps what providers can charge for switching to only cost-covering amounts in the near term, and bans switching charges, including egress fees, outright starting January 12, 2027.

That regulatory sequence is worth sitting with, because it shows the limits of attacking lock-in at the fee level. Egress fees were always the most visible, most quotable piece of switching cost, a line item journalists and regulators could point to. But the paper's framing suggests fees were never the root cause; they were a convenient lever built on top of the deeper mechanism. Even with egress fees at zero, a customer whose workload architecture, APIs, and data schemas are proprietary to one provider's ecosystem still faces enormous switching costs that have nothing to do with a transfer bill. Waiving the fee removes one friction point while leaving the structural one, pooling-driven predictability plus ecosystem lock-in, fully intact.

What Actually Bends the Incentive

If throttling and efficiency share a root cause, then policies that only target the throttling symptom, capping a specific fee, mandating a specific SLA, will keep getting outflanked by whichever lever is left standing. The paper's own suggested remedies point toward the structural layer instead: cross-region pooling that spreads predictability benefits without concentrating discretion in one provider, transparent interruption policies that let customers price in risk accurately, and auction-based spot pricing that turns an opaque discretionary decision into a visible market-clearing signal.

None of these levers touches the thing that makes the whole system work in the first place: pooling. Nor should it. Pooling uncorrelated workloads is genuinely what makes cloud computing more efficient than the alternative of every firm running its own servers, that part of the story is real and worth preserving. The policy target isn't the forecasting; it's making sure the forecast's benefits and its leverage don't both accrue exclusively to the provider. Portability, interoperability, and switching-cost reduction are ways of giving customers a credible outside option without asking providers to pool less. Whether regulators can move fast enough to make that outside option real before the next architecture shift creates fresh lock-in is the open question the CMA, the European Commission, and now this research are all converging on from different directions.