Green DevOps: the carbon cost of our servers

It's easy to think of software as weightless. Code is just text, the cloud is just "somewhere". But every request, every pipeline run, every idle VM runs on physical hardware in a data centre that uses electricity and water, and was manufactured with real materials.

Data centres already use a noticeable chunk of the world's electricity, and the AI boom is making that number rise quickly. As the people who decide how much infrastructure runs and how efficiently, DevOps engineers have more influence over this than we often realise.

Why it matters now

• Regulation. In the EU, the Corporate Sustainability Reporting Directive (CSRD) requires many large companies to report environmental impact, which includes IT. The Energy Efficiency Directive requires larger data centres to report energy and water use. Even where requirements have been scaled back or delayed, the direction is clear.
• Customers and investors increasingly ask about emissions, including from digital services.
• AI workloads are energy-hungry, and growing quickly.
• Cost. Energy is a big part of what you pay for in the cloud. Wasted compute is wasted money and wasted carbon at the same time.

Where software emissions come from

Roughly three sources:

1. Operational energy: electricity used by servers, storage and networking while running your workloads.
2. Carbon intensity of that energy: the same kilowatt-hour can have very different emissions depending on where and when it's used. A grid powered by wind and hydro is much cleaner than one powered by coal or gas.
3. Embodied carbon: emissions from manufacturing the hardware. Using hardware more efficiently, and longer, spreads that out.

The Green Software Foundation defines a Software Carbon Intensity (SCI) specification, now an ISO standard, to calculate emissions per unit of work (for example per request or per user), combining energy, carbon intensity and embodied emissions.

Measuring it

You can't reduce what you can't see. Tools that help:

• Cloud provider dashboards: AWS Customer Carbon Footprint Tool, Google Cloud Carbon Footprint, Microsoft's Emissions Impact Dashboard. Good for an overview, usually with a delay and limited detail.
• Cloud Carbon Footprint: an open-source tool that estimates emissions from cloud billing data across providers.
• Kepler (Kubernetes-based Efficient Power Level Exporter, a CNCF project): uses eBPF and hardware counters to estimate the energy use of individual pods and containers, exposed as Prometheus metrics.
• Electricity Maps and WattTime: real-time and forecast carbon intensity data for electricity grids.
• Carbon Aware SDK from the Green Software Foundation: helps applications use that data to make decisions.

The greenest compute is the compute you don't run. The second greenest is the compute you run efficiently, in a clean place, at a clean time.

What DevOps teams can do

Most of these are also cost optimisations, which makes them easier to justify.

Use less: - Delete idle and forgotten resources. - Right-size VMs, containers and databases. - Turn off non-production environments outside working hours. - Scale to zero where possible. - Keep observability data lean: fewer logs, sampled traces, shorter retention. - Avoid unnecessary CI runs (only build what changed, cancel outdated runs).

Use it more efficiently: - Increase utilisation by packing Kubernetes nodes better (Karpenter consolidation, honest resource requests). - Use energy-efficient hardware like ARM-based instances, which often use less energy for the same work. - Optimise hot code paths (continuous profiling helps find them). - Cache and compress to reduce network traffic and repeated work.

Use cleaner energy: - Choose regions with cleaner grids when latency and data rules allow. Regions in countries with lots of hydro, wind or nuclear typically have much lower carbon intensity. Cloud providers publish data about their regions. - Carbon-aware scheduling: run flexible workloads (batch jobs, training, reports, non-urgent CI) when or where the grid is cleaner. For example, shift a nightly job to the hours with the most wind power, or to a cleaner region.

Use hardware longer: - For on-premises, extending hardware lifetime reduces embodied emissions.

Carbon-aware scheduling, in practice

A simple version: a batch job that can run any time within the next 12 hours checks a carbon intensity forecast and starts in the cleanest window. Tools and Kubernetes projects are emerging to do this automatically, using KEDA scalers based on carbon intensity or schedulers that consider grid data.

It doesn't work for everything. User-facing requests need to run now, close to users. But a surprising amount of compute is flexible: data pipelines, model training, backups, test suites.

Saving money and CO₂ together

The nice thing about green DevOps: it rarely conflicts with good engineering. Efficient systems are cheaper, faster and greener. FinOps and sustainability teams often find they're working on the same list.

A useful habit: next to the cost of a service, show its estimated energy or carbon footprint. It gives engineers one more reason to clean up, and makes the impact visible.

So, where do I start?

Look at your cloud provider's carbon dashboard to get a baseline. Then do the efficiency work you'd do for cost anyway: remove waste, right-size, turn off what's idle. If you run Kubernetes, try Kepler to see energy per workload. And for your next batch workload, ask whether it could run at a cleaner time or in a cleaner region.

My take: every idle server is burning money and carbon for nothing. Efficient infrastructure is good engineering, good business and good for the planet, all at once.

— Desly