GreenOps explained: cloud carbon accounting from Scope 2 to embodied carbon

GreenOps — applying FinOps discipline to the environmental footprint of cloud workloads — graduated from a buzzword to a named capability: the FinOps Foundation's 2026 framework renamed and broadened its Sustainability capability to cover carbon allocation across cloud, SaaS, on-prem and end-user computing. Meanwhile the EU AI Act has made energy documentation mandatory for general-purpose AI models, and CSRD — though reduced — still requires the largest cloud customers to report auditable Scope 3 numbers.

What is still missing is a clear, end-to-end explanation of how a cloud bill becomes a carbon number. This guide is that explanation: the GHG Protocol mapping, the estimation pipeline (usage → kWh → PUE → grid factor), embodied hardware carbon, the SCI standard, water, and the state of the three hyperscalers' own tools as of mid-2026.

Where cloud emissions sit in the GHG Protocol

From your point of view as a cloud customer, every kilogram of CO₂e your workloads cause is Scope 3, category 1 — "purchased goods and services". Microsoft states it directly: emissions from Azure services are reported as Microsoft's Scope 1, 2 and 3, which "collectively become customers' scope 3 emissions as defined by the GHG Protocol".

On the provider side, the decomposition is: Scope 1 — diesel generators, natural gas, refrigerants in the datacenter; Scope 2 — the electricity those datacenters draw; Scope 3 — manufacturing the servers (cradle-to-gate), constructing the buildings, fuel- and energy-related activities, transport. Provider carbon tools redistribute all three to customers pro-rata to usage or cost. So when a tool shows "your cloud carbon footprint", it is showing you an allocated slice of someone else's inventory — which is why methodology matters so much.

Location-based vs market-based: the number that changes everything

GHG Protocol Scope 2 has two accounting methods, and they produce wildly different numbers for the same workload:

• Location-based (LBM): the emission factor of the actual local grid where the datacenter sits — ideally at hourly resolution. This is the physical signal.
• Market-based (MBM): accounts for the provider's contractual clean-energy purchases (PPAs, RECs/GOs). Hyperscaler MBM figures are near zero in many regions because of their PPA portfolios.

Both are legitimate — for different jobs. MBM belongs in inventory reporting. But for optimization decisions, LBM is the only signal that responds to your actions: moving a workload from a coal-heavy grid to a clean one changes real-world emissions; it does not change Amazon's PPA contracts. A GreenOps tool that only shows market-based numbers will tell you everything is already green and there is nothing to do.

This distinction is about to get sharper: the GHG Protocol's Scope 2 revision (public consultation closed January 2026, revised draft expected later in 2026) proposes hourly matching and deliverability requirements for market-based claims. Hourly granularity is becoming the de facto standard — which favors whoever computes emissions hourly today.

The estimation pipeline: usage → kWh → PUE → grid factor

Providers publish monthly, lagging, partially-scoped numbers (see below). For anything near real time, multi-cloud, or per-resource, the industry-standard methodology is the one pioneered by Etsy's Cloud Jewels (2020) and operationalized by Cloud Carbon Footprint (CCF):

Total CO2e   = operational emissions + embodied emissions
Operational  = usage × energy coefficient (kWh)
               × provider PUE
               × grid emission factor (CO2e/kWh)
Compute kWh  : avg watts = min + utilization × (max − min)

Three honest limitations to keep in view. Default utilization: without real metrics, CCF assumes 50% CPU utilization — feed it actual CloudWatch/Monitoring data and accuracy improves substantially. Hardware blind spots: custom silicon (Graviton), GPUs and serverless need separate adjustments; the coefficients above were derived from x86 server data. Stale PUE constants: CCF hardcodes PUE at 1.135/1.1/1.185, but 2024 disclosures put AWS at 1.15 fleet-wide and Google at 1.09 — better practice is per-region values from the Green Software Foundation's ratified Real-Time Cloud dataset, which publishes PUE, WUE, carbon-free-energy % and grid region for AWS, Azure and GCP regions.

