What is carbon-aware computing and how to schedule for it

Carbon-aware computing is the practice of scheduling flexible workloads to run at the times, and in the regions, when the electricity grid is cleanest. The idea rests on a simple fact about grids: their carbon intensity changes hour by hour as wind, solar, and demand rise and fall, so the same job emits more carbon at 7pm on a gas-heavy evening than at noon on a sunny, windy afternoon. A workload that does not need to run right now, such as a nightly batch job or a model-training run, can be shifted into a cleaner window for the same output at a lower carbon cost. It is the timing companion to placement, covered in how to choose low-carbon cloud regions, and a core technique in any GreenOps program.

This article is part of our complete guide to cloud sustainability and GreenOps, the cluster pillar it links up to.

What signal does carbon-aware computing use?

Carbon-aware computing uses a carbon-intensity signal, a real-time measure of how clean the grid is, supplied by services such as WattTime and Electricity Maps. The cleanest way to consume these signals is through the Green Software Foundation Carbon Aware SDK, a tool that wraps these data sources behind one interface and returns the region or time window with the lowest carbon intensity. Centralizing the logic in the SDK keeps it observable and auditable rather than scattered across jobs.

There are two kinds of signal, and the difference matters. Average carbon intensity is the emissions per unit of all the electricity on the grid at a given moment, which Electricity Maps provides. Marginal carbon intensity is the emissions of the next unit of demand your workload would add, which WattTime provides. For deciding when to run additional load, marginal intensity is the more accurate signal, because it reflects which power plant actually ramps up to serve your job.

How does it relate to the SCI standard?

Carbon-aware computing is one of the levers that reduces a workload's Software Carbon Intensity, or SCI, the standardized measure of carbon emitted per unit of software work. SCI is now an international standard, ISO/IEC 21031:2024, developed by the Green Software Foundation. It gives teams a consistent way to score an application's carbon and compare design choices, and carbon-aware scheduling is a direct way to drive that score down for the flexible portion of a workload. Where rightsizing reduces the energy a job uses, carbon-aware scheduling reduces the carbon per unit of that energy by running it on cleaner power.

How do I schedule a workload for it?

Schedule for carbon-aware computing by routing flexible jobs through a carbon signal and running them in the cleanest window within their deadline. The method:

1. Identify the flexible workloads. List the batch jobs, training runs, data pipelines, and report generation that can tolerate a delay or a different region without breaking a deadline. Real-time, user-facing work is not a candidate.
2. Connect a carbon-intensity signal. Use a marginal source such as WattTime, or an average source such as Electricity Maps, ideally through the Carbon Aware SDK so the logic is centralized.
3. Set the scheduling rule. Define a rule that runs the job in the cleanest window within its deadline, or shifts it to a cleaner region, while respecting cost and latency limits.
4. Wire it into the scheduler. Trigger jobs from the carbon signal through your existing batch scheduler, queue, or orchestration platform so the behavior is consistent and auditable.
5. Measure the avoided emissions. Track the carbon avoided by running in clean windows versus a naive schedule, and report it next to cost.

The discipline of identifying which work is genuinely flexible is where most of the value is decided, because scheduling something that actually needed to run now just adds latency for no benefit. Getting that classification right across an estate is part of the governance a FinOps implementation puts in place.

Is it worth the effort?

Carbon-aware scheduling is worth it when you have a meaningful volume of flexible, deferrable compute, and less so when almost everything is real-time and latency-bound. For an estate with large nightly batch windows, heavy data pipelines, or substantial model training, the avoided emissions can be significant and the engineering cost is modest once the signal is wired in. For a purely interactive workload with no deferrable jobs, the lever has little to grip, and the effort is better spent on rightsizing and region choice. As with every GreenOps move, start by measuring where the flexible compute actually is.

Common questions about carbon-aware computing

What is carbon-aware computing?

Carbon-aware computing is the practice of running flexible workloads at the times and in the regions when the electricity grid is cleanest. It uses real-time carbon-intensity signals to shift batch and deferrable jobs into low-carbon windows, reducing emissions without changing the amount of compute done.

What is the difference between marginal and average carbon intensity?

Average carbon intensity is the emissions per unit of all electricity on the grid right now; Electricity Maps provides this. Marginal carbon intensity is the emissions of the next unit of demand your workload would add; WattTime provides this, and it is the better signal for deciding when to run additional load.

Does carbon-aware scheduling save money?

Not directly. Carbon-aware scheduling targets emissions, not cost, though it can pair with spot pricing or off-peak rates that happen to align with cleaner grid times. Treat it as a carbon lever that complements, rather than replaces, the cost levers such as rightsizing.

Written by Fredrik Filipsson and reviewed by Morten Andersen, applying our See, Cut, Lock, Run method. Independent and vendor neutral.