Cloud Emissions: The Ultimate Guide to the Carbon Footprint of the Cloud in 2025

Cloud Services and Carbon Emissions: Understanding the Hidden Footprint

Every email we send, photo we upload, or app feature we deploy to “the cloud” triggers activity in physical data centers – and those activities have a carbon footprint. Cloud computing’s emissions are often less visible than, say, a factory’s smokestack or a car’s exhaust, but they are far from negligible.

In fact, the global digital sector (including data centers, networks, and user devices) is estimated to account for 3–4% of worldwide greenhouse gas (GHG). Data centers alone consume roughly 2% of the world’s electricity – about as much as some entire countries – and their energy use doubled between 2015 and 2022. As cloud adoption surges (about 75% of IT workloads ran on cloud infrastructure in 2023), the emissions tied to cloud services are an increasingly important piece of the climate puzzle.

What makes cloud emissions especially critical is that they’re largely “hidden” from the end user. When your company uses Amazon Web Services (AWS), Google Cloud, or Microsoft Azure, you don’t see a gas meter or an electricity bill for the servers powering your workloads. The hardware is out-of-sight, often thousands of miles away, so it’s easy to forget about the environmental impact. However, those data centers draw enormous amounts of power (often from fossil-fueled grids) and require energy-intensive manufacturing of equipment. They may be “virtual” services, but their climate impact is tangible.

What Are Cloud Emissions? (Sources Across the Lifecycle)

When we talk about “cloud emissions,” we mean all the greenhouse gases released throughout the lifecycle of cloud computing services.

This spans a wide range of sources – from the moment a data center is constructed and filled with hardware, through every watt of electricity consumed in operation, all the way to the end-of-life disposal of equipment. These sources are commonly broken into Scopes 1, 2, and 3 as defined by the GHG Protocol (read more about this here).

Scope 1 (Direct emissions)

For cloud providers, scope 1 includes on-site fuel use and any direct greenhouse gas releases. The prime example is diesel generators at data centers. Data centers have backup generators (often diesel-powered) that run during power outages or for periodic testing – releasing CO₂ and other pollutants.

Another Scope 1 source is fugitive emissions from cooling systems. Data centers use refrigerants in their HVAC and server cooling infrastructure; as these gases leak, they can have a high global warming potential.

Scope 2 (Energy usage emissions)

This is typically the largest operational component of cloud emissions. Scope 2 covers the electricity consumed by data centers – to power the servers, storage drives, networking gear, and all the supporting systems like cooling, lighting, and security. Data centers are essentially massive warehouses of computers, and those computers run 24/7, drawing power from the grid. If that grid’s electricity comes from fossil fuels, the carbon emissions can be significant.

Even with modern efficient data centers, the sheer scale of cloud activity means a big electricity demand. It’s also important to note where that energy comes from: a data center in a region with a coal-heavy grid will be responsible for more CO₂ per kWh than one in a region with hydro, nuclear, or wind power.

Scope 3 (Indirect value-chain emissions)

These are all the other emissions “indirectly” caused by the cloud service, often outside the data center itself or upstream in the supply chain. Scope 3 is typically the largest share of a cloud provider’s total carbon footprint – as is the case in most industries – because it includes the embodied emissions of manufacturing and other activities not captured above. For cloud services, key Scope 3 sources include:

• Manufacturing of IT hardware: Every server, storage device, rack, and networking switch in a cloud data center had to be manufactured from raw materials. The process of mining and refining metals, producing semiconductor chips, assembling circuit boards, etc., is extremely energy- and carbon-intensive.
• Construction of data center buildings: The data center facility itself has an embodied carbon footprint. The steel, concrete and construction processes for these massive, reinforced buildings produce emissions.
• Upstream fuel and energy production: Another often-overlooked indirect source is the emissions from extracting and transporting the fuels that generate electricity, as well as losses in the transmission grid. Even if the electricity use is counted in Scope 2, the additional footprint of fuel production and grid infrastructure can be counted in Scope 3.
• Logistics and supply chain operations: This can include shipping servers and parts around the world, warehouse storage, etc. These are minor compared to manufacturing, but part of the value-chain emissions.
• Employee commuting and travel: The people who keep data centers running also contribute a bit – driving to the facility, business travel for operations.
• End-of-life disposal: What happens to old servers? If not recycled properly, the decomposition or incineration of e-waste can release emissions.

