Section 1
The three levels of action.
Most organisations that describe themselves as having a sustainability programme are, on closer inspection, running a reporting function. That is a starting point. It is not a destination.
Reporting
Tells you what happened. The rear-view mirror. Necessary for disclosure, compliance, and baselines. Not sufficient for improvement on its own. Most organisations are here and do not always know it.
→ If this is all you have, you have a communications function.
Optimisation
Doing the same thing with less. Rightsizing, improving utilisation, extending device lifespans. Where most immediate wins are found, but it does not guarantee absolute reduction.
→ A business growing 20% while improving 10% is still growing its footprint.
Avoidance
Designing demand out before it exists. Consolidating duplicate platforms, retiring unused applications, designing for less compute. The highest-leverage decisions live here.
→ Shift-left in practice. Requires earlier intervention than most governance allows.
Section 2
Three layers, three conversations.
Infrastructure is not one thing. Treating it as a single domain masks where efficiency gains are available and where they are not. The three-layer separation is the framework that makes infrastructure conversations precise.
Facility
The building, cooling, power distribution, and physical security. Measured by PUE, WUE, CUE. Owned by data centre operations or the colocation provider. Most organisations do not control this layer directly, but they choose who does.
Key metric: PUE tells you how much overhead the facility adds. A PUE of 1.4 means 40% of total power is consumed by cooling and distribution, not by IT.
IT load
Servers, storage, networking equipment. The compute that does the work. Measured by utilisation, idle percentage, provisioned versus actual. Owned by platform, infrastructure, and cloud teams. This is where rightsizing and consolidation operate.
Key metric: utilisation. A server running at 12% average utilisation is consuming power to do almost nothing. Multiply that across thousands and the waste is structural.
Service
The application, the workload, the business function that justifies the infrastructure. Measured by carbon per transaction, per API call, per user session. Owned by application teams and product owners. This is where demand management and avoidance live.
Key metric: service intensity. Connects infrastructure consumption to business value. Without it, efficiency is measured in the abstract.
Why the separation matters
A facility can have an excellent PUE while running servers at 10% utilisation. A platform team can achieve high utilisation while hosting applications that nobody uses. Each layer can look efficient in isolation while the system as a whole wastes resources. The three-layer view forces you to ask whether efficiency at one layer is being undermined by waste at another.
PUE is not the whole story
PUE measures facility overhead relative to IT load. It says nothing about whether the IT load itself is useful, well-utilised, or necessary. A data centre with a PUE of 1.1 running servers at 8% utilisation is efficient at delivering waste. Water usage (WUE) and carbon usage (CUE) add important dimensions, but even together they describe the facility, not the value of what runs inside it.
Resilience as a waste driver
Most infrastructure is provisioned for peak demand plus a resilience margin. That margin is rarely questioned and almost never right-sized after initial deployment. The result: permanent over-provisioning justified by a resilience requirement that was set once and never revisited. Mature programmes treat resilience levels as a periodic governance decision, not a one-time architectural default.
Section 3
The rebound effect.
The pattern that separates mature GreenOps programmes from immature ones. The pattern: optimise, free up capacity, allocate to new demand, net footprint stays flat or rises.
Rebound effect: unit intensity improves, total emissions stay flat (hover to animate)
Unit metrics: the operational instrument
Carbon per transaction, per VM-hour, per API call. Shows whether the programme delivers operational discipline, not just demand-driven reduction. Can improve even as the business grows.
Total emissions: the rear-view mirror
What the physical world responds to. Required for CSRD, TCFD, and SBTi. Can rise even as efficiency improves, if demand grows faster. Must be explained honestly, not hidden, when it rises.
The fix: explicit governance of freed capacity
This is not a moral failure. It is a governance failure. Mature programmes treat freed capacity as requiring an explicit decision before reallocation, not as automatic resource to be reused. That single governance step separates Level 2 from Level 3 maturity.
Section 4
Carbon-aware computing.
Changing when and where computation runs, not just reducing the amount. The carbon cost of the same computation varies substantially depending on grid conditions at the moment it executes.
Temporal shifting: live: best windows for flexible workloads in GB right now
Loading NESO forecast...
This is temporal shifting in practice. The forecast above shows which hours today have lower carbon intensity. A batch pipeline, an ML training run, or a data sync scheduled for the green window rather than the peak window delivers a measurably different carbon outcome, using exactly the same infrastructure, code, and compute.
Section 5
Water, cooling, and the metrics that PUE misses.
Data centres consume water. The cooling systems that keep servers within operating temperature use evaporative processes that draw on local water supplies. In water-stressed regions, this is not an abstract concern. It is a resource constraint with planning, regulatory, and reputational implications.
Power Usage Effectiveness
Total facility power divided by IT equipment power. The most established data centre metric. Useful for facility-level efficiency comparison. Does not capture water, carbon source, or IT utilisation.
Water Usage Effectiveness
Annual water usage divided by IT equipment energy. Measured in litres per kWh. Varies with cooling technology: air-cooled systems use far less water than evaporative ones. Seasonal variation is significant and should be reported, not averaged away.
Carbon Usage Effectiveness
Total carbon emissions from energy divided by IT equipment energy. Captures the carbon intensity of the energy supply. Two facilities with identical PUE can have very different CUE depending on grid carbon intensity and renewable sourcing.
Site-level, not portfolio averages
A hyperscale provider reporting a portfolio-average PUE of 1.1 may be averaging a highly efficient Nordic facility with a less efficient facility in a warmer, water-stressed region. The portfolio number tells you nothing about the specific site where your workload runs. Always request site-level metrics where available. If they are not available, note that as a data quality limitation.
Knowledge Check · Module 5 · Q1
An organisation completes a cloud rightsizing exercise, reducing idle compute by 35%. Six months later, total emissions are unchanged. What is the most likely explanation?
Select an answer to reveal the explanation.
✓ Correct: Option C
The rightsizing exercise was technically successful. The efficiency gains were real, but efficiency without demand management does not guarantee absolute reduction. Freed capacity is almost always reabsorbed unless there is an explicit governance step that treats it as a deliberate decision rather than automatic resource to be reused.
This is the rebound effect: the pattern that explains why organisations can improve all their unit metrics while total emissions stay flat or rise. The fix is not better rightsizing. It is treating freed capacity as requiring an explicit decision before reallocation.
Knowledge Check · Module 5 · Q2
A cloud engineer wants to use carbon-aware scheduling to reduce the footprint of a machine learning training pipeline. What should they verify first?
Select an answer to reveal the explanation.
✓ Correct: Option B
The precondition for temporal or spatial carbon-aware scheduling is genuine workload flexibility. A training pipeline is often a strong candidate. It typically runs in the background with no user-facing latency requirement. But some pipelines have dependencies: they feed downstream services, trigger deployment workflows, or have regulatory time constraints.
Option A misunderstands how this works: it requires workload assessment, not committee approval. Option C is not a prerequisite; scheduling can be done through open-source tools including the Carbon Aware SDK.
⏸ Pause & Reflect
Take 5–10 minutes. Specificity matters more than completeness.
Module 5: Key Takeaways
Optimisation and avoidance are where operational value lives, and they require different governance to activate.
Freed capacity must be subject to an explicit decision before reallocation. Without active demand management, efficiency gains are absorbed rather than accumulated.
Quantify your flexible load first. It is almost always smaller than hoped and larger than zero.
The goal is not to always win on carbon. It is to make the trade-off with cost and performance visible and deliberate.
The most efficient model shares the same tooling, attribution model, and governance cadence.
Infrastructure sets the physical context. But the decisions that determine how much infrastructure you need are made further up the stack: in the software, in the architecture, in the product scope. Module 6 picks up where infrastructure leaves off. It looks at software engineering as a sustainability lever: the application portfolio, the code patterns, the demand that software creates for everything underneath it.