Source-linked AI summary
Carbon accounting in the Cloud: a methodology for allocating emissions across data center users
Ian Schneider, Taylor Mattia
TL;DR
Because data center machines and workloads are shared among users, direct energy measurements alone are insufficient for organizational carbon accounting. This paper presents an allocation methodology that supports product- and location-specific carbon reporting; its approach is allocation-based rather than a causal estimate of emissions.
Problem
Data center machines and workloads can be shared among multiple users, so direct energy measurements alone are insufficient for organizational accounting.
Source: §2 · p. 3Method
The approach combines energy profiling with internal resource and cost accounting, including separate allocation of idle and dynamic machine power.
Source: §2 · p. 3, §3.3 · p. 7Results
The methodology supports carbon reporting data for enterprise customers of multiple Google products, including Google Cloud and Workspace.
Source: §1 · p. 2, §3.2 · p. 6Takeaways & Limitations
Region-level emissions estimates can help customers assess workload moves to lower-carbon regions when optimizing location-based emissions.
Source: §3.6.2 · p. 23The approach is allocation-based accounting; producing causal estimates of carbon emissions would require improving the allocation or departing from it.
Source: §4 · p. 25
Abstract
from arXiv · showhide
This paper presents a methodology for allocating energy consumption to multiple users of shared data center machines, infrastructure, and software. Google uses this methodology to provide carbon reporting data for enterprise customers of multiple Google products, including Google Cloud and Workspace. The approach documented here advances the state-of-the-art of large scale Cloud carbon reporting systems. It uses detailed, granular measurement data on machine energy consumption. In addition, it uses physical factors for allocating energy consumption and carbon emissions--preferred by the Greenhouse Gas Protocol's Scope 3 Reporting Standard. Specifically, the approach described here allocates machine energy consumption based on a combination of data center resource reservations and hourly measured resource usage. It also accounts for Google's own internal use of shared software services, reallocating energy use to the users of those shared services. Finally, it uses hourly, location-specific estimates of carbon intensity to precisely measure carbon emissions of users in a global fleet of data centers.
1 Introduction
Google developed granular, product- and location-level electricity and emissions data to support sustainability efforts and customer reporting. The methodology addresses the challenges of measuring and allocating energy across a large, globally distributed fleet with shared resources and incomplete physical data.
1 Introduction
- Google's 2022 electricity use was 22 TWh, with most consumption coming from data-center operations, despite efficiency improvements.By 2022, Google delivered approximately three times the computing power with the same electrical power as five years earlier.Source: §1 · p. 1
- Since 2020, Google has developed granular hourly electricity consumption and carbon-emissions data by product and location, building on a decade of aggregate operational electricity measurement.The information helps Google target data-center efficiency and flexibility efforts and provide customer carbon reporting data.Source: §1 · pp. 1–2
- The approach must account for millions of devices across hundreds of component and machine types, shared resources, internal use of products, and global carbon estimation.Physical data are unavailable or insufficient in some domains, requiring economic allocation in some calculations.Source: §1 · p. 2
2 Literature and State-of-the-art
Prior work has estimated data-center workload energy using proxies or workload duration, while this paper addresses the additional challenge of allocating measured energy across shared users. Accurate accounting and disclosure matter for customers reporting Cloud-related emissions and considering reductions.
2 Literature and State-of-the-art
- Accurate accounting and disclosure can support users—especially large business users—in making decisions to reduce emissions.Cloud-provider emissions relevant to serving a customer's needs fall under that customer's Scope 3 reporting.Source: §2 · pp. 2–3
- Google Cloud customers seek accurate emissions reporting and may be interested in reducing their Cloud-related data-center emissions.As of March 2024, over 50% of carbon emissions were already being monitored by Google Cloud customers.Source: §2 · pp. 2–3
- Direct energy measurements are preferred when available because estimated workload energy can differ substantially, but measurements alone do not allocate energy across shared users.The paper's primary contribution is a methodology for allocating energy use across users of shared machines, infrastructure, and software.Source: §2 · p. 3
3 Methodology
The methodology allocates energy to products and users, then accounts for location-based carbon emissions. It uses physical allocation where data are available and economic allocation where they are not.
3 Methodology
- The methodology provides granular product-level energy allocation and location-based carbon-emissions accounting at Google.It underpins Google Cloud Carbon Footprint reporting and supports estimates for many Google products and services.Source: §3 · pp. 3–4
- The methodology combines physical allocation when physical data are available with economic allocation when physical data or factors are unavailable.The approach follows the Greenhouse Gas Protocol's guidance and may shift to physical allocation as more suitable data become available.Source: §3 · p. 4
- The methodology section proceeds from key concepts and boundaries to machine and power allocation, shared-service reallocation, carbon measurements, and customer allocation.Its final described application is carbon accounting for Google Cloud customers through the Carbon Footprint reporting platform.Source: §3 · pp. 3–4
3.1 Key Concepts
The section defines operational terms for machines, users, resources, power, and emissions that frame the allocation methodology. These distinctions separate reserved resources from actual use and distinguish location-based from market-based emissions.
3.1 Key Concepts
- Idle power is the minimum draw while a machine is active, while dynamic power is measured power minus idle power.Busy power is the maximum draw while actual workloads run in a data center.Source: §3.1 · pp. 4–5
- Location-based emissions use data-center electricity consumption without direct clean-energy purchases, whereas market-based emissions account for Google's clean-energy purchases.PUE is total data-center power divided by IT power.Source: §3.1 · p. 5
- Resource allocation is the amount of a resource reserved for a production group or user, while resource usage is the amount actually used.Production jobs may reserve more than they use so they can scale to meet external demand.Source: §3.1 · p. 5
- A shared machine has multiple internal users; a dedicated machine has one machine owner, the production group controlling access and operation.A cluster is a group of production machines typically sharing a local network and located in one data-center building.Source: §3.1 · pp. 4–5
- A shared service combines software and resources provided by one internal team to other internal users, with Bigtable and Spanner as examples.A production job is a high-priority machine task that takes priority over lower-priority non-production jobs.Source: §3.1 · pp. 5–6
3.2 Boundaries and Exclusions
The paper’s Scope 2 boundary covers electricity use at Google-owned or operated data centers, including compute, networking, cooling, and lighting. It excludes Scope 1 and other listed activities; per-customer Scope 1 and Scope 3 estimates are outside this paper’s scope.
3.2 Boundaries and Exclusions
- The inventory covers Scope 2 emissions from electricity used by Google-owned or operated data centers, including compute, networking, cooling, and lighting.The paper focuses on this Scope 2 methodology; per-customer Scope 1 and Scope 3 estimates are described elsewhere.Source: §3.2 · p. 6
- Excluded emissions include transmission and distribution losses, fuel extraction and transport, generation-facility life-cycle emissions, and all Scope 1 emissions.Source: §3.2 · p. 6
- The boundary also excludes small equipment deployments at ISP partners, Google networking equipment outside data centers, and downstream end-of-life emissions from data center equipment and buildings.Source: §3.2 · p. 6
3.3 Machine Power Allocation
The methodology separates machine idle and dynamic power allocation to address shared machines, heterogeneous workloads, and non-proportional power use. It assigns idle power using ownership or resource allocations and dynamic power using hourly GCU usage.
3.3 Machine Power Allocation
- Separating idle from dynamic power reflects the approach that resource reservations drive idle power while actual use drives dynamic power.Measured power is sampled every five minutes and averaged for each hour; idle power is adjusted so it cannot exceed measured power, leaving nonnegative dynamic power.Source: §3.3 · pp. 7–8
- The approach distinguishes dedicated from shared machines and balances production reservations against non-production usage.In the simplified example, the production user receives all idle power, while the users split dynamic power according to utilization.Source: §3.3 · p. 8, Figure 1 · p. 9
3.3.1 Machine Idle Power Allocation
- Idle power was slightly larger than dynamic power for the illustrated cluster during September 18–24, 2023.Figure 2 shows hourly idle, dynamic, and total power as percentages of the cluster’s weekly average total power.Source: §3.3 · p. 9, Figure 2 · p. 10
- Idle power is allocated to dedicated-machine owners and across shared machines in proportion to users’ power-weighted resource allocations.The resource weighting combines GCU, HDD, SSD, and RAM allocations; nearly all ML machines are dedicated and therefore excluded from this shared-resource allocation.Source: §3.3 · p. 8, §3.3.1 · pp. 10–11
3.3.2 Machine Dynamic Power Allocation
- Dynamic power is allocated to users in proportion to their GCU usage on each machine during the hour.A user’s cluster allocation sums their shares across machines where they have non-zero GCU usage.Source: §3.3 · p. 8, §3.3.2 · p. 12
- GCU-based dynamic allocation may underestimate users with above-average memory use, especially on machines with substantial non-CPU resources.The authors note that storage machines typically have low dynamic range and most ML machines are dedicated, which can mitigate these shortcomings.Source: §3.3.2 · pp. 12–13
3.4 Reallocating Energy of Internal Services
Google reallocates energy from internal shared services to their users, using resource-usage data for major services and net-cost data for smaller ones. The combined process produces per-user energy totals by cluster after three rounds of shared-service reallocation.
3.4.1 Reallocating Energy of Major Shared Services
- Major shared services reallocate dynamic power to users using their service usage; Colossus weights GCU, HDD, and SSD usage by incremental power.Idle power is already attributed through resource allocations mapped to end users.Source: §3.4.1 · pp. 13–14
3.4.2 Reallocating Energy of Minor Shared Services
- Smaller services use net-cost proportions because granular data linking their users to consumed resources is unavailable; this covers about one-third of shared-service energy.The resource-based approach for major services covers approximately two-thirds; smaller-service reallocation uses cost data from Google’s Resource Economy.Source: §3.4.2 · pp. 14–15
- Two cost-based reallocation rounds handle shared services that themselves use shared services; further rounds changed emissions little in testing but would require more pipeline resources and processing time.Together with the earlier major-service round, the pipeline performs three total rounds of shared-service reallocation.Source: §3.4.2 · p. 17
3.4.3 Putting it All Together
- The final per-user, per-cluster energy totals account for machine usage, resource allocation, and use of dozens of shared services.The end-to-end allocation also incorporates idle and dynamic power and reallocations from major and minor shared services.Source: §3.4.3 · pp. 17–18
3.5 Incorporating energy overheads and carbon intensity
Google estimates location-based carbon footprints by combining each user’s hourly allocated IT energy with data-center overhead and grid carbon intensity. The estimates use location- and hour-specific intensity where available, but exclude Google’s clean-energy purchases.
3.5 Incorporating energy overheads and carbon intensity
- User-level location-based emissions combine hourly IT energy, data-center PUE, and the carbon intensity of the electricity zone serving each cluster.For locations without real-time intensity data, the method uses IEA annual grid averages.Source: §3.5 · pp. 18, 20
- The 2022 global mean across Electricity Maps zones was 320.8 gCO2e/kWh, with a standard deviation of 227.5 gCO2e/kWh; this distribution is not Google’s energy mix.The figure covers all zones and hours, while Google’s consumption is not equally distributed across those zones.Source: §3.5 · p. 19, Figure 6 · p. 20
- Electricity Maps estimates hourly, consumption-based intensity by tracing power flows between generation and consumption locations and applying emissions factors to the resulting generation mix.Google uses operational carbon-intensity values, rather than life-cycle assessment values.Source: §3.5 · p. 19
- The carbon estimates use base grid intensity and exclude Google’s carbon-free energy purchases, so they represent location-based rather than market-based emissions.For Google Cloud in 2023, market-based emissions averaged 63% below location-based emissions; the ratio varied by location and usage time.Source: §3.5 · pp. 20–21
3.6 Allocating carbon emissions to customers
Google allocates internally measured energy and emissions to Cloud SKUs, regions, and customer billing accounts. SKU allocation follows list-price proportions, while regional and account-level calculations include adjustments so allocated emissions sum to internally measured totals.
3.6 Allocating carbon emissions to customers
- The process maps SKUs to products and internal resource providers, allocates service energy to SKUs using revenue data, then adds product- and region-specific carbon intensity.The final account calculation uses each account’s SKU usage in each region.Source: §3.6 · p. 21, §3.6.1 · p. 22, §3.6.3 · p. 24
3.6.1 Using Revenue Data to Allocate Electricity to SKUs within Internal Services
- Within a product, allocated energy per usage unit is proportional to SKU list price while total allocated energy sums to the internal service’s measured consumption.The method uses total SKU usage and list prices, excluding commitment and usage discounts from the price measure.Source: §3.6.1 · p. 22
- List-price allocation may not reflect actual relative SKU energy use, so customers cannot use it to infer which SKU switch would reduce actual emissions.The authors give the example of equally electricity-consuming SKUs in the same region receiving different allocated footprints because their list prices differ.Source: §3.6.1 · p. 23
3.6.2 Google Cloud Products’ Carbon Footprint Per Cloud Region
- Regional estimates account for where customers can place workloads and allocate energy globally before adjusting for regional carbon intensity, so shared overhead resources are spread across customers.A reweighting term ensures the regional SKU emissions sum to the internal user’s measured carbon footprint.Source: §3.6.2 · pp. 23–24
3.6.3 Final Allocation to End Customers
- Customer billing accounts receive estimated emissions by Google Cloud product and region, reported per product, region, and month.The customer allocation includes an overhead adjustment so emissions not directly assigned to customers are allocated as well.Source: §3.6.3 · pp. 24–25
4 Future work and discussion
The approach prioritizes fair, Google-wide allocation, while leaving room to improve allocation assumptions, pursue causal estimates, and validate methods against direct measurements. Future work also addresses the current Scope 2 focus, hardware manufacturing emissions, and new reporting and optimization tools.
4 Future work and discussion
- The Google-wide allocation could replace economic factors such as cost or revenue with more specific physical resource and energy data.The paper describes this as a potential improvement to customer-allocation decisions that currently use economic factors.Source: §4 · p. 25
- For shared-machine dynamic power, the current model allocates by GCU usage; future work could also account for memory usage.The paper notes that users with above-average memory usage may be responsible for more energy consumption.Source: §4 · p. 25
- Causal emissions estimates could complement this accounting- and reporting-focused approach in some cases.The paper identifies more directly causal estimates as a possible departure from the existing allocation method.Source: §4 · p. 25
- Direct energy measurements for specific SKUs could help validate allocation-method improvements by comparing their accuracy.The paper qualifies this validation approach as possible when direct measurements are available.Source: §4 · p. 25
- The authors describe the allocations as a useful starting point, with future improvements helping identify software optimizations to reduce emissions.Source: §4 · p. 25
- The work covers Scope 2 emissions from purchased data-center electricity; future work should measure and allocate hardware manufacturing emissions as electricity-related emissions shrink.The paper says manufacturing emissions will become an increasingly important segment of data-center emissions as grids become cleaner and hourly matched carbon-free energy purchases increase.Source: §4 · pp. 25–26
- Future market-based reporting for Cloud customers will use annual emissions factors, while longer-term tools aim to help customers reduce electricity use and carbon emissions.The planned market-based metrics account for Google's carbon-free energy procurement and are anticipated to be used primarily for reporting.Source: §4 · p. 26