In summary, Scope 3 covers the embodied emissions (from making and assembling all that tech), plus various other upstream impacts needed to deliver cloud services. Multiple analyses have shown that for tech companies, these supply chain emissions dominate the carbon footprint. For instance, the surge in cloud AI infrastructure in 2023 caused double-digit percentage increases in the carbon footprints of companies like Google and Microsoft – largely driven by manufacturing of new servers and equipment (a Scope 3 source).

From Black Box to Transparency: Measuring and Tracking Cloud Emissions

For years, outsourcing to the cloud meant losing direct visibility of your IT emissions. Companies knew that their cloud usage had a carbon footprint, but quantifying it was difficult. If you wanted to report “how much CO₂ was emitted due to our use of AWS this year” you were largely in the dark.

Many organizations resorted to crude estimates – for example, using industry averages (like so many kg CO₂ per hour of server usage) or third-party models – which were inexact and couldn’t account for the provider’s specific efficiency or energy sourcing. Cloud providers themselves, meanwhile, would publish company-wide sustainability reports, but not customer-specific data.

This opacity has changed dramatically in the last few years. Regulators and customers have pushed for more transparency, and the big three cloud providers have responded by launching tools to report cloud emissions to their users.

Today, AWS, Google Cloud, and Azure each offer dashboards or reports that let you measure the carbon emissions associated with your cloud workloads, often broken down by service and region. These tools aren’t perfect or identical (as we’ll see), but they represent a major step forward from the “black box” era.

Here’s a quick summary of the main tools available from each provider:

• Amazon Web Services released its Customer Carbon Footprint Tool in 2022, giving AWS users a way to see estimated emissions from their cloud usage. It’s available in the AWS Billing console to all customers.
• Google was one of the pioneers in providing customers with a view of their cloud emissions. The Google Cloud Carbon Footprint dashboard was introduced in 2021, and it has set a high bar in terms of detail and transparency.
• Microsoft’s Azure cloud has offered carbon tracking for its customers also since about 2021. Azure’s primary offering in this space has been the Emissions Impact Dashboard (EID), which is a solution built on Power BI to visualize Azure usage emissions. Microsoft has continued to evolve its tools, adding Azure Emissions Insights (for more advanced analytics via Microsoft Fabric) and a preview of Azure Carbon Optimization (targeted at developers/IT for actionable insights).

Comparing the Cloud Emissions Tools (AWS vs. GCP vs. Azure

So how do they stack up? Overall, our view is that AWS is currently a clear last place, based on the lack of granular, timely data – especially for Scope 3. Google and Azure are fairly comparable, but we’d pick Google because of the way they treat Scope 2 emissions – essentially providing better, fairer data around the impact of their data centre electricity usage.

Below we compare each tool across key areas, to help you decide which one to go for if emissions data is key.

Scope 3 Coverage: Google and Azure win

This is perhaps the biggest differentiator. Google Cloud and Microsoft Azure both include Scope 3 (supply chain) emissions in their customer emissions reports by default) and have done so for a few years. This means they allocate things like hardware manufacturing, data center construction, etc., into your footprint.

AWS, on the other hand, did not include Scope 3 until at least 2024, and as of mid-2025 it appears those numbers are still not visible in the AWS tool. AWS has acknowledged this lag and promised updates.

The absence of Scope 3 can be huge – leaving out manufacturing and other upstream emissions can make the reported emissions artificially low. In fact, AWS’s and Oracle’s cloud calculators can provide “near-zero” emissions results due to omitting Scope 3 entirely (and using 100% renewable electricity accounting), which probably crosses the line into greenwash territory. So, if you see a big difference like “Google says our usage emits 100 tons, but AWS says only 10 tons,” the likely reason is the Scope 3 gap, not that AWS is magically cleaner.

Bottom line: Google and Azure currently offer more complete carbon accounting of your cloud usage than AWS in terms of included sources. Companies that need to comply with comprehensive reporting (e.g., CSRD) will find Google/Azure’s data much closer to what regulators expect (all material sources included).

Electricity Emission Accounting (Scope 2): Google wins

A quick aside: when accounting for any Scope 2 emissions – including the electricity used to power data centres – there are two methods:

• Location-based. Emissions are based on the electricity that directly powers the data centre (usually the local grid, unless the data centre has its own solar panels).
• Market-based. Emissions take energy tariffs into account (so if the data centre has a 100% renewable energy tariff, emissions will be 0).

