Cloud computing powers over 90% of enterprises (Cloudzero, 2025), but its impact on carbon remains a black box. While standards exist for manufacturing and logistics emissions, methods for calculating the carbon costs of the cloud are so inconsistent that the two most common approaches produce results differing by 50x. With regulators closing in, that ambiguity is becoming a liability.
The cloud exists to effectively outsource computing. In a non-cloud setup, an organisation runs its own applications with physical hardware onsite. The cloud outsources this resource-heavy process by allowing organisations to rent server capacity in datacentres. This means that for the more than 90% of companies that purchase cloud computing services, the cloud is a source of Scope 3 emissions: CO2 that is emitted by activities that the company is responsible for, without burning fossil fuels onsite (Scope 1) or purchasing electricity (Scope 2).
Organisations are facing increasing pressure to report their Scope 3 emissions. The EU is leading the way in mandating Scope 3 reporting with the Corporate Sustainability Reporting Directive, and countries around the world are following suit by beginning to adopt the International Financial Reporting Standards S2 standard. As a result, organisations of all sizes, from all industries, are faced with the task of accounting for their full carbon impact for their full value and supply chain – including the cloud.
However, until recently, the carbon impact of the cloud has been poorly understood. Sustainability leaders are left to choose between wildly unreliable spend-based factors, or Cloud Service Provider (CSP) estimators with opaque methodologies and a vested interest in reporting low emissions. When given the same input data, spend-based factors deliver carbon emission figures more than 50x larger than CSP estimators. In response to this lack of clarity, organisations like Boavizta and Tailpipe have proposed a new, usage-based methodology to make cloud carbon reporting simple and accessible. Tailpipe assessed its own carbon emissions from its cloud use from January to December 2025, resulting in a figure of 553 kilograms of greenhouse gases (or, kgCO2e) – seven times smaller than spend-based factors, and eight times larger than CSP estimations.
How does the cloud generate emissions?
Every request to the cloud is routed to a server in a datacentre somewhere in the world. Cloud computing generates carbon emissions from the energy consumption of the computing equipment inside these datacentres. These servers require constant power, which increases with utilisation – the level of intensity at which the computing equipment is working. Very large, ‘hyperscale’ datacentres therefore draw a vast amount of electricity from local energy grids, and when those grids are predominantly powered by fossil fuels, it makes them responsible for the subsequent release of CO2e into the atmosphere. This demand is only growing as the world becomes increasingly digital, with datacentre energy consumption expected to more than double between 2024 and 2030 (IEA, 2025).
Spend-based Factors: Seven times too big?
Many estimations of cloud emissions currently being reported by organisations are based on spend-based factors, which use the amount of money spent by an organisation on a service as the coefficient for the organisation’s carbon emissions. The most commonly used spend-based factors for cloud are USEEIO, OpenCEDA, and EXIOBASE. These databases calculate carbon emissions per dollar spent by dividing an estimation for the total input spend on an industry by its total output emissions. These factors are unfit for purpose, overestimating emissions against a usage-based model by up to seven-fold, as the following table shows for Tailpipe’s spend and usage of cloud computing in 2025:
Spend-based emissions factors misrepresent the relationship between the usage of cloud computing and carbon emissions. There is no direct correlation between cloud spend and emissions: instead, the relationship depends on how intensively an organisation uses the cloud. It is actually possible for emissions to increase when spend drops, and vice versa. For example, Company A and Company B might be paying the same amount to host their websites in the cloud, but whilst Company A processes hundreds of visitors an hour, Company B has just a handful. In this case, Company A will be sending hundreds of requests to a cloud server, demanding hundreds of watts of power (and therefore, causing greater emissions), whilst Company B requires just a few watts of power to keep its website running.
Additionally, despite being separate data sources, these three different emissions factor models are calculated based on the same economic input and carbon output datasets, covering the period between 2007 and 2017. Not only are they outdated, but they also collate every software, data processing, and computing process under the same category: ‘data processing, hosting, and related services’ in USEEIO and OpenCEDA, and ‘computer and related services’ in EXIOBASE. Organisations that use spend-based factors therefore fail to account for the specificity of cloud usage patterns, and the differentiation between cloud workloads. They also offer no insight into how to reduce cloud emissions, beyond simply spending less – and therefore, using fewer cloud services.
Cloud Service Provider Estimations: Eight times too small?
The three big Cloud Service Providers (CSPs) – Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) – do provide carbon estimations to their customers. These CSPs calculate cloud emissions with varying levels of granularity, but all adopt a top-down approach that calculates either total hardware power consumption (Azure and GCP) or total datacentre power consumption (AWS) before allocating emissions to individual customers based on the proportion of server resources they have been allocated. This approach is much more reliable than spend-based factors, but it does not recognise real-time utilisation of resources.
To take one example, AWS’ Customer Carbon Footprint Tool (CCFT) delivers both location-based and market-based emissions figures with a three-month lag. Location-based emissions look at the actual carbon intensity of the grid mix that powers a datacentre and multiplies it by the power drawn by it. Market-based emissions deliver lower carbon figures because they factor in AWS’s carbon offsetting and energy matching schemes.
A usage-based model does not account for offsetting or energy matching, because it reports the actual carbon emitted into the atmosphere as a result ofelectricity consumption. AWS does not document how it accounts for the emissions figures presented in Tailpipe’s billing account, beyond the high-level, generic overview provided in its Customer Carbon Footprint Methodology, which lacks any input data that would allow customers to verify their carbon figures. The AWS customer dashboard also only delivers the two figures above, with no further granularity or recommendations for how to reduce them. Without recommendations on how to reduce their emissions from cloud computing, organisations cannot deliver actionable carbon reduction strategies – other than, again, using the cloud less.
The Tailpipe Approach: How does it work, and why should I trust it?
Tailpipe has pioneered a ground up approach to calculating cloud carbon emissions, which starts with the power draw of the hardware that an organisation is using. Drawing from an organisation’s CSP billing and operational data, computing equipment manufacturer specifications, and data aggregators like non-profit Boavizta, Tailpipe knows exactly when and where an organisation is using the cloud, their level of utilisation, and the specific CPU, RAM, and GPU models being utilised at that time, along with the average power draw of other hyperscale datacentre server equipment. It uses this data to calculate the power consumption of that hardware in 5% CPU utilisation increments, based on lab-based stress-testing of CPU, RAM, and GPU models (documented in Tailpipe’s Methodology).
With electricity consumption calculated, Tailpipe factors in the carbon intensity of the local grid that power the datacentres in which an organisation’s cloud services are located, delivering granular emissions data at the service and component level. It then compares these emissions figures with best practice models, to suggest easy-to-implement and tailored recommendations to cut cloud emissions by up to 90%. This has the additional benefit of often reducing spend with the CSPs, since energy-efficient infrastructure is often cost-efficient infrastructure.
To ensure that its data is reliable, Tailpipe carries out regular data validation tests. Tailpipe lab-tests the power consumption of bare metal and datacentre-based servers, comparing these empirical figures to those calculated using its own methodology. Tailpipe always achieves a less than 10% variance between calculated and measured power and uses these tests to fine tune its methodology.
What does this all mean?
Right now, datacentres generate as much carbon in a year as the entire aviation industry does in five months (IEA, 2025). As cloud services expand, AI consumes more energy, and day-to-day experiences become increasingly digitised, the cloud’s responsibility for global emissions will only grow. At the same time, organisations that use cloud services will be expected to understand and to cut their cloud carbon emissions, and they need the tools to do so – fast. With spend-based factors unfit for purpose, and cloud service provider estimations purposefully opaque, a new set of independent, cloud-specific tools are needed to optimise a more efficient, more sustainable cloud.
Find Out More
For a more detailed breakdown of how Tailpipe calculates emissions, see the Tailpipe Methodology. For an explanation of how Tailpipe can reduce an organization’s cloud spend and carbon emissions, see Tailpipe’s Recommendations.
To discuss what Tailpipe can do to measure and reduce your cloud computing spend and emissions, get in touch with us here.