For the grid factor itself, the two reference sources are Electricity Maps (flow-traced average intensity, hourly, historical + 72h forecast; it supplies Google Cloud's hourly data and dropped its marginal signal in 2025) and WattTime (marginal intensity). The 2026 consensus: average/flow-traced for reporting, marginal reserved for real-time scheduling decisions.

PUE, WUE and CFE: why region choice dominates

The number that should drive decisions is the regional variance: Google publishes CFE% per region, and it ranges from 12% to 92%. The same workload, same provider, same cost can differ by ~7× in carbon purely on placement. Region selection is the #1 GreenOps lever — ahead of rightsizing, ahead of scheduling — and it is the one no provider tool will proactively recommend across clouds.

Also worth internalizing: Google's datacenter energy use grew ~44% in two years on AI demand. Efficiency gains no longer offset growth, which is exactly why customer-side optimization (placement, scheduling, rightsizing) is back on the agenda.

Embodied carbon: the Scope 3 everyone skips

Manufacturing the server fleet emits carbon before your first vCPU-hour. Order of magnitude from manufacturer disclosures: a mainstream rack server carries ≈ 1,726 kgCO₂e embodied, ≈ 432 kgCO₂e/year amortized over Dell's standard 4-year life — roughly 20% of lifecycle emissions, rising to ~33% if the lifetime doubles. HPE's ProLiant DL380 Gen10 data shows embodied share ranging 15.4% to 43.3% of lifecycle depending on configuration and region — embodied *dominates* wherever the grid is clean (Nordic regions, hydro-heavy zones).

Amortization assumptions move the answer materially: Dell assumes 4 years, while AWS amortizes IT hardware over 6 years and buildings over 50 in its carbon methodology. For multi-cloud or long-tail providers with no carbon tool at all, the open reference is Boavizta — a bottom-up API that computes embodied impacts per instance type (and goes beyond carbon: primary energy and abiotic resource depletion).

One research caveat worth knowing: the "sunk carbon fallacy" (arXiv 2410.15087) — using amortized embodied carbon in *scheduling* decisions can mislead, because that carbon is already spent. Report embodied; optimize on operational.

SCI: the ISO standard for software carbon — and SCI for AI

SCI = ((E × I) + M) / R     — ISO/IEC 21031:2024
E = energy (kWh)
I = grid carbon intensity (gCO2e/kWh, location-based)
M = embodied carbon, amortized
R = functional unit (request, user, transaction…)

The Software Carbon Intensity spec became ISO/IEC 21031:2024 and has three properties that make it the right KPI shape: it is a rate, not a total (comparable across systems and over time); offsets are excluded (only real reduction moves the score); and it uses location-based intensity (the physical signal).

On 17 December 2025 the Green Software Foundation ratified SCI for AI — the first standard for measuring AI emissions across training and inference. It defines separate provider and consumer scores and standardizes functional units: tokens for LLMs, inferences for classifiers, FLOPs for training efficiency. The GSF positions it explicitly as an EU AI Act compliance tool. If you run AI workloads, carbon-per-token is no longer a vanity metric — it is the unit the ratified standard prescribes.

Water: the next disclosure

Water follows the same pipeline with one extra factor: `liters = estimated kWh × regional WUE (L/kWh)`. WUE per region is available in the Real-Time Cloud dataset and provider disclosures (AWS 0.15 L/kWh fleet average 2024; Microsoft 0.30, with zero-water datacenter designs announced for 2026). With AI driving datacenter siting fights over water, expect WUE to follow PUE into standard reporting.

What the providers give you in 2026

Two 2026 changes matter operationally. AWS added Scope 3 (including cradle-to-gate hardware) in October 2025, then announced that the Customer Carbon Footprint Tool is deprecated on 30 June 2026 in favor of the new AWS Sustainability console with programmatic API/SDK access — any ingestion built on CCFT needs migrating before that date. GCP remains the methodological leader: its Scope 2 location-based figures are computed at hourly resolution using Electricity Maps data.

The practitioner hierarchy that follows: provider data is the truth for inventory reporting (monthly, lagging, heterogeneous methods); bottom-up estimation (CCF/Boavizta + Real-Time Cloud + Electricity Maps) is the tool for optimization — near-real-time, homogeneous across clouds, and available on providers that ship no carbon tool at all (OCI, Alibaba, DigitalOcean, Linode). The differentiator almost nobody does: reconcile the two — calibrate estimates against the official monthly numbers and disclose the gap.

The 2026 regulatory picture, in three lines

• CSRD survived, reduced: the Omnibus directive (in force March 2026) limits mandatory reporting to companies with >1,000 employees and >€450M revenue — ~80% of firms exit the obligation, but the large cloud spenders that remain still need auditable Scope 3 cloud data, and they will push the ask down their supply chain.
• EU AI Act: since August 2025, every general-purpose AI model provider must document the model's energy consumption — measured, or estimated from compute. A standardization request on AI resource reporting is expected in 2026. This is the strongest live driver for carbon-per-inference metering.
• US: the SEC proposed rescinding its climate disclosure rules entirely (May 2026). The regulatory driver for GreenOps is, for now, almost exclusively European.

Putting it into practice

A workable GreenOps rollout in 2026 looks like: ingest the provider numbers monthly for the inventory baseline; estimate bottom-up hourly for decisions; rank regions by CFE/PUE/WUE next to price; report SCI per workload (and SCI-for-AI per model, in tokens); and attach a CO₂e delta to every cost recommendation so finance and sustainability stop working from different lists.

That last point is the thesis behind how Cloudios works: every optimization finding carries euros and CO₂e (Scope 2 location- and market-based, Scope 3 embodied via Boavizta, water) on the same line, so a rightsizing or region move is approved once, with both numbers visible. You can see it on real findings in the live demo — no sign-up needed.