In general, it’s great to have both methods, but priority should be given to the location-based method because this is a truer reflection of the emissions actually generated as a result of the electricity usage. The market-based method is vulnerable to accusations of greenwashing – the robustness of 100% renewable tariffs varies significantly. You can read more about the distinction here.

All three providers source a lot of renewable energy and provide market-based reporting which takes this into account – but their coverage of the location-based method varies.

AWS and Azure historically focused on market-based results – meaning if they covered your usage with renewable energy certificates or power purchase agreements, they report little or no emissions from electricity. Google provides both market-based and location-based figures out-of-the-box, giving a more nuanced view. AWS has recently added a location-based option in its console, and Azure’s methodology could theoretically be used to derive location-based numbers, but they aren’t front and center in the default dashboard.

The practical impact: if you want to optimize by moving workloads to cleaner regions or times, Google’s tool is the most straightforward, since it directly shows the difference (and even uses hourly grid data). With AWS/Azure, you might have to deduce it.

For compliance, note that some regulations require location-based reporting, so having those figures is important. Google’s and now AWS’s inclusion of location-based data is a plus, whereas Azure users might need to request that data or calculate it from grid info if not provided in the UI.

Data Timeliness: Google and Azure win

If you want up-to-date info, Google and Azure update monthly (with weeks of lag, not months). AWS updates only quarterly (monthly with 3-month lag) as of now. This means Google/Azure can be used to track progress more closely – for example, if you undertake a cloud efficiency initiative in Q1, you’ll see the impact by Q2. With AWS, you might not confirm the impact until half a year later. Azure’s new Carbon Optimization tool even leans toward more continuous data (rolling 12 months) to encourage immediate action.

Granularity and Actionability: Google and Azure win

Google’s breakdown by project, service, region and integration of recommendations makes it quite actionable – you can pinpoint what to improve.

Azure’s breakdown by subscription, resource group, service is also very useful, and their focus on top emitters and recommendations in Carbon Optimization is geared to action.

AWS’s tool is currently the least granular – with only broad service categories and broader time lag, it’s more about reporting a total than helping drill down into, say, which application is causing an emissions spike. If you have a multi-cloud environment or are looking to compare, you might find Google and Azure give you more to work with in terms of diagnosing emissions drivers.

Transparency and Methodology: Google wins

All providers have published some methodology info. Google’s and Microsoft’s are fairly detailed (Google’s especially, describing allocations and sources). AWS provided a methodology document as well, but notably had to revise it as they update their model (they were on “Methodology 2.0” as of 2022).

An important transparency point is whether the data is third-party verified. Typically, these customer tools themselves are not fully audited, though they derive from the companies’ corporate inventories which often undergo assurance. Still, the level of detail shared by Google (listing exactly what’s included vs excluded)cloud.google.com and Microsoft (white paper, etc.) tends to be higher than what AWS shared historically (AWS was more of a high-level summary). This matters if you’re an SME that wants to explain or defend the numbers in your own reporting – being able to cite the provider’s documentation that “yes, these figures include X, Y, Z categories”cloud.google.com is helpful.

If the provider omits something, you may need to estimate that yourself. For example, if using AWS today, you might take AWS’s reported footprint and add an additional factor for hardware manufacturing emissions based on industry averages, to be safe, because AWS’s tool doesn’t yet show hardware (Scope 3) emissions. Some third parties and non-profits (like Cloud Carbon Footprint and others) have created open models to estimate cloud emissions for this reason.

In short, Google Cloud’s tool currently leads in completeness and transparency, Azure’s tools are strong and particularly enterprise-focused (with new improvements for accessibility), and AWS’s tool – while improving – still lags in some key areas like Scope 3 inclusion and data immediacy.

All three, however, signify a positive trend: cloud customers are no longer flying blind when it comes to carbon footprint. You can get data (mostly for free) from your providers to plug into your own carbon accounting.

Conclusion: Managing Your Cloud Carbon Footprint

In conclusion, cloud services have a carbon footprint that is too large and significant to remain invisible. They may be out of sight, but they shouldn’t be out of mind for any organization committed to sustainability. By understanding what cloud emissions are – across the full lifecycle – and by leveraging the new generation of cloud emission reports, businesses can illuminate this “hidden” part of their footprint.