Carbon-aware computing is the practice of making software intelligent enough to run when and where the electricity powering it is cleanest. Rather than treating compute as a commodity that is always equivalent, carbon-aware systems treat the timing and location of compute as engineering variables to optimize.
There are two primary strategies:
1. Time Shifting — Do It When the Grid Is Clean
If a workload is flexible about when it runs, schedule it to coincide with periods of low carbon intensity on the local grid.
How it works: Instead of triggering a batch job at a fixed time (e.g., "run at 6:00 PM every day"), the scheduler queries a carbon intensity forecast API, identifies the cleanest upcoming window within the acceptable deadline, and defers execution to that window.
Ideal workloads for time shifting:
- Machine learning model training
- Batch data processing and ETL pipelines
- Nightly database backups and snapshots
- Video transcoding and media processing
- CI/CD build pipelines (especially long ones)
- Vulnerability scanning and compliance reporting
What it is not suitable for: Any workload with strict latency requirements or real-time user interaction. You cannot time-shift a web server handling live user requests.
2. Location Shifting — Do It Where the Grid Is Clean
If a workload must run now but is flexible about where it runs, route it to the region with the lowest current carbon intensity.
How it works: A global load balancer or job scheduler queries carbon intensity data across multiple cloud regions and routes the workload to the cleanest available region that meets latency and data residency requirements.
Ideal workloads for location shifting:
- Stateless application servers with global deployment
- Distributed ML training across multiple cloud regions
- Content delivery and media serving
- Asynchronous job queues that can be processed in any region
The constraint: Location shifting is limited by data gravity (you cannot easily move a 10 TB database to another region on demand), regulatory requirements (GDPR data residency rules), and latency budgets (a user in London should not be served from Sydney).
The Compound Effect
Time shifting and location shifting are not mutually exclusive. A sophisticated carbon-aware scheduler can combine both: "Run this job in the cleanest region, during the cleanest window, before the deadline." This compound approach can reduce the carbon footprint of a flexible workload by 50–80% compared to running it immediately in a fixed region.
A common interview question: "What types of workloads are good candidates for carbon-aware scheduling?" The answer has two parts. First, the workload must be deferrable (time shifting) or location-agnostic (location shifting) — real-time user-facing services are neither. Second, the workload must be significant in duration or frequency — shifting a 5-second job saves negligible carbon, but shifting a 10-hour ML training run or a daily batch pipeline that processes terabytes can save kilograms of CO₂ per run.