Pick your cloud region on carbon, not just on latency

Before you start

Ten minutes. You need to know which regions you currently use, which is usually one or two.

We’ll use Google’s published data because it’s the most complete and it’s genuinely public: a table on the web, a machine-readable copy on GitHub, and a BigQuery dataset. The principle holds on any provider.

Find the regions you’re actually in

Not the ones you meant to use. The ones things are running in.

Check your main compute, your database, and your storage separately. They don’t have to match, and on accounts that grew over a few years they often don’t. Write down the region code for each, like europe-west2 or us-east-1.

If you did guide 25, you already have this list and can go straight to step 2.

Look each one up

Open Google’s carbon data for cloud regions at cloud.google.com/sustainability/region-carbon.

Two columns matter:

Carbon-free energy percentage.

How much of that grid’s supply is already carbon-free.

Grid carbon intensity

, in grams of CO2 per kilowatt-hour. This is the one to compare on, because it’s an absolute number rather than a proportion.

Find your regions and write the numbers down next to the codes from step 1.

Google also labels a region Low CO2 if its carbon-free energy is 75% or higher, or its grid intensity is 200 gCO2eq/kWh or lower. That’s a useful shorthand once you’ve looked at the real numbers, and a poor substitute for looking.

Check a region you assumed was fine

This is the step that changes what you believe, so don’t skip to the conclusion.

Pick two regions you’d have guessed were roughly equivalent and look them both up. European ones are the usual eye-opener, because “in Europe” feels like one thing and the grids underneath are not one thing at all.

Some real pairs from the table:

Seeing your own region land somewhere in that spread is worth more than any argument in this guide.

Work out what actually constrains you

Now the honest part, because carbon is one input and not the only one.

Latency. If your users are in Sydney, Stockholm is a bad answer no matter how clean it is. Physics wins.

Data residency. If you’ve promised customer data stays in a country, that promise decides the region and carbon doesn’t get a vote. Guide 25 covers finding out what you actually committed to.

Service availability. Not every service exists in every region, and the cleanest regions are sometimes the newer ones with less in them.

Cost. Regional pricing varies, usually by less than people assume, but check rather than hope.

Write down which of these genuinely binds you. For most small operations the honest answer is latency to one market and nothing else, which leaves more room than expected.

Set the rule for next time

You’re not migrating anything today. Migrations are a project, and this guide isn’t one.

Write one sentence somewhere your future self will find it, next to whatever you keep about your infrastructure. Something like: new services go in the cleanest region that meets our latency and residency constraints, and we check the table before we pick.

That’s the whole boundary. It costs nothing, applies from the next deploy, and compounds quietly as things get added.

Read your provider’s own number, and know what it leaves out

Separately from region choice, your provider will tell you what your usage emitted. On AWS that’s the Customer Carbon Footprint Tool in the Billing console.

Read it, and read what it excludes. AWS’s current model covers hardware and data centre buildings amortized over their service life, but it leaves out end-of-life treatment of that hardware and of the buildings, and it excludes facilities that aren’t data centres, like offices and warehouses.

None of that makes the number useless. It makes it a floor rather than a total, and knowing which one you’re holding matters if you’re ever going to repeat it to a client.

A boundary worth knowing about

Grid intensity is an annual average, and grids don’t run at their average.

The same region can be mostly wind at 3am and mostly gas at 6pm. A number that says 50 gCO2eq/kWh is telling you about a year, not about the hour your batch job runs. Shifting heavy work to cleaner hours is a real technique and it’s a different, harder guide than this one.

The other edge: the figures move. Grids get cleaner, providers sign new supply, and the table you read today is not the table from two years ago. That’s an argument for checking at decision time rather than memorising a favourite region.

If you have staff

Put the region in whatever checklist already exists for standing something up. One line next to the other decisions. A rule that lives in a checklist gets followed and a rule that lives in someone’s head does not.

Make the constraints explicit, not the preference. “Cleanest region that meets latency and residency” survives a new person joining. “We like Stockholm” does not, and it breaks the first time Stockholm is the wrong answer.

The short version

1. Find the actual regions your compute, database and storage are in
2. Look each one up at cloud.google.com/sustainability/region-carbon. Compare grid intensity
3. Look up two you’d have assumed were equivalent. They probably are not
4. Write down what genuinely constrains you: latency, residency, service availability, cost
5. Set one rule for the next deploy and write it where it will be found
6. Read your provider’s footprint number and know what it excludes

Sources

• Carbon free energy for Google Cloud regions — carbon-free energy percentage and grid carbon intensity per region, the Low CO2 threshold of 75% CFE or 200 gCO2eq/kWh, and the machine-readable and BigQuery copies of the same data
• AWS Customer Carbon Footprint Tool now includes Scope 3 emissions — what the tool now counts, the amortization of embodied carbon over service life, and the exclusions for end-of-life treatment and non-data-centre facilities

Written August 2026. Region figures checked against Google’s published table on 23 August 2026. These numbers move as grids change, so check at decision time rather than trusting a figure quoted in a guide, including this one.