Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / How Cloud Contracts Now Mandate Carbon-Aware Instance Rights
Transcript
- Lucas: Luna, I was reading a master service agreement from a major cloud provider last night — don't ask me why — and I stumbled onto a clause that I think a lot of operators are going to encounter in their next renewal. It's called a carbon-aware instance right. Luna: That sounds like the provider gets to decide where and when your compute runs, based on carbon footprint. Am I in the ballpark? Lucas: You're exactly right. And it's not hypothetical. AWS, Azure, and GCP have all started including language that lets them shift your virtual machines to lower-carbon regions or time slots. The trigger is usually something like 'grid carbon intensity above a threshold.' Luna: So if the local grid is burning coal because of a heat wave, my workload might get migrated to a different availability zone — or even a different region — without me clicking 'yes'? Lucas: That's the gist. And the clause is typically buried in the 'service level agreements' appendix. I found a version that says the provider may 'relocate compute resources to alternative infrastructure' to meet carbon reduction targets. The customer gets notified, but they don't get a veto. Luna: I can see the legal team loving that. But what about performance? If my app is latency-sensitive — say, a trading platform — having my instances moved three hundred miles away could add milliseconds that matter. Lucas: That's the tension. And the providers know it. In Q1 of this year, AWS ran a pilot in its Oregon region where it shifted non-urgent batch jobs to overnight hours when the grid was cleaner. They published a case study claiming a twelve percent reduction in regional emissions. But they also noted that some customers saw a six percent increase in job completion time. Luna: Six percent on a batch job that runs for an hour is three and a half minutes. That might be fine for data analytics. But for a real-time inference pipeline? That's a dealbreaker. Lucas: Right. And here's where the contract language gets really specific. Some agreements carve out categories. 'Mission-critical' workloads might be excluded from carbon-aware scheduling, but you have to define them upfront. If you don't flag your production database as critical, it could get shifted. Luna: That's a classic gotcha. The onus is on the customer to know what's coming and opt out. If you're a mid-size company without a dedicated cloud architect reviewing every line of the MSA, you might miss it. Lucas: Exactly. And the providers frame it as a sustainability feature. They're helping you meet your own ESG goals. But the fine print also says that if your workload gets moved and performance degrades, the provider's service credit obligations are limited. They basically say 'we'll try, but no guarantees.' Luna: Let's talk about the measurement side. How do they even determine carbon intensity? Is it per data center, per grid region, per hour? Because if it's an average over a day, that's very different from real-time. Lucas: Great question. Azure, for example, uses something they call 'carbon-aware scheduling' that pulls data from the local grid operator's emissions API. They update every five minutes. Google Cloud has a similar system called 'carbon-aware load shifting' that works across their global fleet. But the contract doesn't specify the refresh rate. It just says 'based on available carbon data.' Luna: That's a loophole you could drive a truck through. 'Available' could mean once a day if that's all the provider has. And if the customer wants to audit the decisions, where do they even get the logs? Lucas: Most providers now offer a carbon dashboard — AWS has the Customer Carbon Footprint Tool, Azure has the Emissions Impact Dashboard. But those are retrospective. They show you what your emissions were last month. They don't show you the real-time decisions that were made about your instances. So you can't easily say 'hey, you moved my workload at 2 PM and my latency spiked.' Luna: It feels like we're entering an era where cloud contracts are becoming carbon-aware by default, and customers need to negotiate the terms just like they would for data residency or latency SLAs. This is a whole new dimension. Lucas: And that's exactly the angle for today. Episode sixty-seven of The Cloud Business Podcast. I'm Lucas. Luna: And I'm Luna. And Lucas, before we go deeper into the negotiation tactics, I want to mention something. We keep these episodes ad-free on purpose. No sponsors, no mid-roll interruptions. It's just the two of us working through what matters for people who build and run cloud infrastructure. Lucas: Yeah, and we hear from listeners that they appreciate that. If you find value in these conversations and want to support that approach, the link is buy me a coffee dot com slash fexingo. No pressure, just a way to keep this independent. Luna: Exactly. It helps us keep the focus on the substance. Now, back to those carbon-aware instance rights. Lucas, you mentioned a pilot in Oregon. What were the actual results for the customers? Lucas: So AWS published a blog post in March. They said that over a three-month period, they shifted about fifteen percent of eligible compute hours to lower-carbon windows. The average carbon reduction per shifted instance was around twenty percent. But here's the rub: customers who opted in — because it was opt-in for that pilot — were mostly running development and test environments. Production workloads were excluded by design. Luna: Interesting. So the pilot was cautious. But the contract language I've seen in new enterprise agreements doesn't make that distinction. It says 'all workloads' unless the customer specifically opts out. That's a big difference. Lucas: That's the shift. And I think it's driven by two forces. One, the providers have public carbon reduction targets — Amazon's Climate Pledge, Microsoft's 2030 negative emissions goal. Two, the SEC's climate disclosure rules are starting to require companies to report Scope 3 emissions, which include cloud usage. Providers want to be able to show that they're helping customers reduce their footprint. Luna: So from the provider's perspective, this clause is a feature. From the customer's perspective, it could be a risk. Let's talk about a concrete example. I spoke with a fintech company last week that runs high-frequency trading models on AWS in us-east-1. They have strict latency requirements. They're renegotiating their contract now, and this clause came up. Lucas: What did they do? Luna: Their cloud architect added a specific exclusion: any instance tagged as 'trading-prod' cannot be relocated for carbon reasons. They also negotiated a reporting requirement — the provider has to notify them within one hour if any instance is moved due to carbon-aware scheduling, even if it's not tagged. That way they can monitor for drift. Lucas: That's smart. And I've seen similar carve-outs for healthcare workloads that need to stay in a specific region for data residency. The key is to define your categories before the contract is signed. Because once it's signed, the provider has the right to move you unless you've explicitly reserved that control. Luna: And what about the cost side? Do customers get a discount for opting in? I've seen some providers offer a small credit — like two or three percent off compute — if you agree to carbon-aware scheduling by default. Lucas: Microsoft Azure has a program called 'Carbon Aware Compute Discount' that offers up to five percent off for workloads that are flexible. But the discount is only applied to the base compute rate, not to data egress or storage. So the actual savings might be smaller than it sounds. Still, for a large enterprise, five percent on a million-dollar monthly bill is real money. Luna: It is. But I wonder how many companies are doing the math. If you have workloads that are already running in regions with clean grids — like hydropower in the Pacific Northwest — the carbon benefit of shifting might be negligible. You could be giving up control for a discount that doesn't reflect your actual situation. Lucas: That's a great point. The carbon intensity of a grid varies by region and time. For example, in California, solar peaks at midday, so running compute then is cleaner than at night. But in the Midwest, where coal is still in the mix, the cleanest hours might be overnight when wind is blowing. A blanket policy doesn't account for that nuance. Luna: So what's your advice for someone who's about to sign a cloud contract and sees this clause for the first time? Lucas: First, don't ignore it. Treat it like any other operational constraint. Second, audit your workloads and classify them by latency sensitivity, data residency needs, and flexibility. Third, negotiate the opt-out categories explicitly. Fourth, ask for transparency — real-time notifications and logs of any relocation decisions. And fifth, if you do opt in, make sure the discount is tied to measurable carbon reduction, not just participation. Luna: And for the providers listening, if any are: clearer language would go a long way. Instead of 'may relocate based on carbon data', say 'may relocate based on real-time grid carbon intensity data updated every five minutes, with customer notification within 15 minutes'. That builds trust. Lucas: Absolutely. The technology is here to make carbon-aware scheduling work. The contracts just need to catch up. And as more companies face SEC disclosure requirements, I think we'll see carbon-aware clauses become standard — but also more transparent. It's an evolving area, and we'll keep tracking it. Luna: Good. Next time, maybe we dig into how these clauses interact with data sovereignty laws. Because if your workload gets moved to a region that doesn't meet your compliance requirements, that's a whole other problem. Lucas: That's a great angle. We'll add it to the list. For now, thanks for listening to The Cloud Business Podcast. We'll be back soon.