Sustainability reporting used to be a finance and facilities exercise. It now reaches engineering, because cloud usage is a material part of many organisations' reported footprint and the numbers have to come from somewhere. Engineers asked to produce them discover quickly that cloud provider emissions dashboards are less precise than they appear, and that the honest answer involves more caveats than a reporting template usually allows. This is the practical side of sustainable and green IT.
01Know which scope your cloud usage lands in
Emissions reporting divides into scopes, and cloud services generally fall into the third, covering indirect emissions in the value chain. That scope is the least precise by nature, because it depends on data held by suppliers who each measure and disclose differently.
This matters because expectations differ by scope. Scope three figures are understood by assurance providers to be estimates, and what is assessed is the soundness of the methodology rather than the precision of the number. Engineers who assume they must produce an exact figure usually over-engineer the collection and under-document the method, which is the wrong way round.
02Provider dashboards are modelled, not measured
The major clouds all publish carbon reporting tools, and they are the reasonable starting point. What they report is derived from your resource consumption combined with regional grid intensity and the provider's own efficiency and procurement assumptions. Very little of it is a direct measurement of your workload.
The consequences are practical. The figures are often delayed by weeks, they change retroactively as providers revise methodology, granularity is limited so attributing emissions to a specific service or team is approximate, and numbers from different providers are not directly comparable because the methodologies differ.
| Question | Why it matters for reporting |
|---|---|
| Market-based or location-based? | Renewable contracts change the figure substantially |
| What reporting lag applies? | Period close may precede data availability |
| Is it restated retroactively? | Prior year comparatives can move |
| What granularity is available? | Determines whether team attribution is possible |
| Which services are excluded? | Coverage gaps need disclosing |
03Market-based and location-based tell different stories
Two legitimate accounting approaches exist and they can produce very different results. Location-based reflects the average intensity of the grid a data centre draws from. Market-based reflects the energy the provider contractually purchased, including renewable instruments.
A provider with substantial renewable procurement will show a far lower market-based figure than location-based. Neither is dishonest, and reporting frameworks generally expect both to be disclosed. What is not acceptable is choosing whichever is lower each year without saying which basis was used, and that is an easy trap when the dashboard defaults change.
04Region choice dominates efficiency work
Engineering instinct is to optimise the workload. For emissions specifically, where the workload runs usually matters more than how efficiently it is written, because grid intensity varies by a large factor across regions while achievable efficiency gains are typically incremental.
That makes region selection the highest-leverage decision available, subject to the constraints that actually bind: data residency, latency to users, service availability and cost. Where those constraints permit a choice, running batch and non-latency-sensitive work in a low-intensity region is the single most effective action most teams can take.
- Check grid intensity per region before placing new workloads, not after.
- Move batch, training and analytics work first; they rarely have latency constraints.
- Weigh residency and latency requirements honestly, they often remove the option.
- Shifting workload timing helps where grid intensity varies through the day.
- Decommissioning unused resources beats optimising resources nobody needed.
05Idle capacity is the easiest genuine reduction
Before any sophisticated optimisation, most estates contain substantial unused capacity: non-production environments running continuously, oversized instances provisioned for a peak that never materialised, orphaned volumes, and forgotten resources in accounts nobody reviews.
This work has the unusual property of reducing both emissions and cost, which makes it straightforward to justify without invoking sustainability at all. It is also the most defensible thing to report, because a decommissioned resource is a real reduction rather than a modelling change.
- Shut non-production environments outside working hours as a default policy.
- Right-size against observed utilisation rather than the original provisioning request.
- Sweep for unattached storage, idle load balancers and forgotten accounts.
- Set retention on logs and backups; indefinite retention accumulates quietly.
- Report reductions from decommissioning separately from methodology changes.
06Build the collection to be audited
Sustainability figures increasingly attract assurance, which means the same expectations that apply to financial data begin to apply here: the number must be reproducible, the method documented, and the judgements recorded.
Practically, that means storing the raw provider exports rather than only the summary, recording the methodology version in force for each period, keeping the calculations in version control rather than a spreadsheet on someone's machine, and writing down every estimate and exclusion at the time the decision is made. A figure nobody can reproduce twelve months later is a finding waiting to happen.
Topics
Aarav Patel
Principal Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.