Cloud Carbon Coefficients
The open coefficients this site uses to put a carbon figure beside a cost figure: watts per vCPU, PUE, storage and network factors, and Google's per-region grid intensity. Includes the list of calculators that deliberately show no carbon number, and why.
Compute and infrastructure coefficients
| Provider | Min W/vCPU | Max W/vCPU | PUE | Memory kWh/GB-hr | Network kWh/GB |
|---|---|---|---|---|---|
| AWS | 0.74 | 3.5 | 1.135 | 0.000392 | 0.001 |
| Google Cloud | 0.68 | 4.11 | 1.1 | 0.000392 | 0.001 |
| Azure | 0.74 | 3.54 | 1.185 | 0.000392 | 0.001 |
Storage is 1.2 Wh per terabyte-hour for SSD and 0.65 for HDD across all three providers. PUE multiplies everything, because it describes the data-centre overhead — cooling, lighting, conversion losses — wrapped around the IT load.
Google Cloud grid intensity by region (40 regions)
Google is the only provider that publishes this per region. Carbon-free energy percentage is how much of the region’s consumption Google matches with carbon-free generation on an hourly basis; grid intensity is what the local grid emits per kilowatt-hour. A workload moved from a high-intensity region to a low-intensity one changes its emissions by more than almost any efficiency work.
| Region | Location | CFE% | gCO₂eq/kWh |
|---|---|---|---|
| northamerica-northeast1 | Montréal | 100% | 2 |
| europe-west9 | Paris | 94% | 34 |
| europe-north1 | Finland | 98% | 46 |
| northamerica-northeast2 | Toronto | 87% | 47 |
| southamerica-east1 | Sāo Paulo | 90% | 56 |
| europe-west6 | Zurich | 92% | 59 |
| us-west1 | Oregon | 84% | 94 |
| europe-west1 | Belgium | 82% | 122 |
| europe-southwest1 | Madrid | 76% | 131 |
| europe-west2 | London | 92% | 136 |
| southamerica-west1 | Santiago | 91% | 138 |
| us-west2 | Los Angeles | 55% | 198 |
| europe-west4 | Netherlands | 80% | 236 |
| europe-west8 | Milan | 52% | 249 |
| europe-west12 | Turin | 52% | 249 |
| us-south1 | Dallas | 79% | 321 |
| us-east5 | Columbus | 52% | 322 |
| us-east4 | Northern Virginia | 52% | 322 |
| europe-west3 | Frankfurt | 90% | 345 |
| europe-west10 | Berlin | 90% | 345 |
| asia-east2 | Hong Kong | 28% | 360 |
| asia-southeast1 | Singapore | 4% | 369 |
| us-west4 | Las Vegas | 26% | 373 |
| asia-northeast3 | Seoul | 35% | 378 |
| asia-northeast2 | Osaka | 30% | 385 |
| us-central1 | Iowa | 95% | 430 |
| asia-east1 | Taiwan | 18% | 451 |
| australia-southeast2 | Melbourne | 40% | 456 |
| asia-northeast1 | Tokyo | 16% | 459 |
| me-west1 | Tel Aviv | 5% | 463 |
| australia-southeast1 | Sydney | 33% | 501 |
| asia-south2 | Delhi | 29% | 529 |
| us-east1 | South Carolina | 29% | 560 |
| me-central2 | Dammam | 0% | 569 |
| me-central1 | Doha | 0% | 575 |
| asia-southeast2 | Jakarta | 13% | 580 |
| us-west3 | Salt Lake City | 29% | 588 |
| africa-south1 | Johannesburg | 16% | 646 |
| asia-south1 | Mumbai | 14% | 648 |
| europe-central2 | Warsaw | 31% | 723 |
Where this site deliberately shows no carbon figure
Publishing an indefensible number would undermine every other figure here, so these calculators show none — and say so on the page rather than omitting it silently.
- Snowflake Cost Calculator
Snowflake bills in credits and does not disclose the hardware behind a warehouse size, so there is no published coefficient per credit. Any figure would be a guess about somebody else's fleet.
- Databricks Cost Calculator
The DBU is a billing abstraction, not a hardware unit. The cloud VMs underneath it do have coefficients — but the calculator cannot know which instance types a workload actually ran on, and assuming one would move the answer by several times.
- LLM Token Cost Calculator and AI Agent Cost Calculator
Per-model inference emissions are already published, with a methodology, by the EcoLogits project at the GenAI Impact non-profit. Reimplementing it would add a second less-reviewed number to a question that already has a good answer.
Use these instead, where they apply
- AWS Sustainability
Free, native, and authoritative for AWS. Emissions and water, by Region, service and scope.
- Google Cloud Carbon Footprint
Free, and exports to BigQuery. Google also publishes per-region CFE%, which this page uses.
- Azure Carbon Optimization
Free and in-portal, and issues recommendations rather than only measurements.
- EcoLogits (GenAI Impact)
Per-model LLM inference emissions, operational and embodied, with a published methodology.
- Cloud Carbon Footprint
The open methodology every coefficient on this page comes from.
What this model assumes
- Every coefficient is collected from Cloud Carbon Footprint’s published methodology and Google’s region-carbon-info dataset, by a script rather than by hand. The date above is the date it ran.
- Embodied carbon is not included. Manufacturing a server carries a substantial one-off footprint that Cloud Carbon Footprint can estimate but that depends on hardware refresh cycles we cannot see. Every figure on this site is operational only, and therefore an understatement.
- The CPU term uses the minimum and maximum watts directly rather than interpolating by utilisation, because the calculators do not have a utilisation figure and presenting an interpolated number would hide that the range is the finding.
- Grid intensity defaults to 430 gCO2eq/kWh (us-central1) for all providers. AWS and Azure do not publish per-region intensity, so applying a region-specific figure to them would imply a precision that does not exist.
- Your provider’s own carbon reporting is authoritative and these figures are an estimate. They exist to price a change before you make it, which is the one thing provider reporting cannot do.
Frequently asked questions
Why does this site have a carbon calculator when every provider ships one free?
Because the provider tools all answer the same question and it is not the only question. AWS Sustainability, Google Cloud Carbon Footprint and Azure Carbon Optimization are free, native, and better than us at measuring what already happened — each vendor knows its own PUE, grid contracts and hourly generation mix, which we can only estimate. What none of them does is price a workload that does not exist yet, span providers, or rank the locations you might deploy into. Those are design-time questions, they have to be answered before there is anything to measure, and region alone moves the answer by a factor of hundreds. So the calculator here is forward-looking and comparative; once the workload is running, the provider tool is the authority.
Why is the carbon figure always a range?
Because the underlying research is a range. Cloud Carbon Footprint publishes a minimum and a maximum watts-per-vCPU for each provider, since the true figure depends on processor generation and on how hard the machine is working — neither of which a calculator knows. Collapsing that to a midpoint would look more confident and be less true, so both ends are shown.
Where do the grid emission factors come from?
Google publishes carbon-free-energy percentage and grid carbon intensity for every Google Cloud region as an open CSV, and that is used directly. The default figure applied when no region is specified is 430 gCO₂eq/kWh, the published value for us-central1 — which is also the region every Google Cloud rate on this site is priced for, so the carbon figure and the dollar figure describe the same place.
Is a provider carbon report more accurate than this?
Yes, and it should be preferred. Your provider measures what we estimate. The estimate here exists to answer a different question — what a proposed change would do — which a backward-looking report cannot answer at all. Use both.
Why do some calculators on this site show no carbon figure?
Because no defensible coefficient exists for them, and printing an indefensible one would undermine every figure on the site. Snowflake and Databricks bill in credits and DBUs rather than hardware, and neither discloses the fleet underneath. For LLM and agent costs, the EcoLogits project at the GenAI Impact non-profit already publishes per-model inference emissions with a documented methodology, and adding a second less-reviewed number would make the answer worse rather than better. The full list is on this page.
Cost and carbon come from the same telemetry.
Finitizer reads your usage once and reports both — so the rightsizing that saves money and the rightsizing that saves carbon are the same piece of work rather than two competing initiatives.