Carbon-Aware Computing: Reduce Emissions Without Rebuilding Everything

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 adds no infrastructure.

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 more than one data source.

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, 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.

Frequently asked questions

Which workloads can I defer to clean-energy hours without affecting users?

The time-flexible ones: batch processing and ETL, ML model training, data warehouse refreshes, backups and indexing. Stateless workloads with no data-residency constraints are also location-flexible and can move to the cleanest region. Real-time user requests, real-time streaming, OLTP transactions and control loops are not flexible. Overall, 20-40% of an organization's total compute can be deferred without affecting the user experience.

How much CO₂ does carbon-aware scheduling actually save?

For a mid-size company, a 10-30% CO₂ reduction on flexible workloads with one implementation sprint, not 100% of total compute. Grid intensity varies up to 16x between the best and worst scenario. A 1 MWh workload emits about 50 kg CO₂ in a clean zone at the optimal time, versus about 800 kg in a dirty zone at a bad time. Forecasts carry a ±20% error, so this is not exact science.

Does running jobs according to carbon intensity raise the cloud bill?

It adds no cost when the change is just scheduling logic: cloud pricing per hour is uniform within the same region. It is a few lines querying an API such as Electricity Maps, whose free tier covers experimentation. The only cost appears if deferring the batch causes an unacceptable delay for the business. In return you get a real, reportable CO₂ reduction useful for CSRD and ESG reporting.

Sources

1. Electricity Maps
2. WattTime
3. Carbon Aware SDK
4. carbon-aware-keda-operator
5. Green Software Foundation