Carbon-Aware Computing: Reduce Emissions Without Rebuilding Everything
Table of contents
- Key takeaways
- The base concept
- Flexibility types
- Data sources: carbon-intensity APIs
- Implementation patterns
- Deferring batch jobs
- Routing workloads across regions
- Carbon-aware HPA in Kubernetes
- What the Green Software Foundation builds
- Real ROI cases
- Costs versus benefits
- Honest limitations
- Getting started
- Conclusion
- Sources
Updated: 2026-07-07
Carbon-aware computing runs flexible workloads when grid electricity emits less CO2, cutting emissions 10-30% without changing infrastructure. Grid carbon intensity varies up to 16x by hour and region; tools like Electricity Maps, WattTime and the Carbon Aware SDK make that scheduling possible with real grid data.
Carbon-aware computing is the idea that flexible workloads can run when and where the energy is cleaner. Grid carbon intensity varies by hour and region: running a batch job at night with high wind emits 3-5x less CO₂ than the same job at midday on natural gas. No hardware change, no app rewrite, just smart scheduling.
Key takeaways
-
Grid carbon intensity varies up to 16x between the best and worst scenario depending on zone and hour.
-
20-40% of an organization’s total compute is deferrable without any impact on end users.
-
The typical reduction is 10-30% CO₂ on flexible workloads with minimal effort.
-
The main tools are the Electricity Maps API, WattTime, and the Carbon Aware SDK from the Green Software Foundation.
-
Carbon-aware computing adds no cost in most implementations: the scheduling logic itself is trivial.
The base concept
The grid does not have constant carbon. Representative examples:
-
Night with strong wind: ~50-100 g CO₂/kWh.
-
Sunny day: ~100-200 g.
-
Peak demand covered with natural gas: ~400-500 g.
-
Coal-dependent zones: >800 g.
A workload that consumes 1 MWh:
-
In a clean zone at the optimal time: ~50 kg CO₂.
-
In a dirty zone at a bad time: ~800 kg.
A 16x difference by changing nothing except timing and location.
Flexibility types
Not every workload is flexible. A practical classification:
Time-flexible (deferrable with no user impact): batch processing and ETL, ML model training, data warehouse refreshes, backups and indexing.
Location-flexible (stateless, multi-region): stateless workloads with no data-residency constraints, pure compute tasks where the data itself can travel.
Not flexible: real-time user requests, real-time data streaming, OLTP transactions, control loops.
20-40% of an organization’s total compute can be deferred without affecting the user experience.
Data sources: carbon-intensity APIs
The three main sources:
-
Electricity Maps[1]: real-time and forecast data per region for 50+ countries. The free tier covers experimentation.
-
WattTime[2]: US-focused, with granular historical data.
-
Carbon Aware SDK[3] (Green Software Foundation): open-source, multi-language wrapper that aggregates several sources.
Implementation patterns
Deferring batch jobs
The simplest change: if a backup or an ETL job can run at any point in a 24-hour window, the schedule can be optimized:
from carbon_aware import get_cleanest_hour
hour = get_cleanest_hour(region="es-es", window_hours=24)
schedule_job_at(hour, "backup-db")
A change of a few lines, with measurable impact on the emissions report.
Routing workloads across regions
For truly stateless workloads:
region = get_cleanest_region(candidates=["se-north-1", "ie-west-1", "pl-central-1"])
deploy_to(region)
Sweden (hydroelectric, very clean) versus Poland (coal, >600 g/kWh) can mean a 6-8x difference in emissions for the same workload.
Carbon-aware HPA in Kubernetes
The emerging stack for scaling based on carbon intensity:
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: carbon-aware-workload
spec:
scaleTargetRef:
name: my-deployment
triggers:
- type: external
metadata:
scalerAddress: carbon-aware-scaler.default:8080
region: eu-west-1
threshold: "300" # g CO₂/kWh
When intensity exceeds the threshold, the HPA scales down replicas and defers work. Microsoft’s carbon-aware-keda-operator[4] implements this pattern. For the observability layer behind these metrics, see container monitoring beyond cAdvisor.
What the Green Software Foundation builds
The Green Software Foundation[5] (Linux Foundation, with Microsoft, GitHub, Accenture, and Thoughtworks) develops:
-
Carbon Aware SDK: the reference multi-language library.
-
Software Carbon Intensity (SCI) specification: a standard metric of g CO₂ per unit of business value.
-
Training and certification programs.
The SCI specification matters because it gives a normalized metric that lets organizations compare with each other and report under CSRD. That same energy-efficiency logic connects to the design choices behind a sustainable data center: where a cloud provider is located and what electricity mix it draws on matter as much as when a workload runs.
Real ROI cases
-
Google reports millions of kg of CO₂ avoided every year through scheduling in its data centers.
-
Microsoft: Xbox downloads updates by prioritizing low-carbon hours.
-
NHS UK: pilots of overnight processing for medical imaging.
For a mid-size company: a 10-30% CO₂ reduction on flexible workloads with one implementation sprint.
Costs versus benefits
Carbon-aware computing adds no cost in most implementations:
-
Cloud pricing per hour is uniform within the same region.
-
The change is just scheduling logic (trivial code).
-
Added time only matters if deferring the batch causes an unacceptable delay for the business.
The benefits:
-
A real, reportable reduction in CO₂.
-
Support for CSRD compliance and ESG reporting.
-
Genuine green credentials, not purchased carbon offsets.
Honest limitations
-
Forecasts carry a ±20% error: this is not exact science.
-
Regional coverage isn’t universal: Electricity Maps covers Western Europe well, but some zones have poor data.
-
Savings are 10-30% of flexible workloads, not 100% of total compute.
-
Greenwashing risk if it’s reported without a real, significant reduction behind it.
Getting started
The most pragmatic path:
-
Audit which workloads are deferrable and how much they consume.
-
Prototype with 1-2 jobs moved to low-carbon hours using the free Electricity Maps API.
-
Measure CO₂ before and after.
-
Expand to more workloads and automate with KEDA.
-
Report it in corporate sustainability reporting.
Conclusion
Carbon-aware computing is low-hanging fruit for IT sustainability. Without hardware changes or app rewrites, flexible-workload emissions can drop 10-30% through intelligent scheduling. Given CSRD and growing European regulation, carbon-aware computing will move from an option to an expectation in the coming years. Better to adopt it early than to be forced into it later.
Spanish version: Cómputo consciente del carbono: reducir emisiones sin rehacer todo.