AWS Builder Center

Builder Center

Green Clouds, Cheap Compute: The Case for Carbon-Aware CI/CD Routing

Green Clouds, Cheap Compute: The Case for Carbon-Aware CI/CD Routing

Hardcoding asynchronous CI/CD workloads to a single region drains peak compute capacity and inflates both costs and carbon emissions. By implementing carbon-aware spatial and temporal routing, you can automatically run heavy jobs in regions offering the cheapest Spot capacity and the greenest energy.

Thirumalesh Pinninti

Green Clouds, Cheap Compute: The Case for Carbon-Aware CI/CD Routing

Out of habit, DevOps practitioners tend to hardcode our heaviest asynchronous workloads—like machine learning model training and massive end-to-end integration tests—to run in our primary cloud region. When a developer pushes code at 2 PM on a Wednesday, the pipeline spins up heavy compute locally. This reflex creates two massive inefficiencies: it drains local Spot capacity during peak operational hours (forcing costly On-Demand fallbacks), and it completely ignores the real-time carbon intensity of the regional power grid.
The solution lies at the intersection of FinOps and GreenOps: Carbon-Aware Scheduling. By dynamically routing flexible jobs to regions with the lowest carbon intensity and cheapest Spot capacity, platform teams can cut compute costs while simultaneously slashing Scope 2 emissions.

The Mechanics of Demand Shifting

The Green Software Foundation outlines two primary levers for carbon-aware scheduling that are particularly relevant for ML training and CI/CD pipelines:
  • Location Shifting (Spatial): Electricity is location-bound. A batch job running in a region powered largely by wind or hydroelectricity generates a fraction of the emissions compared to a region reliant on fossil fuels. By decoupling asynchronous runners from primary application regions, workloads can be routed to wherever the grid is greenest.
  • Time Shifting (Temporal): Renewable energy generation is volatile. If a workload isn't time-sensitive, delaying its execution by just a few hours to align with local solar peaks or nighttime wind generation can drastically reduce its carbon footprint.
Experimental data indicates that leveraging these strategies can reduce application carbon footprints by 30% to 70%.

The FinOps Synergy

What makes carbon-aware routing incredibly compelling is that green energy often aligns with cheap compute. Renewable surpluses usually occur during off-peak hours (like nighttime wind). Consequently, cloud providers often have deeper, cheaper Spot instance capacity pools in these greener regions during these times.
Instead of treating FinOps (cost optimization) and GreenOps (sustainability) as competing priorities, carbon-aware routing satisfies both. You chase the cheapest Spot capacity, which frequently happens to be powered by the cleanest energy.

Moving Beyond Glue Code

Today, implementing this requires teams to build custom orchestrators—querying third-party APIs like WattTime or Electricity Maps, managing cross-region container registries, and writing custom Step Functions.
To make this a standard, cloud providers need to offer native  delayTolerant  configurations within managed CI/CD tools. Developers should be able to define a flexibility window (e.g.,  windowHours: 4 ) and a list of approved regions. The control plane would then evaluate real-time grid intensity and Spot pricing, executing the job at the optimal time and place. Until this becomes a native primitive, engineering teams willing to build this routing layer stand to capture massive financial and environmental dividends with zero architectural changes to the underlying applications.
# sustainability# ci-cd# devops
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article