The Same Workload Emits 105× More CO₂ in One AWS Region Than Another

Nobody picks a region for the grid

When you choose an AWS region, you weigh latency, price, and which services are available. Almost nobody weighs the electricity. That turns out to be a strange omission, because the carbon intensity of the power grid behind each region varies by more than two orders of magnitude — and the choice dwarfs nearly every other efficiency decision you can make.

Here is every AWS region ranked by grid carbon intensity, measured in grams of CO₂ equivalent per kilowatt-hour. These are location-based averages compiled from EPA eGRID (US), EEA (Europe), and national grid data — the same sources underlying the Cloud Carbon Footprint dataset. Exact values drift year to year as grids decarbonize, but the ordering has been stable for years:

The pattern is exactly what you'd expect if you follow energy rather than cloud news. Cape Town sits on Eskom's coal-heavy grid. Mumbai, Sydney, and Bahrain are fossil-dominated. Stockholm, Montreal, Oregon, São Paulo, and Paris run on hydro and nuclear. N. Virginia — the default region, the biggest AWS footprint on Earth, the place where untold millions of workloads run because us-east-1 is the first item in every dropdown — lands almost exactly in the middle, on Dominion's mix of gas, coal, and nuclear.

The same kilowatt-hour emits 105× more CO₂ in Cape Town than in Stockholm. No amount of rightsizing, Graviton migration, or code optimization available to you comes close to a 105× factor. Region choice is the single largest climate lever most AWS customers have, and it is nearly invisible.

Why you've never seen this number

AWS does publish a Customer Carbon Footprint Tool, and to be fair, it has improved: it now breaks emissions down by region and service, reports both location-based and market-based Scope 2 figures, and delivers data a few weeks after each month closes. If your job is producing a compliance report, it works.

But it answers the question after the decision is already made:

• It's a reporting tool, not a design input. Monthly account aggregates, published weeks later, partly estimated and recast the following year — useful for disclosure, useless at the moment you're writing region = "us-east-1" into a Terraform file.
• Its headline Scope 2 numbers are market-based, reflecting AWS's renewable purchases and energy attribute certificates. Reasonable people disagree about how much credit EACs deserve; what's not in dispute is that a certificate purchased in one place does not change the fuel mix of the electrons consumed in another.
• It maps emissions to billing dimensions — region, service, account — not to the resource-level objects engineers actually control: this task definition, this instance, this bucket.

The result: "our cloud carbon footprint" is a number a sustainability report sees once a quarter, while the decision that drives most of it — where to run — is made per-project, per-service, per-day, with zero carbon information in the room.

A worked example

Take a single always-on m5.4xlarge (16 vCPU). Estimating whole-instance draw — CPU package, memory, and host overhead amortized — at roughly 7 W per vCPU, the instance consumes about 112 W, or ~82 kWh per month (see the caveats below on this number). Apply the regional intensity:

One modest instance, left running in Cape Town, emits about 883 kg of CO₂ per year — roughly one London–New York round-trip flight, or ~4,200 km of driving a diesel car. The identical instance in Stockholm emits 8.4 kg, about what you'd emit driving 40 km to the airport to board that flight.

Now the comparison that stings: migrate that instance to Graviton (m7g, ~2.5 W/vCPU) while keeping it in us-east-1, and you cut consumption to ~29 kWh/month — emissions fall from 372 to 133 kg/year, a respectable 64% reduction. Move the same Intel instance from us-east-1 to eu-north-1 and you get a 97.7% reduction.

The efficiency industry's default advice — modernize to Graviton — is correct but second-order. Where the workload runs matters roughly 30× more than what chip it runs on.

The honest caveats

These numbers deserve scrutiny, and they're easy to misread, so:

• These are location-based, average grid intensities — modeled estimates, not meter readings. They don't include PUE (datacenter overhead; AWS models it around 1.1–1.15), embodied carbon of hardware, water use, or network transmission.
• Power draw is the fuzziest input. The ~7 W/vCPU above is a whole-instance estimate. Cloud Carbon Footprint's SPECpower-derived CPU-package figures run lower — roughly 0.6 W idle to ~4 W max per vCPU for the Skylake/Cascade Lake chips behind m5 — plus a separate memory term. Treat the absolute kilogram figures as order-of-magnitude, not accounting-grade. The ratios between regions are unaffected by this choice, since wattage is a common multiplier.
• Average vs. marginal is a real debate. Your workload doesn't get "average" electrons; the marginal generator responds to your demand. But this caveat mostly strengthens the direction of the argument: marginal generation in coal grids is coal, while marginal generation in hydro/nuclear grids is often near-zero or would otherwise be curtailed.
• Market-based accounting cuts both ways. AWS purchases renewables and PPAs that location-based figures ignore. If your reporting standard credits those purchases, your footprint looks different — but the grid physics of where the electricity comes from doesn't change.
• Region choice is constrained. Latency, data residency, egress cost, and service availability are real requirements. Nobody should ship latency-sensitive prod to Stockholm for users in Texas. The point isn't that every workload can move — it's that some workloads can, and nobody's checking which.

What's actually movable

The workloads that can relocate without anyone noticing are precisely the ones nobody optimized in the first place:

• Batch and async processing — ETL, report generation, video transcoding
• CI/CD build fleets — often a large, spiky, latency-insensitive load
• ML training — hours-to-days jobs where a queue position is expected anyway
• Backups, snapshots, log archives, disaster-recovery replicas
• Dev/test/staging environments — frequently the least latency-critical compute in the account

Anything already sitting in af-south-1, ap-south-1, or ap-southeast-2 that doesn't need to be there is the largest single carbon lever in your account — bigger than every instance-type optimization combined.

The cleanest kWh is still the one you don't use

Region math only applies to work that needs to happen at all. An idle Fargate task in Stockholm is clean; an idle Fargate task deleted is cleaner — and cheaper. In practice the two levers compound: first remove waste (which also removes its emissions everywhere), then run what remains on the cleanest grid your constraints allow.

I built GreenOps Scan partly to make the first half of that sentence concrete — it's a free, read-only CLI that scans an AWS account and reports per-resource cost and modeled CO₂ opportunity, using the regional table above and per-family vCPU wattage estimates:

npx greenops-scan

The carbon figures are estimates with all the caveats above — they're for prioritization, not regulatory reporting. But "which of these workloads shouldn't exist, and which shouldn't exist here" is a question most accounts have never been asked, and the answer is usually worth more than the tool costs, which is nothing.

Tags: #AWS #CarbonAware #CloudSustainability #GreenOps #ClimateTech #FinOps