Every major cloud provider will tell you they are on track for net zero. Microsoft’s own 2025 sustainability report quietly acknowledged that its carbon emissions have risen 23.4% since 2020.
That’s not a contradiction I’m manufacturing. It’s in their own reporting. And it’s exactly the kind of detail that matters when you’re a technology leader being asked by your board whether your cloud operations are sustainable.
I’ve been working with cloud infrastructure in regulated industries for over two decades. What I’ve observed over the last two years is a growing gap between what cloud providers communicate about sustainability and what the data actually shows. That gap has real consequences — for your organisation’s reporting obligations, your understanding of your actual environmental footprint, and your ability to make informed decisions about where and how you run your workloads.
The Energy Demand Problem
The International Energy Agency published its Energy and AI report in 2025. The numbers are stark. Global data centre electricity consumption reached approximately 415 TWh in 2024. By 2030, the IEA projects that figure will nearly double to around 945 TWh — growing at roughly four times the rate of the rest of the global economy.
The driver is AI. Compute-intensive AI workloads are reshaping the energy profile of cloud infrastructure faster than most people anticipated, and the scale of that shift is only beginning to be visible in the numbers. In the UK specifically, data centres already consume around 2.5% of national electricity supply, with approximately 450 data centres and 1.6 GW of installed capacity. DSIT’s Compute Roadmap, published in August 2025, forecasts the UK will need at least 6 GW of AI-capable data centre capacity by 2030 — nearly four times what exists today.
This isn’t an argument against cloud, and it isn’t an argument against AI. But it is a reason to understand what your cloud provider’s sustainability claims are actually telling you — and, more importantly, what they’re not.
What “100% Renewable” Actually Means
Here’s where it gets complicated.
AWS announced in 2023 that it had matched 100% of its global electricity consumption with renewable energy — seven years ahead of its original 2030 target. A remarkable headline. Except that, in Amazon’s own CDP disclosure for the same year, 68% of those renewable energy certificates were unbundled RECs.
An unbundled REC — or a REGO in the UK context — is a certificate that represents the right to claim that a unit of renewable energy was generated somewhere, by someone, at some point in the recent past. You’re not necessarily paying for new renewable capacity to be built. You’re not necessarily connected to the grid at the same time as the renewable generation. In some cases, organisations are buying certificates from projects that have been operational for a decade. Amazon employees publicly challenged this framing in 2024, stating the company was “distorting the truth” about its renewable energy progress. The concern at the heart of that challenge is one of additionality — does the purchase actually result in less carbon in the atmosphere, or does it simply shift paper ownership of renewable attributes around?
Compare that to Google’s approach. Google reports against a 24/7 Carbon-Free Energy (CFE) score, which matches actual clean energy generation to actual electricity consumption on an hourly basis by grid region. Their 2024 score was 66% — which looks lower than Amazon’s 100%, but is arguably far more honest. Nine of Google’s 20 owned data centre grid regions reached at least 80% CFE. Microsoft, meanwhile, contracted 19 GW of new renewable power across 16 countries in 2024 through long-term Power Purchase Agreements, which — unlike unbundled RECs — do carry meaningful additionality.
I’m not making a blanket judgement about any provider’s sustainability intentions. What I am saying is that when you receive a carbon report from your cloud provider, the methodology behind the numbers matters enormously. As a technology leader, knowing the difference between an unbundled REC and a Power Purchase Agreement is now part of your job.
FinOps Meets GreenOps: The Practical Opportunity
Here’s what I’ve found more encouraging about the current state of cloud sustainability. For organisations already running FinOps programmes — and many are — the path to understanding your cloud carbon footprint is shorter than you might think.
Cloud cost is a close proxy for energy consumption. The compute you’re not running isn’t consuming energy. The storage you’ve rightsized isn’t drawing power. The idle resources you’ve cleaned up aren’t sitting in a data centre somewhere, generating heat that needs to be cooled.
This alignment has given rise to what the industry is calling GreenOps — the practice of applying FinOps discipline to carbon metrics alongside cost metrics. The FinOps Foundation added Sustainability as a formal capability in the FinOps Framework in 2024. Organisations including HSBC and Nubank presented on cloud sustainability at FinOps X 2024. This isn’t theoretical anymore.
The tooling has improved meaningfully. AWS Customer Carbon Footprint Tool now supports both location-based and market-based emissions methodologies and includes coverage of Scope 3 emissions from hardware manufacturing. GCP Carbon Footprint provides emissions breakdowns by project, region, and product, with data exportable to BigQuery for deeper analysis. Azure’s Emissions Impact Dashboard covers Scope 1, 2, and 3 emissions for Azure usage, with data retained for two years. None of these tools are perfect — I’d encourage anyone implementing them to read the independent analysis from Carbone4 and Scott Logic before deciding how much weight to put on the numbers — but the direction of travel is positive.
What strikes me is how closely this mirrors the maturity curve we saw with FinOps itself. Five years ago, most organisations had no systematic view of their cloud spend. Today, most serious cloud programmes have a FinOps function or equivalent. Carbon measurement is at a similar inflection point. The organisations getting ahead of it now will be significantly better positioned when reporting obligations tighten — which they will.
The Reporting Reality
If your organisation meets the CSRD thresholds — and following the December 2025 Omnibus revision, that’s companies with 1,000+ employees and €450M+ turnover — cloud computing emissions are likely to be a material Scope 3 category. The first wave of CSRD reporters published their first compliant reports in 2025, covering fiscal year 2024. Wave 2 has been pushed out to 2028 under the Omnibus changes, which gives some organisations more runway. But the material assessment work, the data collection infrastructure, and the internal processes need to be built well before the first report is due.
In the UK, we’re not subject to CSRD post-Brexit, but UK organisations with EU operations or subsidiaries meeting CSRD thresholds face dual reporting obligations. The UK Sustainability Reporting Standards, based on ISSB S1 and S2, are expected to become mandatory for listed companies from FY2026/27. Scope 3 has a phased approach — years one and two focus on Scope 1 and 2, with Scope 3 required from year three onwards.
One tension worth flagging explicitly for technology leaders involved in sustainability reporting: CSRD requires location-based electricity emissions calculations, while cloud providers typically lead with market-based figures that reflect their renewable certificate purchases. Using a provider’s market-based figure can materially understate actual grid emissions in a CSRD-compliant report. This is a conversation that technology leaders need to be having with their sustainability and finance colleagues now, before reporting obligations crystallise and the numbers are locked in.
Measuring the Right Things
On the Clipper Race, you monitor your instruments constantly. Speed, heading, trim, sail shape — the data comes at you continuously and you make adjustments based on what it tells you. But one of the first things you learn is that an instrument calibrated to the wrong datum gives you confident, precise, completely wrong information. You can spend hours optimising for a number that doesn’t reflect reality, feeling like you’re making progress, while the waypoint gets no closer.
That’s where some organisations are with cloud sustainability today. They’re receiving dashboards and reports that look authoritative, without fully understanding the methodology behind them. They’re measuring something — but not necessarily the right thing.
The organisations I’ve seen making genuine progress on this are the ones that have approached cloud sustainability with the same sceptical discipline they’d apply to any other metric. They’ve asked their cloud providers to explain the methodology. They’ve distinguished between market-based and location-based Scope 2 figures. They’ve started mapping cloud spend to carbon estimates using their existing FinOps data, and they’ve built in a process for reviewing that data over time as the tooling matures. They haven’t waited for perfect measurement — they’ve started with a good-enough baseline and improved from there.
That’s not a simple undertaking, and I won’t pretend it is. The tooling is still maturing. The regulatory landscape is still evolving. The difference between an unbundled REC and a 24/7 Power Purchase Agreement is not yet common knowledge in most boardrooms. But the regulatory and reputational reasons to start are only becoming more pressing — and the organisations that build this capability now, rather than scrambling to meet a reporting deadline, will be in a much stronger position.
The question I’d invite you to sit with is this: if your board asked you today to explain your organisation’s cloud carbon footprint — methodology and all — what would you say?
Leave a Reply