Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud Contracts Now Include GPU Power Capping
Transcript
- Lucas: So it's mid-June 2026, and I just finished reviewing a new enterprise cloud agreement from one of the big three providers. And there's a clause in it I hadn't seen before — something called a 'GPU power capping allowance.' Luna: Power capping? As in, the cloud provider can dial down the juice to your GPUs? Lucas: Exactly. During peak grid demand events — think a heatwave in Northern Virginia or a cold snap in Dublin — the provider reserves the right to cap the power draw of your GPU instances. Not shut them off. Cap them. Typically at a percentage like 70 percent of max rated power. Luna: That's dramatic. I mean, a single NVIDIA H100 can pull 700 watts under full load. The new B200 is pushing toward a kilowatt. If you cap that by 30 percent, you're cutting performance too, right? Lucas: You are. But the interesting part is how non-linear that trade-off is. NVIDIA's own power management curves show that dropping from 100 percent to 70 percent power reduces performance by only about 15 percent for most large language model training workloads. The GPU just becomes more efficient at the lower voltage-frequency point. Luna: So you lose fifteen percent throughput, but the data center sheds thirty percent of the electrical load. That's a net win for the grid operator during a spike. But for the customer running a training job that costs fifty thousand dollars an hour, that fifteen percent could mean missing a model deadline. Lucas: Right, and that's the tension. The clause I saw was written specifically for what they call 'ai optimized instance families' — the P5 and P6 instances on AWS, the nd series on Azure, the A3 instances on GCP. These are the racks filled with H100s and B200s, and they're incredibly power-dense. Luna: How power-dense are we talking? Lucas: A standard data center rack used to draw maybe five to ten kilowatts. Now, with eight B200 GPUs per server and four servers per rack, you're looking at thirty-two kilowatts per rack — and that's before networking and cooling. Some hyperscaler deployments are hitting fifty kilowatts per rack. That's tripling the power density in less than three years. Luna: So the grid wasn't built for this. And the cloud providers are basically writing themselves an escape hatch in the contract so they don't have to say 'sorry, we're turning off your GPUs' — instead they just cap them. Lucas: Exactly. And it's not just a theoretical clause. In early 2025, during a major winter storm that hit the data center corridor in Ashburn, Virginia, one provider reportedly invoked a similar — though less formal — power reduction across several customer clusters. The difference now is that it's being codified into the contract with clear terms: when it can happen, by how much, and with what notice. Luna: What kind of notice are we talking? An hour? A day? Lucas: The agreement I saw said 'commercially reasonable efforts to provide four hours advance notice.' But there's a carve-out for emergency grid events where they can act immediately. And here's the kicker: there's no service credit if your job fails because of a power cap. It's explicitly excluded from the availability SLA. Luna: That's a big change. For years, cloud SLAs have been about uptime — can you reach the instance? Now we're talking about quality of service during the run. A running instance that's throttled is technically available, but it's not delivering the performance you paid for. Lucas: Right. And the pricing model hasn't adjusted yet. You're still paying the full per-hour rate for a capped instance. So the question becomes: how do you architect around this? Some enterprises are already building checkpointing into their training pipelines so that if a power cap drops performance below a threshold, they can save state and spin up in a different region. Luna: Which adds latency and complexity. And it only works if the job is designed to be preemptible. If you're running a multi-week training run with inter-dependent steps, checkpointing every thirty minutes might not be enough. Lucas: That's exactly why some of the bigger AI labs are now negotiating carve-outs. They're agreeing to higher base compute prices in exchange for an exemption from power capping. I heard of one deal where a major lab pays a fifteen percent premium on their reserved instances to get a 'no power cap' rider. Luna: So the market is segmenting. The hyperscalers are effectively selling two tiers of GPU compute: capped and uncapped. If you can tolerate the occasional performance hit, you pay less. If your workload is zero-tolerant, you pay a premium. Lucas: Which is actually a rational market response. But it also creates a new headache for cloud architects. Now you not only have to think about instance type, region, and spot versus on-demand — you also have to think about power-capping tier. And you have to model the probability of a cap event in that region during your training window. Luna: Which brings in weather data, grid reliability data, even local utility rate structures. That's a whole new dimension of capacity planning. And it's happening because the grid is the new bottleneck for AI expansion. Lucas: If these conversations are useful for what you're building or running, we do this show ad-free and listener-supported. If you find yourself nodding along, you can toss a little something in the bucket at buy me a coffee dot com slash fexingo. No pressure — just helps us keep the lights on, or in this case, the GPUs powered. Luna: Yeah, we really appreciate that. And it goes right back into making sure we can cover emerging stuff like this before it's common knowledge. Lucas: Alright — back to power capping. One mitigation strategy I'm seeing is on-site battery storage. Some of the newer data centers are installing large battery banks that can buffer the facility during grid spikes, so the provider doesn't have to cap instances as often. Luna: So instead of capping your GPUs, they draw from batteries for fifteen minutes while the grid stabilizes. That's better for the customer, but it adds capital cost. Who pays for that? Lucas: That's the open question. In some of the newer builds, the hyperscaler is amortizing the battery cost across the facility and passing it through in the base power rate. But in existing data centers, retrofitting batteries is expensive. So those facilities are more likely to use the power cap clause. Luna: So geography matters too. A data center in a region with a stable grid and cheap renewables might never invoke the cap. One in a region with aging infrastructure and peak demand events might invoke it several times a year. Lucas: Exactly. And that's starting to influence where enterprises place their long-term training workloads. We're seeing a shift away from the traditional hotspots — Northern Virginia, Dublin, Singapore — toward regions with more grid headroom, like Ohio, Spain, and parts of Scandinavia. Luna: But those regions often have less fiber connectivity, fewer peering points. So you trade off network latency for power reliability. It's another multi-dimensional problem. Lucas: Right. And the clause I saw actually includes a provision for the provider to offer 'alternative region credits' if a customer wants to move workloads out of a region that's experiencing repeated cap events. So they're acknowledging it's a problem and building in an escape route. Luna: That's surprisingly customer-friendly. Usually these contracts are all about limiting provider liability. Lucas: It is. I think the hyperscalers recognize that if they don't offer some flexibility, the largest AI customers will start building their own data centers. And that's a much bigger threat to their business than writing a reasonable power-capping clause. Luna: So where does this go in the next year? Do we see regulators getting involved? Lucas: I think we'll see utility regulators start asking questions about how data centers are managing demand response. Some states are already offering incentives for facilities that can reduce load on request. The power cap clause is essentially a private-sector version of that. But if it becomes too common, regulators might step in to mandate minimum performance standards. Luna: Or they might mandate that cloud providers disclose the historical frequency of cap events per region, so customers can make informed decisions. Lucas: That would be a logical next step. And I suspect some of the larger cloud buyers are already pressuring providers to publish that data as part of the contract negotiation. Right now it's still opaque, but transparency is coming. Luna: Good. Because if I'm spending eight figures a year on GPU compute, I want to know the odds that my training run gets throttled mid-July when everyone cranks up the AC. Lucas: Exactly. And that's the kind of question that keeps cloud architects up at night. Power capping is here to stay. The only question is how well we design around it. Luna: Alright, next episode we're looking at the new reserved-instance swap windows — how some providers now let you trade unused GPU capacity for spot credits. It's another contract evolution worth dissecting. Lucas: That's a good one. See you then.