Cloud carbon and CSRD: what AWS, Azure and Google provide

For cloud carbon reporting under the CSRD, AWS, Azure and Google Cloud each provide monthly, estimated emissions by account, region and service, in a dedicated tool and never in the cost export. The revised ESRS place those figures as a subset of Scope 3, category 1 (purchased goods and services), even though the provider labels them as its own Scopes 1, 2 and 3. This guide shows what each source provides, what it cannot do, and how to prepare the data for ESRS E1 or a customer request. It is not legal or audit advice.

Who has to report under the CSRD in 2026

Scope has moved twice. The "stop-the-clock" Directive (EU) 2025/794 postponed the second wave by two years. The Omnibus Directive (EU) 2026/470, in force since 18 March 2026, limits the duty to companies with more than 1,000 employees and net turnover above EUR 450 million, for financial years starting on or after 1 January 2027. Member states must transpose it by 19 March 2027 and may exempt first-wave companies that fall out of scope for financial years 2025 and 2026.

In Germany, the government's CSRD transposition bill (Bundestag printed paper 21/1857) had its committee hearing on 13 April 2026. We could not find it promulgated in the Federal Law Gazette by 10 October 2026, so confirm the current position with your auditor.

The revised ESRS (Delegated Regulation (EU) 2026/1563) enter into force on 10 November 2026 and apply to financial years starting on or after 1 January 2027, with a choice between old and new versions for 2026.

Most startups and small companies will not report themselves, but reporting customers will ask them for data. The value chain cap applies: companies with up to 1,000 employees may decline requests beyond the datapoints listed in Annex II of the voluntary standard (Delegated Regulation (EU) 2026/1560), for financial years starting on or after 1 January 2027. For companies with more than ten employees that list includes the greenhouse gas figures of basic module B3, your own Scope 1 and location-based Scope 2. Scope 3, including your cloud emissions, is not on it.

Where cloud sits in ESRS E1

In the revised ESRS, disclosure requirement E1-8 asks for gross Scope 1, location-based and market-based Scope 2, and each significant Scope 3 category. Application requirement AR 24(g) asks companies, where applicable, to show emissions from purchased cloud computing and data centre services as a subset of Scope 3, category 1. Google and Microsoft say the same in their methodologies: the allocated figures are the customer's Scope 3.

The location-based versus market-based split is mandatory for your own Scope 2. For the cloud line in Scope 3, choose one basis and apply it consistently across providers and years.

What the three providers supply

Two dates and one limit belong in the calendar. Microsoft deprecated the Microsoft for Sustainability API on 30 May 2025 and points to carbon optimization. The Emissions Impact Dashboard retires on 31 March 2027, and Microsoft asks customers to export their data before then. Because carbon optimization keeps only 12 months, you need a monthly export to support a reporting year and its prior-year comparison.

What the data cannot do

• No per-workload precision. Providers allocate their emissions using usage and economic keys. Microsoft notes that usage for emissions calculations may not match usage for billing.
• No completeness. AWS excludes third-party software bought through AWS Marketplace; Google lists services it does not cover. SaaS tools, colocation and devices are missing entirely.
• No assurance. Google states that its customer-specific data has not been third-party verified or assured and may change materially with methodology updates.
• No stable history. AWS recalculates history with each new model version; older versions survive only in a data export, under their own prefix. In Google's BigQuery export, corrections arrive only through a manual backfill.
• No conversion from euros. An emission factor applied to cloud spend ignores region, grid mix and discounts. For gaps, a spend-based estimate can be a documented fallback; for covered services it does not replace provider data.

Archive the data every month

AWS and Google exports can be summarised in SQL. For Google Cloud's BigQuery export:

SELECT
  usage_month,
  project.id AS project_id,
  carbon_model_version,
  SUM(carbon_footprint_total_kgCO2e.location_based) AS kg_co2e_location_based,
  SUM(carbon_footprint_total_kgCO2e.market_based) AS kg_co2e_market_based
FROM `{project}.{dataset}.carbon_footprint`
WHERE usage_month BETWEEN DATE '2026-01-01' AND DATE '2026-12-01'
GROUP BY usage_month, project_id, carbon_model_version
ORDER BY usage_month, project_id;

For the AWS table, for example with Athena over the S3 export:

SELECT
  usage_period_start,
  usage_account_id,
  model_version,
  SUM(total_lbm_emissions_value) AS mtco2e_location_based,
  SUM(total_mbm_emissions_value) AS mtco2e_market_based
FROM carbon_emissions
GROUP BY usage_period_start, usage_account_id, model_version
ORDER BY usage_period_start, usage_account_id;

Keep the model version in every summary. Two months calculated with different versions are comparable only after a recalculation.

A sequence for a report or a customer request

1. Clarify your role. Do you report under ESRS, answer a customer under the voluntary standard, or volunteer more? That sets the depth.
2. Set up the exports. The AWS data export for the emissions table (permission sustainability:GetCarbonFootprintSummary), the Google BigQuery transfer (role roles/billing.carbonViewer) and the Azure carbon optimization API (Carbon Optimization Reader role), monthly.
3. Store immutably. Archive each monthly cut with retrieval date and model version; never overwrite.
4. Fix the basis. Market-based or location-based, the same for all providers. For Azure, the documentation shows only market-based Scope 2.
5. Map the reporting boundary. Assign accounts, subscriptions and projects to legal entities, using the same mapping as your monthly cloud cost review.
6. Close the year late enough. Wait for the latest provider date, which means not before 21 January for AWS December data.
7. Document gaps. Show uncovered services, Marketplace purchases and other SaaS suppliers separately, with method and assumptions.

What Costfluent contributes

Costfluent does not report emissions. What transfers is the habit of a cost report: a saved report in cost reports shows cloud cost by account, service and tag, and a report subscription sends a monthly link to the live view. If the emissions register and the cost report use the same account mapping and cut-off date, your team can see where cost and emissions diverge. For setting up the billing exports themselves, see AWS CUR 2.0 or FOCUS 1.2 and Google Cloud billing export for cost reporting.

Sources and method

Checked on 10 October 2026: Directive (EU) 2025/794, Directive (EU) 2026/470, Delegated Regulation (EU) 2026/1563 (revised ESRS), Delegated Regulation (EU) 2026/1560 (voluntary standard), Commission on the revised ESRS, Bundestag committee hearing on sustainability reporting, AWS Sustainability: getting started, AWS carbon emissions table in Data Exports, AWS carbon emissions table columns, AWS Sustainability key concepts, AWS calculation methodology, AWS methodology and system boundary, Azure carbon optimization, Azure carbon optimization: view emissions, Microsoft Emissions Impact Dashboard, Microsoft calculation methodology, Microsoft sustainability deprecations, Google Cloud Carbon Footprint methodology, Google Cloud BigQuery export, Google Cloud export schema, Google Cloud release notes. The tables, queries and steps are Costfluent recommendations, not legal, tax or audit advice.