Measure cloud carbon across providers by starting with each provider's native tool, because they use the provider's own grid and energy data. Hold one Scope 2 accounting method constant, location-based or market-based, across all three, then export everything into one place and normalize on a unit metric such as grams of CO2e per transaction. Absolute totals will never be perfectly comparable across clouds, so compare trends and unit figures rather than chasing one exact tonnage. Set a baseline, then re-measure after each optimization the way you prove cost savings.
Measuring cloud carbon emissions means quantifying the greenhouse gases attributable to your cloud usage, reported in the Greenhouse Gas Protocol's three scopes. The reason it is harder in multicloud than in a single cloud is that each provider builds its own model, with its own energy mix, its own assumptions, and its own update cadence, so the numbers do not line up cleanly. The practical answer is not to wait for a perfect cross-provider figure that does not exist, but to measure each cloud accurately with its native tool, impose a consistent methodology yourself, and track a unit metric you control. That discipline is the foundation of any GreenOps program.
This article is part of our complete guide to cloud sustainability and GreenOps, the cluster pillar it links up to. For the AWS-specific walkthrough, see how to use the AWS Customer Carbon Footprint Tool.
Which tool measures each cloud's carbon?
Each provider ships a native carbon tool, and these are the most accurate starting point because they draw on the provider's own facility and grid data. AWS reports through the Customer Carbon Footprint Tool, now superseded by the AWS Sustainability Console. Azure reports through the Emissions Impact Dashboard and the Carbon optimization page in the portal. Google reports through Google Cloud Carbon Footprint. All three now report Scope 1, 2, and 3 following the Greenhouse Gas Protocol, and all three present both market-based and location-based Scope 2.
| Provider | Native tool | Scopes | Export |
|---|---|---|---|
| AWS | Customer Carbon Footprint Tool / Sustainability Console | 1, 2, 3 | Data Exports |
| Azure | Emissions Impact Dashboard / Carbon optimization | 1, 2, 3 | Power BI |
| Google Cloud | Carbon Footprint | 1, 2, 3 | BigQuery |
How do I get one comparable number?
Get one comparable number by holding the methodology constant and normalizing on usage, rather than trusting raw totals to align. The method:
- Enable each provider's native carbon tool. Turn on the AWS, Azure, and Google tools above so every cloud reports its own emissions accurately.
- Choose one accounting method consistently. Pick location-based or market-based Scope 2 and apply the same choice everywhere, because mixing the two makes totals incomparable.
- Export the data to one place. Send each provider's export, via BigQuery, Data Exports, or Power BI, into a single warehouse or sheet so the figures sit side by side.
- Normalize on usage and a unit metric. Track grams of CO2e per transaction, per customer, or per unit of output, not only absolute tonnes, so the number is comparable across clouds and over time.
- Set a baseline and re-measure. Record a baseline month, then re-measure after each optimization to prove the carbon reduction, the same way you prove a cost saving.
Normalizing on a unit metric is the move that makes the data useful, because absolute emissions rise with a growing business even as efficiency improves. A falling grams-per-transaction figure shows real progress that a rising tonnage would hide. This is the same unit-economics thinking we apply to cost, and it is built into a full FinOps implementation.
Want carbon measured and proven down across clouds?
Our FinOps implementation stands up cross-cloud measurement, sets the baseline, and proves cost and carbon reductions on AWS, Azure, GCP and OCI. Fixed fee, performance fee, or fully managed. On the performance model, you pay only from realized savings.
Talk to us about FinOps implementation →Why will the numbers never match exactly?
The numbers will never match exactly because each provider makes different choices about energy attribution, the grid data it uses, and how it allocates shared infrastructure to a single customer. One cloud may credit power-purchase agreements that another does not; one may update grid factors quarterly and another annually; one may model Scope 3 server manufacturing more granularly than another. None of this makes the tools wrong, it makes them non-identical. The right response is to stop treating a cross-provider total as a precise figure and treat it as a directional one, while trusting the within-provider trend, which is internally consistent, to guide optimization.
The FinOps Operating Model Blueprint includes the measurement model and unit-metric worksheet we use to track cost and carbon together across multiple clouds.
Common questions about measuring cloud carbon
Can I compare carbon directly across AWS, Azure and Google?
Not perfectly. Each provider models emissions with its own methodology, energy mix, and assumptions, so absolute totals are not strictly comparable. Use a consistent accounting method, normalize on usage, and track a unit metric to compare trends rather than chasing an exact cross-provider number.
What is the difference between market-based and location-based emissions?
Market-based Scope 2 credits the provider's clean-energy purchases and can look near zero where renewable certificates match demand. Location-based Scope 2 uses the raw grid average where the workload ran. Location-based is the number that responds to rightsizing, region choice, and scheduling.
Do the native tools cover Scope 3?
Increasingly yes. AWS, Azure, and Google now report Scope 3 emissions covering the lifecycle footprint such as server manufacturing and transport, in addition to Scope 1 and Scope 2. AWS added Scope 3 to its Customer Carbon Footprint Tool in late 2025.
Written by Morten Andersen and reviewed by Fredrik Filipsson, applying our See, Cut, Lock, Run method. Independent and vendor neutral.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: FinOps Foundation Framework ↗ and FinOps Rate Optimization capability ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.