Cloud Workload Carbon Calculator
Estimate the operational CO₂e of a workload you have not deployed yet, across AWS, Google Cloud and Azure, and rank every location with published grid data. The provider tools measure what already happened; this prices the decision beforehand.
The same workload, everywhere with published grid data
| Location | Grid | CFE | kg CO₂e/yr | vs here |
|---|---|---|---|---|
| Montréalnorthamerica-northeast1 | 2 | 100% | 3 | -576 |
| Pariseurope-west9 | 34 | 94% | 46 | -533 |
| Finlandeurope-north1 | 46 | 98% | 62 | -517 |
| Torontonorthamerica-northeast2 | 47 | 87% | 63 | -515 |
| Sāo Paulosouthamerica-east1 | 56 | 90% | 75 | -503 |
| Zuricheurope-west6 | 59 | 92% | 79 | -499 |
| Oregonus-west1 | 94 | 84% | 126 | -452 |
| Belgiumeurope-west1 | 122 | 82% | 164 | -414 |
| Madrideurope-southwest1 | 131 | 76% | 176 | -402 |
| Londoneurope-west2 | 136 | 92% | 183 | -396 |
| Santiagosouthamerica-west1 | 138 | 91% | 186 | -393 |
| Los Angelesus-west2 | 198 | 55% | 266 | -312 |
Does the operator change the answer?
| AWSPUE 1.135 | 534 kg |
| Google CloudPUE 1.1 | 578 kg |
| AzurePUE 1.185 | 562 kg |
| Spread | 1.08× |
Barely. The operator changes only data-centre efficiency — power usage effectiveness and assumed watts per vCPU — which moves the answer by a few per cent. Location moves it by a factor of hundreds. Treat this table as evidence that the provider choice is not where the carbon decision lives, not as a league table.
What this model assumes
- This is an estimate, and your provider’s own tool is authoritative. AWS Sustainability, Google Cloud Carbon Footprint and Azure Carbon Optimization all measure what actually happened using data nobody outside those companies has. This exists to answer the question they cannot — what a workload would emit, and where it should run — before there is anything to measure.
- Location-based accounting, not market-based. Grid intensity is what the local grid emits per kilowatt-hour; carbon-free-energy percentage is how much of its consumption an operator matches with carbon-free purchases. Google’s us-central1 has a 95% CFE and a 430 gCO₂eq/kWh grid — both true, answering different questions. Only grid intensity means the same thing for every provider, so only it drives the comparison. CFE is shown alongside and never blended in.
- Grid intensity is a property of the grid, not the provider. That is why this asks for a location and an operator separately: a data centre in Iowa draws from the Iowa grid whoever owns it. The operator selection changes only the efficiency coefficients.
- Embodied carbon is excluded, so every figure here is an understatement. Manufacturing a server carries a substantial one-off footprint, and attributing a share of it needs hardware refresh cycles we cannot see. For embodied estimates per instance type, the Boavizta project publishes an open API that models it explicitly.
- The range comes from Cloud Carbon Footprint publishing a minimum and a maximum watts-per-vCPU, because the real figure depends on processor generation and how hard the machine works. A midpoint would look more confident and be less true.
- Only locations with published grid data are offered — the 40 in Google’s open dataset. AWS and Azure publish no per-region carbon intensity, so their regions are not listed separately; pick the location their region sits in.
- Efficiency coefficients — Cloud Carbon Footprint methodology
- Grid intensity and CFE — Google Cloud region-carbon-info
Collected 2026-08-05 by a script, not by hand.
Frequently asked questions
Why use this when AWS, Google and Azure all have free carbon tools?
Because they answer a different question. All three measure what you already emitted — at account level, for their own cloud, on a one-to-three-month lag. None of them can tell you what a workload you have not deployed yet would emit, or compare that across providers, or rank the regions you might put it in. Those are design-time questions and they have to be answered before there is anything to measure. Once the workload is running, use the provider tool — it is measuring what this only estimates.
Which cloud region has the lowest carbon footprint?
Among locations with published grid data, Montréal is the lowest by a wide margin at about 2 gCO₂eq/kWh, followed by Paris, Finland, Toronto and Zurich — all under 60. At the other end, Warsaw, Mumbai and Johannesburg all exceed 640. That is a spread of more than 300x for identical hardware doing identical work. Even inside the United States the range is roughly 6x, from Oregon at 94 to South Carolina at 560.
Does the choice of cloud provider change the carbon footprint much?
Much less than people expect. The operator affects data-centre efficiency — power usage effectiveness of roughly 1.1 to 1.19 — and the assumed watts per vCPU, which together move the answer by a few per cent. Location moves it by a factor of hundreds. Anyone choosing a cloud on carbon grounds is optimising the small term and ignoring the large one.
What is the difference between grid carbon intensity and carbon-free energy percentage?
They are two accounting methods and they answer different questions. Grid carbon intensity is location-based: what the physical grid in that place emits per kilowatt-hour. Carbon-free energy percentage is market-based: how much of its consumption the operator matches with carbon-free purchases. Google's us-central1 has a 95% CFE and a 430 gCO₂eq/kWh grid, and both figures are correct. This calculator uses grid intensity, because it is the only one that means the same thing regardless of who owns the building — and it shows the CFE beside it rather than blending them.
Does this include the carbon from manufacturing the servers?
No, and that means every figure here is an understatement. Embodied carbon — the one-off footprint of manufacturing hardware — is real and material, but attributing a share of it to your workload needs hardware refresh cycles and fleet utilisation that are not published. Rather than guess, it is excluded and said so. The Boavizta project publishes an open API that models embodied impact per instance type if you need it.
How accurate is this?
It is an estimate presented as a range, and the range is wide on purpose. The coefficients come from Cloud Carbon Footprint, which publishes a minimum and a maximum watts-per-vCPU because the true figure depends on processor generation and load — neither of which a calculator knows. What it is reliable for is the comparison: the ratio between two locations is far more robust than the absolute figure, because the uncertain terms largely cancel.
Cost and carbon come out of the same telemetry.
Finitizer reads your usage once and reports both, so the rightsizing that saves money and the rightsizing that cuts emissions are one piece of work rather than two competing initiatives with separate business cases.