If a business wants to understand the carbon cost of its public cloud use, it should be able to ask a straightforward question – what emissions did our activity generate?
The answer is rarely straightforward. It depends what the provider measures, how emissions are divided between customers, which electricity accounting method is used and what sits outside the calculation. Establishing whether those emissions have fallen introduces another layer of complexity. Deciding what can credibly be offset depends on understanding both.
In my view, the fundamental difficulty is the distance between responsibility and visibility. Businesses are expected to account for the environmental impact of services they buy, while much of the evidence needed to do so sits with someone else.
Public cloud customers purchase access to computing resources. They do not own the infrastructure, directly measure its electricity consumption or control how it is replaced. They rely on their provider to translate a complex physical operation into a figure they can use.
That figure can be valuable. But we need to understand what it represents before building environmental claims around it.
Shared infrastructure and reporting gaps
Shared infrastructure is the first challenge. A server can support multiple customers, with storage, networking, cooling and other services shared across an even wider estate. Emissions therefore have to be allocated. Detailed methods can use measured energy consumption, resource reservations and hourly usage, but the customer’s footprint remains an attributed share of a larger system. It is not a direct reading from a meter attached to their business.
Allocation is unavoidable. The important questions are whether the method is transparent, whether it reflects the resources consumed and whether it is consistent enough to support meaningful comparisons.
Reporting frequency creates a further gap. A monthly total may help a sustainability team complete its reporting, without helping an IT team establish which decision changed its emissions. It can conceal variation between workloads and between different times of day, even where the underlying calculation uses more detailed data. Monthly customer reporting already exists, but a reporting total and an operational decision tool serve different purposes.
This matters because measurement should help businesses act. If we cannot connect the number to decisions about capacity, storage or processing, its usefulness is limited.
Scopes, grids and moving baselines
There is also the question of whose emissions we are counting. Electricity purchased to operate a cloud provider’s data centre generally falls within the provider’s Scope 2. For the customer buying the service, the associated emissions generally sit within Scope 3, as part of its supply chain. Moving infrastructure into the cloud can therefore change where emissions appear in a customer’s inventory. That change does not, by itself, establish that fewer emissions have occurred.
I think this is an important test for any migration claim. Has the environmental impact reduced, or has it moved outside the part of the organisation’s footprint that receives the most attention?
Electricity accounting adds another complication. Location-based figures reflect the electricity mix of the grid that serves a facility. Market-based figures reflect qualifying contractual arrangements for electricity purchases. A renewable electricity claim based on annual matching does not establish that every workload was powered by carbon-free electricity at every hour. Buyers need to understand which basis supports the figure they are being given.
Without that explanation, two figures can look comparable while answering different questions. A customer may also struggle to distinguish a reduction that results from lower consumption from one that results from changes in electricity purchasing.
Then we come to the baseline. To claim a reduction, an organisation needs a credible starting point and a consistent basis for comparison.
Cloud carbon calculations evolve as providers improve their data and methodologies. Those improvements can lead to historical figures being revised. That is a reason to maintain clear records of the calculation method, rather than assume that a dashboard total is permanently settled. Otherwise, businesses risk treating a change in measurement as a change in performance.
The activity being measured also needs to be comparable. If emissions fall because a business processes fewer transactions, that is different from delivering the same service more efficiently. Conversely, emissions per transaction may improve while total emissions increase as demand grows. Reporting absolute emissions and an appropriate measure of intensity would make these distinctions clearer. The Software Carbon Intensity specification offers a useful approach to relate operational and embodied emissions to a defined unit of activity.
Hardware lifecycles and AI hardware
Customers also have limited control over where and when emissions occur. Region selection can influence a workload’s footprint, but choices must accommodate requirements such as latency, resilience and data residency. Electricity carbon intensity varies geographically and over time – a regional average cannot explain every individual operating decision.
It is reasonable to expect customers to make informed choices. It is equally reasonable to expect providers to explain what customers can influence and what remains beyond their control.
My IT lifecycle perspective adds one further question: does the calculation adequately account for the equipment itself? Manufacturing and end-of-life emissions form part of a hardware footprint, and allocating them to a service requires assumptions about equipment lifespan and use. Some cloud methodologies include embodied emissions, so it would be wrong to suggest these are universally ignored. The issue is whether their coverage and assumptions are clear to the buyer.
AI infrastructure makes that scrutiny particularly relevant. More efficient accelerators can improve performance per unit of energy, but a sound assessment also considers manufacturing and the consequences of replacement. Customers need enough information to understand whether an apparent improvement covers the whole service lifecycle or only its electricity consumption.
The limits of offsetting
What does all this mean for offsetting?
An organisation can purchase credits against an estimated footprint. Uncertainty does not make that transaction impossible. It does, however, affect how confidently the organisation can claim that it has compensated for its emissions. Missing sources, unclear boundaries or revised calculations can change the quantity it is trying to address.
And measuring that quantity is only one part of the task. The credibility of the credits requires separate scrutiny. Purchasing them does not demonstrate that the cloud service itself has reduced its emissions. Offsets should be reported separately from the emissions inventory.
I would, therefore, put better measurement and practical reduction ahead of the claim. Buyers should ask providers to explain coverage, allocation methods, electricity accounting and methodology changes. Procurement, IT and sustainability teams should agree what evidence they need before committing to a public statement.
We should not wait for perfect data before removing unused resources or questioning unnecessary consumption. But we should be honest about the limits of the evidence.
Public cloud carbon is difficult to measure because infrastructure, information and control are shared unevenly between supplier and customer. The answer is greater transparency across that relationship. Until buyers can explain what their number includes, how it was calculated and why it changed, any claim about reducing or offsetting it needs to reflect that uncertainty.
