Cloud Sustainability — A Field Guide

Cloud sustainability is the practice of measuring and reducing the carbon footprint of workloads running on shared infrastructure — not a compliance checkbox, but an engineering constraint that, done well, tends to overlap heavily with cost optimization, because idle and oversized resources waste both money and energy.

The three emissions scopes, and why cloud complicates them

The GHG Protocol splits emissions into Scope 1 (direct, from things you own — a generator, a company vehicle), Scope 2 (indirect, from the electricity you purchase), and Scope 3 (everything else in the value chain, including your cloud provider's operations). For a company running entirely on AWS, Azure, or GCP, virtually all cloud-related emissions land in Scope 3 — the provider's data centers are the provider's Scope 1/2, but they're your Scope 3. That's why cloud carbon reporting depends heavily on data the provider chooses to expose, and why the three major providers report this differently and with different levels of granularity.

What each provider actually gives you

AWS's Customer Carbon Footprint Tool reports estimated emissions at the account level, broken down by service and region, updated monthly with roughly a three-month lag — useful for trend-spotting, not for real-time decisions. Google Cloud's Carbon Footprint tool does similar account-level reporting and additionally publishes region-by-region carbon-free energy percentages, which is genuinely actionable: GCP publishes which regions run on the highest share of carbon-free energy, so region selection becomes a concrete lever. Microsoft's Emissions Impact Dashboard for Azure works similarly, integrated with Power BI for teams already in that ecosystem. None of the three give per-request or per-service real-time carbon data — the granularity is coarser than most teams initially expect.

Same workload, different regional grid carbon intensity:

us-east-1 (N. Virginia)     grid mix ~heavier fossil, higher gCO2/kWh
us-west-2 (Oregon)          hydro-heavy grid, lower gCO2/kWh
eu-north-1 (Stockholm)      Nordic grid, largely hydro/nuclear, very low gCO2/kWh

A non-latency-sensitive batch workload gains real carbon
reduction just by choosing where it runs and when.

Rightsizing is still the single biggest lever

The single most effective sustainability action for most engineering teams is identical to the single most effective cost action: eliminate idle and oversized resources. An overprovisioned instance running at 8% CPU utilization wastes energy in direct proportion to the money it wastes. Autoscaling to match actual demand, scheduling non-production environments to shut down outside working hours, and rightsizing instance types based on real utilization data all reduce both the bill and the footprint simultaneously — which is exactly why FinOps and sustainability initiatives increasingly share tooling and reporting.

Architectural choices that compound over the workload's lifetime

Serverless and container-based compute generally achieve higher utilization density than dedicated VMs, because the provider packs more workloads onto the same physical hardware — a genuine efficiency gain that shows up as lower emissions per unit of work, not just lower cost. Choosing regions with cleaner grids for non-latency-sensitive workloads, and preferring managed services over self-managed infrastructure where the provider's fleet-wide utilization beats what a single team can achieve on dedicated capacity, both compound over the life of a system in ways a one-time optimization pass doesn't.

Where to start if this is new to the team

Turn on the provider's carbon reporting tool first — it's free and requires no engineering work — and use a quarter of data to identify the highest-emission services before designing any intervention. From there, the rightsizing and idle-resource work most teams already do for cost reasons delivers the bulk of the sustainability gain; region selection and carbon-aware scheduling are the next-tier levers for delay-tolerant or non-latency-sensitive workloads specifically.

Cloud sustainability isn't a separate discipline requiring new tooling from scratch — it rides on the same rightsizing, autoscaling, and utilization work that FinOps already demands, with region selection and workload scheduling as the additional levers unique to carbon specifically.