Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud Contracts Now Include Carbon-Aware Scheduling
Transcript
- Lucas: So there's a new clause showing up in enterprise cloud contracts this year that I think changes the conversation about sustainability in the data centre. It's called carbon-aware scheduling. Luna: We've talked about carbon penalties and carbon credits in previous episodes. This sounds different. Lucas: Completely different. Penalties and credits are financial mechanisms after the fact. Carbon-aware scheduling is operational. The idea is simple: instead of running a batch job whenever the queue says go, you let the cloud provider delay it by a few hours until the regional grid has a lower carbon intensity. Luna: So the provider looks at the grid mix in real time and says, wait for more wind? Lucas: Exactly. AWS, Azure, and GCP all now publish near real time carbon intensity data per region. AWS has the Customer Carbon Footprint Tool with hourly granularity. Azure has the Microsoft Sustainability Manager and the Emissions Impact Dashboard. GCP has the Carbon Footprint API. They can tell you, hey, at 2 PM in us-east-1, the grid is 40 percent cleaner than at 10 AM because solar is peaking. So a contract clause that says, 'Customer agrees that up to 20 percent of non-critical workloads may be shifted to lower-carbon windows' is actually appearing in enterprise agreements now. Luna: And the customer gets a discount for agreeing to it? Lucas: Yes. That's the interesting part. It's not just a warm fuzzy green clause. The provider shares the cost savings from running during off-peak grid times. One manufacturing company I spoke with saved 18 percent on their compute bill last quarter by allowing carbon-aware scheduling for their batch simulation jobs. The simulations could tolerate a two to six hour delay. So they marked those workloads as 'flexible' in the contract, and the scheduler moved them to windows where grid carbon was below a certain threshold. Luna: But does that actually reduce overall carbon? Or does it just shift the load to a different hour, and the same amount of fossil fuel gets burned somewhere else? Lucas: That's the critical question. And the honest answer is: it depends on the grid. If the grid has a fixed baseload from coal or natural gas, shifting load by a few hours doesn't change the total fossil generation much. But grids with high renewable penetration — like California, Texas, or parts of Europe — actually ramp renewables up and down. Solar peaks midday, wind picks up overnight. When you shift load to those windows, you're soaking up generation that would otherwise be curtailed. So it does reduce the marginal carbon intensity of that compute. Luna: So it's region-dependent. A company with workloads in multiple regions would need to think about which ones can actually benefit. Lucas: Right. And the contract clauses are starting to reflect that. Some agreements let the customer choose a carbon intensity threshold — say, 300 grams of CO2 per kilowatt-hour — and the scheduler won't move workloads unless the grid falls below that. Others use a percentage-based approach: the provider commits to running at least 70 percent of flexible workloads during the lowest-carbon 25 percent of hours. Luna: That's pretty specific. Are these clauses standard yet, or still bespoke? Lucas: Still bespoke for the most part. I've seen them in about a dozen enterprise contracts this year, mostly from companies in the Fortune 500 that have public sustainability targets. The hyperscalers want to make this a standard offering, but they're cautious. They don't want to promise carbon reductions if the grid mix doesn't deliver. So the early adopters are companies with batch-heavy, latency-tolerant workloads — things like overnight data processing, machine learning training, financial risk simulations. Luna: What about latency-sensitive applications? A real-time fraud detection system can't wait two hours for the grid to get greener. Lucas: No, and nobody's proposing that. The clauses explicitly carve out 'critical' or 'latency-sensitive' workloads. The enforcement is at the workload level, not the account level. You tag your resources: 'scheduling-flexible: yes' or 'scheduling-flexible: no'. The provider's scheduler only touches the ones with the green light. Luna: So the architect has to explicitly designate which jobs are flexible. That's a design decision upfront. Lucas: Exactly. And it's actually a good forcing function. Companies start mapping their workload profiles: what can tolerate delay, what can't. That's valuable information beyond just carbon. It helps with capacity planning, cost optimization, and resiliency. Luna: I can see that. How do the providers actually calculate the savings? Is it a fixed discount, or variable? Lucas: Variable. Typically the discount is tied to the spot instance price or the interruptible instance price. If you're already using spot instances, the carbon-aware scheduling is layered on top. The provider may give an additional 5 to 15 percent discount depending on how much flexibility you grant. But it's not a simple percentage. Some contracts use a 'green multiplier' — the discount is higher during periods of low grid carbon intensity. Luna: So the provider has an incentive to shift load to green hours, and the customer gets a better price. That aligns incentives nicely. Lucas: It does. And it's a step beyond just buying carbon offsets. Offsets are important, but they're disconnected from the actual operation. Carbon-aware scheduling changes how and when compute happens. It's operational carbon efficiency. Luna: Are there any tools to help companies model this before signing the clause? Like, can they simulate what their savings and carbon impact would be? Lucas: Yes. All three major providers offer some kind of carbon modeling tool. AWS has the Carbon Footprint Simulator for estimating the impact of shifting workloads. Azure has a 'carbon optimization' section in the Sustainability Manager that lets you tag workloads and see projected savings. GCP has the 'Carbon-Aware Load Shifting' guide with sample code. One startup I know, Carbon Relay, actually builds a third-party layer that sits across providers and optimizes scheduling across multiple clouds based on real-time grid data. Luna: So this is becoming a multi-cloud consideration too. A company might shift a batch job from AWS us-east-1 to GCP us-west-1 if the grid is cleaner there at that hour. Lucas: Exactly. That's the next frontier. The current contract clauses are single-provider, but I've heard of enterprises asking for cross-provider carbon-aware routing in their multi-cloud agreements. That's harder to implement because you need real-time grid data from multiple regions and the ability to move data and compute quickly. But the interest is there. Luna: Let's talk about the grid data itself. Are the providers using the same data sources? Is there a standard? Lucas: Not exactly the same. AWS uses a mix of utility-provided data and grid operator emissions data. Azure integrates with the WattTime API, which provides real-time marginal emissions rates. GCP uses the Electricity Maps API. There's no single standard yet, but the differences are usually small. The bigger issue is data granularity: some regions report carbon intensity every five minutes, others every hour. The contract clauses I've seen specify a maximum data lag — typically 15 minutes — to ensure the scheduling decisions are based on reasonably current information. Luna: And what about data centers that have on-site renewables or battery storage? Does that affect the scheduling? Lucas: It can. Some hyperscaler data centers have behind the meter solar or batteries. If a data center has a battery that charges from the grid during low-carbon hours and discharges during high-carbon hours, the carbon intensity of compute during those hours is effectively lower. The contract clauses sometimes include a 'local renewable contribution' factor that adjusts the effective carbon intensity for that facility. But it's early days — most of the savings still come from grid-level timing. Luna: So the bottom line: for enterprises with significant batch workloads, carbon-aware scheduling is a real cost-saving and carbon-reduction lever. But it requires upfront architectural tagging and regional analysis. Lucas: Exactly. And it's a negotiation point now. If you're signing or renewing a cloud contract in 2026, ask for the carbon-aware scheduling clause. Even if you don't use it immediately, having the option is valuable. And the providers are competing on this — they want to show they're enabling green compute. Luna: I know we talk about contracts a lot on this show, but this one actually feels like a win-win. Lower costs, lower carbon, and the cloud provider gets to optimize their grid usage. Lucas: Yeah, it's one of those rare cases where the operational and the environmental incentives line up. And speaking of keeping this show independent and ad-free, this is a good example of the kind of deep-dive analysis we can do because we're listener-supported. A small group of listeners chips in monthly through buy me a coffee dot com slash fexingo, and that's what lets us spend the time tracking these contract changes. Luna: Yeah, it really does. We don't have advertisers to answer to, so we can follow the details that actually matter for operators and builders. Lucas: Right. And if you find these conversations useful for what you're building or running, that's the link. No pressure. Now, back to the scheduling mechanics — one more thing I want to mention about how providers handle the 'no-regret' moves. Luna: What do you mean by no-regret? Lucas: Some workloads can be shifted without any performance impact — like overnight data backups or report generation. Those are the easiest targets. But there's also a category of workloads that can be shifted during low-carbon hours and still meet their SLA if they're given a longer deadline. The contract clauses sometimes allow the provider to shift those workloads up to a maximum delay, say four hours, as long as the SLA is still met. That's where the real savings are. Luna: So the key is understanding your workload's true latency tolerance. Many companies overestimate how urgent their batch jobs are. Lucas: Exactly. And that's the architectural insight. By implementing carbon-aware scheduling, you're forced to actually measure and classify latency sensitivity. That pays dividends beyond carbon. So if you're a cloud architect, this is a good year to start tagging your workloads and running a pilot. Luna: Good advice. And with that, we'll wrap up this episode. Thanks for listening.