The cloud carbon footprint is the amount of greenhouse gas that AWS, Microsoft and Google attribute to a customer's cloud use, reported in CO2 equivalent from scopes 1, 2 and 3 of their own operations. For the customer these emissions belong to scope 3, the upstream value chain, and the European Sustainability Reporting Standards (ESRS) name purchased cloud and data centre services explicitly as part of the category purchased goods and services. Each provider works with its own system boundary, allocation, unit and delay. Anyone who sets the cloud carbon footprint beside cost or carries it into a report needs to know these differences; whether and from when a company reports under the CSRD is for its auditor and legal adviser to judge.
How it works
The CSRD and the ESRS
The CSRD, Directive (EU) 2022/2464, added sustainability reporting to the Accounting Directive. Two amendments set the position on the day read. Directive (EU) 2025/794 of 14 April 2025 moved the second wave to financial years starting on or after 1 January 2027. Directive (EU) 2026/470 of 24 February 2026 limits the requirement for financial years from 2027 to undertakings and groups exceeding a net turnover of EUR 450 million and an average of 1,000 employees; Member States transpose it by 19 March 2027 and may exempt first-wave undertakings below those thresholds for financial years 2025 and 2026.
The ESRS are set out in Delegated Regulation (EU) 2023/2772. Delegated Regulation (EU) 2026/1563 of 3 July 2026 replaces its standards with simplified versions; it enters into force on 10 November 2026 and applies to financial years from 1 January 2027, with a choice for 2026. In both versions the climate standard ESRS E1 asks for gross scope 1, 2 and 3 emissions, with scope 2 both location-based and market-based. Purchased cloud computing and data centre services are disclosed as a subset of scope 3 category 1, in the current version where they are material to scope 3. For scope 3, E1 refers to the GHG Protocol's 2011 Scope 3 Standard, which distinguishes fifteen categories of upstream and downstream emissions.
AWS
AWS reports emissions in the AWS Sustainability console, which AWS says builds on the Customer Carbon Footprint Tool. Scope 2 appears both location-based and market-based. Scope 3 covers upstream emissions from fuels and electricity and the embodied carbon of IT hardware, data centre buildings and other equipment; warehouses, offices and sites in customer facilities are outside. Allocation is physical, by usage, where a service has dedicated racks, and economic otherwise. Data arrives monthly by the 21st of the following month, goes back to January 2022 and breaks down by region, service and, in an organisation, usage account. With each new methodology version AWS recalculates the history, and recommends a Data Exports export to keep earlier figures.
Azure
Microsoft reports emissions in Carbon optimization in the Azure portal, at no cost and down to resource level, by subscription, resource group, resource type and location. A month is available by the 19th of the following month, twelve months are retained, and scope 2 there is the market-based figure. The older Emissions Impact Dashboard needs a Power BI Pro licence, does not cover customers buying through a Cloud Solution Provider and will be retired on 31 March 2027. Under the methodology, Microsoft combines scope 1 with scope 2, scope 3 covers the life cycle of data centre hardware in categories 1, 2, 4, 5, 9 and 12, and allocation follows the customer's share of Azure usage in each region. Microsoft notes that this usage may differ from billed usage.
Google Cloud
Google Cloud Carbon Footprint reports scope 1, scope 2 location-based with hourly factors and market-based with annual factors, and scope 3. Scope 3 includes, among other things, the embodied emissions of data centre equipment and buildings, but not their end of life. Allocation follows SKU usage, weighted by list price in US dollars and adjusted for regional carbon intensity. Figures are monthly by project, service and region. The BigQuery export runs per billing account on the 15th of the following month; earlier months back to January 2021 come only by backfill, and BigQuery storage and queries are charged. The field carbon_model_version names the model version. Google states that the customer-specific data is not third-party verified and that methodology changes can also alter earlier figures.
| AWS | Microsoft | Google Cloud | |
|---|---|---|---|
| Unit | tonnes CO2e | tonnes CO2e | kilograms CO2e |
| Scope 2 in the tool | location- and market-based | market-based | location- and market-based |
| Allocation | physical, else economic | share of usage per region | SKU usage weighted by list price |
| Available | by the 21st of the next month | by the 19th of the next month | export on the 15th of the next month |
| History | from January 2022, recalculated on method change | twelve months | backfill from January 2021 |
| Finest level | account, region, service | resource | project, service, region |
What it means for your cost
Emissions become a measure beside cost, grouped by the same cost dimensions (how grouping and filtering behave): account, subscription or project, service, region and month. The join works only at the finest level both datasets share: account, region and service at AWS, project, service and region at Google, the resource at Microsoft. None of the descriptions read lists tags or labels as a dimension of the emissions data, so assigning emissions to teams needs an account or project structure that follows the teams.
At two providers the emissions and cost data sit side by side: Google exports to BigQuery like the Google Cloud billing export, and AWS offers its own table in Data Exports next to the Cost and Usage Report. Where cost data is already mapped to a common schema such as FOCUS, matching account, service and region is the same work for every provider. Because Google weights by list price, discounts and commitments change the cost but not that part of the allocation.
Where it goes wrong
- Market-based figures read as location-based. Microsoft explains scope 2 values of zero in Carbon optimization by the market-based figure shown there. ESRS E1 asks for both.
- History changed by a methodology update. AWS recalculates history with each new version, Microsoft recalculated its data in February 2024, and Google can adjust earlier figures. A report quoting old numbers no longer matches the console unless an export with date and model version exists.
- Missing months. A month's figures arrive only in the following month: at Google on the 15th, at Microsoft by the 19th and at AWS by the 21st. A report that closes earlier has one month fewer, and new subscriptions at Microsoft show data only after at least a month.
- Units mixed. Google delivers kilograms, AWS and Microsoft tonnes; a sum without conversion is off by a factor of 1,000.
- Three providers added up as if one measurement. The system boundaries differ: Google excludes end of life, Microsoft counts selected scope 3 categories of hardware but not yet the data centre buildings, AWS leaves out offices and warehouses. How such figures are aligned is a methodological decision.
- History not saved. Microsoft keeps twelve months and is retiring its dashboard; without regular exports the prior-year comparison is lost.
Whether the providers' figures are sufficient for a sustainability statement and how they are adjusted is for the sustainability lead and the auditor to judge.
Sources
Read on 2026-10-16. EUR-Lex Directive (EU) 2022/2464 (CSRD), Directive (EU) 2025/794, Directive (EU) 2026/470, Delegated Regulation (EU) 2023/2772 (ESRS) and Delegated Regulation (EU) 2026/1563; GHG Protocol Corporate Value Chain (Scope 3) Standard; AWS AWS Sustainability, system boundary, allocation approach, key concepts, carbon emissions columns in Data Exports and Sustainability console; Microsoft Carbon optimization, troubleshooting, calculation methodology and Emissions Impact Dashboard; Google Cloud Carbon Footprint methodology, export and data schema.