Carbon-aware computing shifts when and where compute workloads run so they draw more electricity from low-carbon sources on the grid. Using real-time carbon-intensity signals from providers such as WattTime and Electricity Maps, schedulers delay flexible jobs to cleaner hours or route them to lower-carbon regions, cutting the emissions of computing without needing new hardware.
| Approach | Temporal shifting (shift in time) | Spatial shifting (shift in place) |
|---|---|---|
| What moves | Job start time, within the same region | Job location, across regions or data centers |
| Typical trigger | Forecasted carbon intensity drop in the next few hours | Another available region currently has lower carbon intensity |
| Best suited for | Batch jobs, backups, non-urgent reports, delayable training runs | Async workloads with no data residency or latency constraint |
| Common enabler | Carbon-aware schedulers reading day-ahead forecasts | Multi-region orchestration plus a carbon-intensity API |
| Main constraint | Deadline tolerance of the workload | Data gravity, latency, and regulatory residency requirements |
What Carbon-Aware Computing Actually Is
Carbon-aware computing is the practice of adjusting when and where software runs so that it consumes electricity when the grid supplying it is cleaner. It is distinct from simple energy efficiency, which reduces the total amount of electricity a workload uses. Carbon-aware computing instead treats electricity as a variable-quality input: the same kilowatt-hour of compute can carry a very different emissions cost depending on whether the local grid is running on hydro and wind at that moment or on wind-starved fossil generation covering an evening demand peak.
This distinction matters because grid carbon intensity, the amount of carbon dioxide equivalent emitted per unit of electricity generated, is not static. It changes hour by hour and region by region as renewable generation from solar and wind fluctuates with weather and daylight, and as grid operators bring fossil-fuel peaker plants online to cover demand spikes. A data center in the same location, running the exact same workload, can have a meaningfully different carbon footprint depending on the hour it chooses to run that workload. Carbon-aware computing is the discipline of exploiting that variability deliberately rather than ignoring it.
The concept sits inside the broader GreenOps movement, which applies FinOps-style operational discipline to environmental impact rather than dollar cost. Readers who want the fuller organizational picture of how sustainability metrics get embedded into cloud operations should see our companion piece on GreenOps, while this article focuses specifically on the mechanics of shifting compute in time and place.
Why Grid Carbon Intensity Varies So Much
Electricity grids blend generation sources continuously to meet demand, and that blend shifts constantly. A region with abundant hydropower or a strong wind resource can see its grid carbon intensity swing from very low in the middle of the night, when wind output is high and demand is low, to considerably higher in early evening, when solar generation drops off just as household and commercial demand peaks. Google’s own reporting on its carbon-aware computing program describes tracking an hourly carbon-free energy percentage for each of its cloud regions specifically because annual averages hide this volatility. A region can be matched to 100 percent carbon-free energy on an annual accounting basis while still running on a much dirtier hourly mix during certain peak windows.
Grid mix also varies enormously by geography. Regions with heavy hydro or nuclear baseload, such as parts of Quebec or the Nordics, sit consistently near the low end of grid carbon intensity, while regions still dependent on coal or gas peaker capacity sit much higher, and the gap between the cleanest and dirtiest available regions for a given cloud provider can be an order of magnitude in emissions per unit of compute.
Figure 1: Grid carbon intensity across a typical day
A line chart plotting grid carbon intensity in grams of carbon dioxide equivalent per kilowatt-hour across a 24-hour period, showing a trough overnight when wind generation is high and demand is low, a moderate rise through the morning, and a sharp peak in early evening as solar output falls while demand from homes and businesses climbs, illustrating the window a temporal-shifting scheduler would target.
The Data Layer: Carbon-Intensity APIs
Carbon-aware scheduling only works if software can query current and forecast grid carbon intensity programmatically. Two providers dominate this space. WattTime supplies real-time, forecast, and historical marginal emissions data for electric grids globally, with a marginal-emissions focus that estimates the emissions impact of the next unit of demand rather than the average generation mix, which matters because shifting load changes what the grid dispatches at the margin. Electricity Maps provides a comparable signal along with a widely used public visualization of live grid carbon intensity by country and region, and both providers publish day-ahead forecasts so schedulers can plan shifts before the low-carbon window even arrives rather than reacting to it in real time.
The open-source Carbon Aware SDK, and similar tooling built on top of it, standardizes access to these signals so an application does not need a separate integration for every carbon-intensity provider or every cloud region. That abstraction layer is what has allowed carbon-aware scheduling to move from research papers into production tooling relatively quickly, since teams can swap the underlying data provider without rewriting the scheduling logic sitting on top of it.
| Component | Role | Example |
|---|---|---|
| Carbon-intensity API | Supplies real-time and forecast grid carbon data | WattTime, Electricity Maps |
| Abstraction SDK | Normalizes API access across providers and regions | Carbon Aware SDK |
| Cluster-level exporter | Surfaces carbon intensity as a Kubernetes-native signal | Kubernetes Carbon Intensity Exporter operator |
| Autoscaler integration | Adjusts replica counts or pauses jobs based on carbon signal | Carbon-aware KEDA operator |
| Power telemetry | Measures actual energy draw of running workloads | Kepler (Kubernetes Efficient Power Level Exporter) |
Carbon-Aware Kubernetes Schedulers
Kubernetes has become a natural home for carbon-aware scheduling because it already treats workload placement as a solvable optimization problem. Adding carbon intensity as another scheduling signal, alongside CPU, memory, and existing affinity rules, fits the same model rather than requiring a new orchestration layer. The most common production pattern uses KEDA, the CNCF-hosted Kubernetes event-driven autoscaler, extended with a carbon-aware operator that adjusts a scaled object’s maximum replica count based on current carbon intensity pulled from a ConfigMap populated by a carbon-intensity exporter. When intensity crosses a defined threshold, the operator can scale flexible workloads toward zero, effectively pausing them until the grid signal improves, then scale back up automatically once conditions clear.
This pattern deliberately targets workloads that can tolerate delay: batch data processing, backup jobs, non-urgent analytics pipelines, and staging or test environment runs that are not user-facing. It is a poor fit for latency-sensitive production traffic, which is why carbon-aware scheduling in Kubernetes is almost always deployed selectively, on a labeled subset of jobs, rather than applied cluster-wide. The same interruption tolerance that makes a workload a good candidate for carbon-aware scheduling also tends to make it a good candidate for spot capacity, so teams often layer both cost and carbon signals into the same scheduling decision; our guide to spot instance strategies for batch and training workloads covers the cost side of that same class of interruptible jobs.
Kepler, a CNCF project that estimates the power consumption of Kubernetes workloads at the pod level using hardware counters and machine learning models, complements carbon-aware scheduling by closing the measurement loop. Scheduling decisions based only on grid carbon intensity tell you when to run something cleanly; power telemetry from a tool like Kepler tells you how much energy that workload is actually consuming, which is the other half of the emissions calculation and increasingly feeds into the broader energy reporting layer for data center power constraints planning.
Demand Shifting in Practice: Two Strategies
Temporal shifting
Temporal shifting delays a workload’s start time within the same region, targeting a forecasted low-carbon window a few hours later rather than running immediately. It works well for jobs with a soft deadline measured in hours rather than minutes: nightly ETL jobs, model retraining runs that need to finish by morning rather than immediately, and report generation that only needs to be ready before business hours. Google’s carbon-intelligent computing platform, one of the earliest production deployments of this idea at scale, reserves and uses compute capacity on the cleanest available grids by moving flexible compute jobs to the time of day when the local carbon-free energy percentage is highest.
Spatial shifting
Spatial shifting routes a workload to a different geographic region entirely, choosing wherever the carbon intensity is currently lowest among the regions where the job is permitted to run. This strategy delivers larger potential carbon savings than temporal shifting alone, since the gap between the cleanest and dirtiest available region at any given moment is often wider than the gap between the cleanest and dirtiest hour in a single region. It is also the harder strategy to deploy broadly, because it inherits every constraint already associated with multi-region architecture: data residency law, cross-region latency for anything user-facing, and the egress costs of moving data between regions to reach the compute. Our piece on egress fees and data gravity covers why data often cannot simply follow the cleanest grid the way stateless compute can.
Figure 2: Decision path for choosing a demand-shifting strategy
A simple flowchart starting from a candidate workload, first asking whether the job tolerates a delay of several hours; if yes, it routes to temporal shifting within the current region. If the job instead has no data residency or latency constraint and can run anywhere, it routes to spatial shifting across regions. Workloads that fail both checks, being both latency-sensitive and undelayable, are marked as not currently suitable for carbon-aware scheduling.
Where Carbon-Aware Computing Meets FinOps
Cost and carbon signals frequently point in the same direction, because off-peak electricity and off-peak cloud pricing often correlate, and interruptible, delay-tolerant workloads are exactly the same population of jobs that both spot-pricing strategies and carbon-aware schedulers target. Organizations building out a FinOps practice increasingly find that the Optimize-phase tooling they already built for rightsizing and commitment discounts can be extended with a carbon dimension relatively cheaply, since the underlying scheduling and tagging infrastructure overlaps substantially. This convergence is one reason GreenOps is often described as FinOps’s environmental sibling rather than a separate discipline built from scratch.
AI training workloads are a particularly visible case, since a single large training run can concentrate enormous, delay-tolerant compute demand into a period of days or weeks, and often the training schedule has meaningful flexibility in exactly when it starts. Our analysis of inference versus training economics covers why training workloads, unlike most inference serving, are usually the best-suited AI workload category for both spot capacity and carbon-aware scheduling.
Common mistake
Applying carbon-aware scheduling to latency-sensitive, user-facing services. Delaying an API response by even a few minutes to wait for a cleaner grid window breaks the user experience the service exists to provide. Carbon-aware scheduling should be scoped to workloads that were already interruption-tolerant before carbon became a consideration, not stretched to cover traffic that cannot absorb delay.
Common mistake
Relying on annual or monthly carbon-free energy averages to make real-time scheduling decisions. An annual figure can look reassuring while hiding sharp hourly swings; a region reported as mostly carbon-free on paper can still have several hours a day running on a much dirtier marginal generation mix, and a scheduler using stale or averaged data will miss exactly the windows it was built to find.
Common mistake
Treating spatial shifting as a free lever without accounting for data gravity. Moving compute to a cleaner region often means moving or replicating data as well, and the egress costs and latency penalties of doing so can outweigh the carbon benefit, especially for workloads that need to read large datasets repeatedly rather than once.
What worked
Teams that got the most durable results scoped carbon-aware scheduling to a clearly labeled subset of workloads from day one, typically batch analytics, CI or test environment runs, and non-urgent model retraining, rather than attempting a cluster-wide rollout. They paired a carbon-intensity exporter feeding a Kubernetes ConfigMap with an existing autoscaler such as KEDA, so the carbon signal plugged into scheduling infrastructure the platform team already operated and trusted, rather than introducing an entirely new scheduling system. Measuring actual power draw with a tool like Kepler alongside the carbon signal let them report real emissions avoided rather than an estimated figure, which made the case for expanding scope to more workloads far easier to make internally.
Measuring and Reporting Impact
Carbon-aware computing claims are only credible when backed by a consistent measurement standard. The Green Software Foundation’s Software Carbon Intensity specification defines a standardized way to calculate the carbon emissions of a piece of software per unit of useful work, combining operational energy consumption, the carbon intensity of the electricity used, and embodied emissions from the hardware itself. Adopting a shared standard like this matters because it lets a carbon-aware scheduling initiative report its avoided emissions in a way that can be compared across teams, providers, and time periods, rather than each team inventing its own accounting method that nobody else can verify or reproduce.
Reporting should separate two distinct benefits that carbon-aware computing delivers: emissions avoided through better timing and placement of a fixed amount of work, and emissions avoided through genuine efficiency gains that reduce the total amount of energy a workload consumes regardless of when it runs. Conflating the two overstates the impact of scheduling changes alone and can mask the fact that the underlying workload might still be wasteful on hardware or software efficiency grounds, a gap covered in more depth in our related piece on sustainable AI infrastructure.
- Carbon intensity
- The amount of carbon dioxide equivalent emitted per unit of electricity generated on a given grid, typically expressed in grams of carbon dioxide equivalent per kilowatt-hour.
- Marginal emissions
- The emissions impact of the next unit of electricity demand on a grid, as opposed to the average emissions of all generation currently supplying that grid.
- Temporal shifting
- Delaying a workload’s execution within the same location to a forecasted period of lower grid carbon intensity.
- Spatial shifting
- Routing a workload to a different geographic region or data center where grid carbon intensity is currently lower.
- Carbon-free energy percentage
- A measure of how often, on an hourly basis, a given location’s electricity supply came from carbon-free sources, distinct from an annual carbon-free energy match.
- Demand response
- The broader practice of adjusting electricity consumption in response to grid conditions, of which carbon-aware computing is a compute-specific application.
- Software Carbon Intensity
- A Green Software Foundation specification for calculating the carbon emissions of software per unit of useful work performed.
- Carbon-aware scheduler
- A workload scheduler that uses real-time or forecast grid carbon-intensity data as an input to decide when and where a job runs.
Key Takeaways
- Carbon-aware computing shifts workloads in time or place to align with lower grid carbon intensity, distinct from energy efficiency, which reduces total consumption.
- Grid carbon intensity varies significantly by hour and by region, which is why annual carbon-free energy averages can mislead real-time scheduling decisions.
- WattTime and Electricity Maps are the two dominant carbon-intensity data providers, both offering real-time and day-ahead forecast signals.
- Temporal shifting delays a job within the same region to a cleaner hour; spatial shifting moves a job to a cleaner region entirely, with larger potential savings but harder constraints.
- Carbon-aware Kubernetes scheduling typically works through a carbon-intensity exporter feeding an autoscaler such as KEDA, scoped to interruption-tolerant workloads.
- Kepler and similar power-telemetry tools close the measurement loop by reporting actual energy consumption alongside scheduling decisions.
- Carbon-aware computing and FinOps overlap heavily because delay-tolerant, interruptible workloads are the same population targeted by both spot-pricing and carbon-aware strategies.
FAQs
What is carbon-aware computing?
Carbon-aware computing is the practice of shifting when and where compute workloads run so they draw electricity from lower-carbon sources on the grid. It uses real-time and forecast carbon-intensity data to delay flexible jobs to cleaner hours or route them to cleaner regions, reducing emissions without requiring new hardware or reduced total energy use.
How is carbon-aware computing different from energy efficiency?
Energy efficiency reduces the total amount of electricity a workload consumes. Carbon-aware computing instead changes when and where that same electricity is drawn, targeting periods and locations where the grid mix is cleaner. The two approaches are complementary and are often measured together using standards like the Software Carbon Intensity specification.
What data sources provide grid carbon intensity?
WattTime and Electricity Maps are the two most widely used providers, both offering real-time, historical, and day-ahead forecast carbon-intensity data for electric grids globally. WattTime emphasizes marginal emissions data, while Electricity Maps also provides a widely referenced public visualization of live grid carbon intensity by country and region.
Which workloads are best suited to carbon-aware scheduling?
Batch processing, backup jobs, non-urgent analytics pipelines, staging and test environment runs, and delay-tolerant model training are the best candidates because they can absorb a delay of hours without affecting users. Latency-sensitive, user-facing services are generally unsuitable because any scheduling delay directly degrades the experience they provide.
How does carbon-aware scheduling work in Kubernetes?
The common pattern uses a carbon-intensity exporter that writes current grid data into a Kubernetes ConfigMap, paired with an autoscaler extension such as a carbon-aware KEDA operator that adjusts a workload’s maximum replica count based on that signal, scaling flexible jobs down when carbon intensity is high and back up once it improves.
What is the difference between temporal and spatial shifting?
Temporal shifting delays a workload within the same region to a forecasted cleaner hour. Spatial shifting instead moves the workload to a different region that currently has lower carbon intensity. Spatial shifting can deliver larger savings but faces more constraints, including data residency requirements, latency, and cross-region data transfer costs.
Does carbon-aware computing save money as well as emissions?
Often, yes, because the same interruption-tolerant workloads that suit carbon-aware scheduling also suit spot-priced capacity, and off-peak electricity frequently correlates with off-peak cloud pricing. Many organizations layer carbon and cost signals into the same scheduling decision rather than building two separate systems for what is largely the same population of flexible jobs.
How do teams measure the impact of carbon-aware computing?
Credible measurement separates emissions avoided through better timing and placement from emissions avoided through genuine efficiency gains, and increasingly uses a shared standard such as the Green Software Foundation’s Software Carbon Intensity specification so results can be compared consistently across teams, providers, and time periods rather than through ad hoc calculations.
References
- WattTime, Marginal Emissions Data and Load Shifting
- Electricity Maps, Developer Hub API Documentation
- Google, Carbon-Aware Computing Location Shifting
- Google Cloud, Carbon-Free Energy Percentage by Region
- Green Software Foundation, Software Carbon Intensity API-Based Guidance
- Azure, Carbon-Aware KEDA Operator
