Carbon Footprint reporting methodology
This page explains the background, high-level methodology, and technical details behind the customer-specific gross greenhouse gas emissions reports provided by Carbon Footprint.
About Carbon Footprint reporting
To help customers run their business with as light a footprint as possible, Google Cloud offers Carbon Footprint. It provides visibility for each customer into the climate impacts of products purchased from Google Cloud so that customers can report on and take action to reduce those impacts.
Google Cloud customers generally use a diverse portfolio of Google Cloud products in multiple regions, making the tracking of their workloads' carbon footprint complex. Most estimates to date use simplified assumptions about usage and location on a yearly timescale. Without details that can be made available only by the cloud service provider, customers are making rough estimates, such as using a revenue apportionment over the total emissions of the cloud service provider, or using industry average of IT hardware consumption.
To give customers a report tailored to their specific carbon footprint, Google looks at the gross carbon emissions produced by the computing infrastructure supporting its internal services. Google apportions those gross emissions to each Google Cloud product, and allocates the emissions to a customer based on the customer's usage of those Google Cloud products.
Behind the methodology
Carbon Footprint reports are prepared according to the widely recognized Greenhouse Gas Protocol carbon reporting and accounting standards (GHGP), which provide detailed guidance for emission reports. Customers can integrate Google Cloud emissions data into their own reports as Scope 3 emissions (indirect emissions related to the value chain).
Carbon Footprint uses the GHGP's location-based reporting method for electricity, which means the footprints represent gross emissions arising from all electricity generation sources in use in a given location. The footprints do not take into account Google's renewable power purchase agreements or other contracts we sign to ensure we receive carbon-free electricity, which can be included in a market-based approach.
Carbon Footprint uses hourly greenhouse gas emission factors because the electricity generation plants supplying electricity to the grid are constantly changing; an hourly greenhouse gas emission factor takes into account the mix of generation sources in use hour-by-hour. When matched with hourly electricity load data, this calculation method results in an emissions figure that is sensitive to the relationship between electricity demand on the grid and the resources called to supply it.
Carbon Footprint builds its calculations from bottom-to-top, relying heavily on machine-level power and activity monitoring inside Google data centers. This lets us allocate gross emissions to the internal services that are directly using these machines or driving machine purchasing decisions. This level of granularity ultimately enables us to apportion gross emissions to customers based on their specific usage.
Using machine-level data and hourly emission factors is a new approach and therefore these gross emissions reports have not yet been third-party verified. Whereas Google's top-down footprint reported annually is assured for accuracy, the data streams and processes required to produce these customer reports have not been similarly assured. However, a third party performed a detailed review to critique and improve our work, and we look forward to further refinements as this effort matures.
The Carbon Footprint report encompasses gross emissions arising from the following activities:
- Google Cloud product electricity use, including that from Google-owned compute and networking equipment as well as ancillary electricity services such as cooling and lighting, whether inside a Google-owned data center or a facility owned by others
- Upstream (cradle-to-gate) emissions associated with electricity generation facilities and fuels, for most of the electricity loads
The Carbon Footprint report excludes emissions arising from the following activities due to data prioritization and availability. Of these, the first category may be large compared to the emissions reported, and the second may be small, but material. Based on Google's company-wide emissions reporting, the remaining exclusions are estimated as immaterial for cloud customer reporting:
- Upstream/downstream lifecycle emissions of data center equipment and buildings
- Generating electricity that is subsequently lost during transmission and distribution
- Combusting diesel for onsite backup power; fugitive emissions from HVAC system coolants
- Emissions arising from small equipment deployments at internet service provider partners
- Emissions from Google networking equipment deployed outside data centers
The Google Cloud customer-specific gross carbon footprint report (the "Carbon Footprint report"), is calculated automatically. This section describes how Google Cloud makes those calculations.
- Google Cloud is a shared computing platform. Its compute resources -- processing power, memory, storage, networking, etc. -- are shared across Google Cloud customers.
Google is organized around units of functionality called internal services. An internal service is a particular software functionality that's run on Google's data center machines. Google Cloud products use internal services and are consumed as customer-facing product units (SKUs).
Electricity use is one of Google Cloud's largest sources of greenhouse gas emissions. Data centers consolidate compute resources into shared buildings. These buildings consume electricity to run the computing equipment and additional power for lights, cooling, power systems, and other ancillary needs.
Electricity is provided by a wide variety of generation plants operating on individual grids all over the world. The greenhouse gases arising from electricity generation vary with the generation fuel (e.g., natural gas, coal, wind, sun, water) among other factors. Each grid's generation sources differ, and within a grid, the sources will differ over the course of a day.
Disaggregating Google Cloud's electricity use and its resulting gross carbon footprint to specific products and customers presents a technical conundrum. A customer's gross footprint tracking is very complex due to the layers of shared resources called upon to serve customer compute needs. Developing new apportionment methodologies and assumptions (as discussed in detail below) enables Google Cloud to present customer gross footprint reports that are appropriate and representative of each customer's cloud computing use and product choices.
Carbon Footprint first calculates energy use as a function of compute usage and data center resource requirements, then it calculates gross carbon emissions, and finally it allocates the gross carbon emissions across customers and further across each customer's purchased products.
Energy use and allocation to internal services
In order to apportion the total machine energy usage to internal services, Google separately evaluates the energy used when running a workload ("dynamic power") against the energy used when machines are idle ("idle power"). Each machine's hourly dynamic power is allocated to the internal services it supported that hour, based on relative internal service CPU usage. Machine idle power is allocated to each internal service based on its resource allocation (CPU, RAM, SDD, HDD) in the data center.
Overhead energy use–power systems, cooling and lights–is allocated hourly to every machine, and its users, based on the machine's total energy use that hour.
Google's shared infrastructure services track the usage of other internal services that call them. This enables the shared infrastructure services' energy usage to be reapportioned to those internal services based on their relative usage. For some internal services that do not have sufficient usage data, Google uses internal costs to reallocate the shared infrastructure's energy consumption.
When these calculations and allocations are complete, we have hourly power use allocated to each internal service in each data center.
Greenhouse gas emissions
Google calculates greenhouse gas emissions on an hourly basis, multiplying location-specific energy use by a grid electricity carbon emission intensity factor. Calculations are denominated in kilograms of carbon dioxide equivalent (kgCO2e), the worldwide standard for greenhouse gas emission reporting.
The hourly grid carbon emission intensity data is provided by Tomorrow's electricityMap. Their emission factors include both electricity production emissions, as well as emissions from activities further upstream, such as construction of the generation plant, and the extraction, production and transportation of fuels from their originating source to the electricity plant. Where Tomorrow data is unavailable, Google uses country-specific annual average carbon intensity factors published by the International Energy Agency. These factors reflect electricity production only.
To calculate emissions, Google multiplies the hourly energy use for each internal service at each location by the appropriate carbon emission intensity factor for that hour and location to determine the internal service's gross carbon footprint per hour and location.
Allocation to SKUs
Every Google Cloud product is consumed as customer-facing product units, identified by their unique SKUs. Google links each SKU to the internal service that provides it (which often has a one-to-one mapping to the equivalent Google Cloud product). Not all Google Cloud products are covered by the Carbon Footprint report because this mapping isn't always possible. SKU usage is the primary means of allocating each Google Cloud product's total gross carbon footprint amongst its customers.
Google first quantifies each SKU's gross footprint. An internal service's gross carbon footprint is divided amongst its SKUs proportional to their usage (quantity purchased) and list prices (all in US dollars), while also accounting for different carbon intensities in each location where the internal service is deployed. This apportionment is solved as a series of equations that satisfy the following principles:
- SKUs for a given internal service deployed in the same location have gross carbon footprints that are proportional to their list price
- A specific SKU for a specific internal service, deployed in multiple locations, has different gross carbon footprints in each location, proportional to the grid carbon intensity in each location
- The aggregated gross footprint of all the SKUs within each internal service is equal to the total gross carbon footprint of the internal service, plus some overhead for certain activities that are not accounted for in the internal service allocations described above. The gross carbon footprint aggregated across all SKUs is equal to the total Google Cloud gross carbon footprint.
Allocation to customers
Solving these equations results in a total gross carbon footprint for each SKU in each region where the SKU is deployed. The last step is to apportion the SKU regional gross carbon footprints to specific customers, aggregated into meaningful units (products, projects, regions).
- First, each SKU's gross carbon footprint is divided by the total SKU usage (volume metric) for a given region to establish each SKU's per-usage carbon intensity factor for that region.
- Each customer's usage of each SKU in each region is then multiplied by the respective SKU carbon intensity factor. This results in a per-SKU, per-region, per-customer gross footprint.
- The customer SKU gross footprints are then aggregated into customer-specific Google Cloud product gross footprints to increase the confidence in the reported carbon emission numbers.
- Finally, the data is aggregated to a monthly granularity to minimize daily fluctuations. The resulting report includes a customer specific gross carbon footprint that is totalized overall per month, with breakdowns per Google Cloud product, per customer-defined project, and per region.
Note that there is validation performed to ensure the aggregation of all the customer gross carbon footprints is equal to the total Google Cloud gross carbon footprint.
This section describes Google's method for bottoms-up energy consumption calculations.
First, every machine runs workloads for one or more internal services. Google records the internal services using each machine, on an hourly basis. Similarly, Google also records power use by machine, on an hourly basis.
A machine's power use will be a mix of power used to execute workloads (dynamic power), and power used when the machine is idle (idle power). There are two different methods to allocate these machine-level power uses to the internal service level:
- Each machine's hourly dynamic power is allocated to the internal services it supported during that hour. When a workload is running, the major resource contributor to energy consumption is CPU usage. Google monitors CPU usage inside its data centers per machine and internal service workload. If one internal service is using the machine, it allocates the machine's dynamic energy consumption to that internal service. If a machine supported more than one internal service, Google allocates the dynamic power proportional to the CPU usage of each internal service running on the machine.
- Idle energy consumption is allocated to Google internal services based on each internal service's resource allocation in the data center. An important driver of machines at idle is the desire to have compute resources (CPU, RAM, HDD, SDD) "at the ready" to execute uncertain but potentially large workloads without delay or interruption. Idle power is distributed based on the level of compute resources that has been purchased, whether or not the internal service is using those resources. This allocation results in idle power allocations per internal service, for each data center location.
Data center electric overhead load (power systems, cooling, lights) is then allocated to every machine within the data center. Google measures this load at the building level and estimates it more finely at the sub-building level, using validated algorithms as part of Google's Power Usage Effectiveness monitoring system. The sub-building estimates are allocated across the sub-building sector's deployed machines in the same proportions as the completed dynamic and idle power allocations.
Next, the power required by the shared infrastructure services software layer is allocated based on the usage of those infrastructure services by higher-level internal services. Overhead load for shared infrastructure services is included in their allocations. These allocations remain at the internal service (not machine) level.
For the internal services that do not have sufficient usage data, Google uses back-charged costs between the internal services to reallocate the shared infrasctructure's energy consumption. For example, Artifact Registry uses Cloud Storage. So, the fraction of Cloud Storage's energy use that is reallocated to Artifact Registry is Artifact Registry's cost for using Cloud Storage's service divided by Cloud Storage's total costs. Some internal services are revenue-neutral. If an internal service is revenue-neutral or revenue-positive, all of its energy use will be reallocated to the other internal services that use it.
Greenhouse gas emissions
Grid carbon emission factors begin with electricity generation data from balancing authorities. This data provides the intraday energy mix, which is the relative production of electricity by the different electricity plants available on the grid. Tomorrow then adds the real-time electricity import and export between interconnected grids.
Finally, Tomorrow uses the Intergovernmental Panel on Climate Change (IPCC) (2014) lifecycle electricity generation emission factors for each electricity generation source (e.g. coal, natural gas, hydropower, etc.) to create a volume-weighted hourly carbon intensity factor (emissions per megawatt-hour generated) for each electric grid. You can review Tomorrow's carbon intensity factors on electricityMap.
The IPCC lifecycle emission factors used by Tomorrow include emissions from electricity generation and from activities further upstream. Upstream activities may include construction of the generation plant including raw materials production, and the extraction, production and transportation of fuels from their originating source to the electricity plant.
Note that Tomorrow does not provide data for all Google Cloud locations, with particular gaps in Asia. Where Tomorrow data is unavailable, Google uses country-specific annual average carbon intensity factors published by the International Energy Agency; these are operational emission factors only, without lifecycle data.
Google maps the relevant carbon emission intensity factors to each of its Cloud locations. We then multiply the hourly energy use for each internal service at each location, by the appropriate carbon emission intensity factor for that location to determine the internal service's gross carbon footprint per hour and location. Each internal service's gross carbon footprint is summed every 24 hours to create a daily gross carbon footprint for that internal service in each location. These gross footprints are summed daily into a internal service footprint per Google Cloud region, as well as a worldwide total.
Allocation to SKUs and customers
Each internal service's gross emissions are apportioned to Google Cloud product units available for customer purchase (SKUs), and then the SKU gross footprints are aggregated to Google Cloud product for the purpose of customer reports.
Every Google Cloud product comprises one or more customer-facing units available for purchase and identified by unique SKUs (see all Google Cloud SKUs). For example, Cloud Storage is a service and Cloud Storage "Standard Storage Finland", "Nearline Storage Finland", "Coldline Storage Finland" and "Archive Storage Finland" are SKUs representing different classes of storage of the Cloud Storage service in Finland (see all the Cloud Storage SKUs).
Google Cloud uses "SKUs purchased" as the primary means of allocating each Google Cloud product's total gross carbon footprint amongst Google Cloud customers. It helps to note that most Google Cloud SKUs are volumetric. For example, some storage SKUs are priced and purchased on a per-terabyte basis. The volume quantity of a customer's purchase of any given product (which we call "SKU usage") is an important factor in data center obligations and load.