Sustainable infrastructure begins with deciding what should not run

Efficiency matters, but sustainable infrastructure is ultimately shaped by demand: which workloads exist, how often they run, how much data they retain and what useful result justifies the resources consumed.

A service moves to a more efficient platform.

Its servers use less energy per transaction. Cooling improves. Hardware handles more work per watt. The deployment region is described as low carbon.

Then usage triples.

More environments are created. Data is retained indefinitely. Reports run every hour instead of every day. AI features are added to interactions that previously required a database query. Faster hardware makes it easier to launch workloads that nobody would have approved when compute was scarce.

The system becomes more efficient.

Its total resource demand still rises.

The central test

Infrastructure is sustainable when the organisation can connect energy, hardware, water and carbon impact to useful work—and remove work whose value does not justify its cost.

Efficiency can improve while total demand grows

Efficiency is necessary.

It reduces the resources required for a defined unit of work. Better processors, software, cooling and utilisation can allow the same service to operate with less energy and hardware.

But infrastructure does not consume efficiency.

It consumes electricity, equipment, land, water and network capacity.

The International Energy Agency reported that data-centre electricity demand reached roughly 485 terawatt-hours in 2025 and projects it to approach 950 terawatt-hours by 2030. The same analysis found that electricity use by AI-focused data centres grew much faster than overall data-centre consumption in 2025. (IEA)

The point is not that digital infrastructure is uniquely harmful or should stop growing.

The point is that efficiency improvements do not remove the need to govern demand.

Common mistake

Treating lower energy per server, model or transaction as proof that total impact is falling.

Better framing

Measure both intensity and scale: resource use per useful outcome, multiplied by the number of outcomes the organisation chooses to produce.

A workload that becomes ten times more efficient but runs twenty times more often consumes more in total.

That is not an argument against optimisation.

It is an argument against stopping the analysis there.

Measure the service, not only the facility

Infrastructure sustainability metrics often describe the building or platform.

Power usage effectiveness can show how much facility energy supports computing rather than cooling and other overhead. Hardware utilisation can show whether purchased capacity is active. Grid-carbon data can describe the electricity available at a location and time.

Those measures are useful.

They do not say whether the computing itself is worthwhile.

A better unit connects consumption to the service delivered:

per completed scientific analysis
per verified document processed
per active user served
per successful transaction
per terabyte preserved under an approved retention policy
per model evaluation completed
per restored service

The Software Carbon Intensity specification, standardised as ISO/IEC 21031:2024, uses this idea by expressing emissions per functional unit and including energy, grid carbon intensity and the embodied impact of hardware. (Green Software Foundation)

The choice of functional unit is an architecture decision.

A vague unit can hide growth. “Per API request” is weak when requests vary dramatically in complexity. “Per user” is weak when automated systems create large differences in usage. “Per model query” says little when one request generates a sentence and another launches a long reasoning process with several tools.

The unit should represent something the organisation values.

Otherwise, sustainability becomes an exercise in making the denominator convenient.

Start with a demand hierarchy

Sustainable design should not begin with the question, “Where can we run this more efficiently?”

It should begin earlier.

Avoid unnecessary work
        |
        v
Reduce the work required
        |
        v
Right-size the resources
        |
        v
Shift flexible work in time or location
        |
        v
Extend hardware and data lifecycles
        |
        v
Use lower-impact energy and materials

Each step preserves options for the next.

Avoid asks whether the workload should exist. Duplicate reports, unused environments, abandoned indexes and speculative AI features should not receive permanent infrastructure by default.

Reduce changes the design. Cache results, move filters closer to the data, select smaller models, reduce unnecessary precision and avoid repeatedly processing unchanged information.

Right-size matches capacity to actual demand rather than optimistic forecasts or one rare peak.

Shift moves flexible work to times or locations with lower grid intensity, available capacity or less environmental pressure.

Extend keeps useful hardware and data structures in service rather than replacing them automatically.

Source addresses the electricity and materials used for the remaining demand.

Starting at the bottom leaves the largest decision untouched: how much work the organisation has chosen to create.

Idle capacity is an architecture decision

Infrastructure teams often inherit a contradiction.

Services must absorb peaks, recover from failures and leave room for growth. At the same time, low utilisation wastes energy and hardware.

The answer is not simply to run every system near maximum capacity.

Resilience requires spare capacity. Performance may require headroom. Recovery environments may remain inactive until a failure. Research workloads may arrive in irregular bursts.

The important distinction is between intentional reserve and unexamined idleness.

Intentional reserve has a purpose:

failover capacity for a defined scenario
recovery infrastructure with a tested activation path
performance headroom tied to a service objective
queued compute for known workloads
seasonal capacity with a retirement date

Unexamined idleness has history:

environments nobody owns
resources created by discontinued projects
oversized databases that were never revisited
clusters kept because removal feels risky
replicated datasets whose consumers no longer exist

Sustainable operation requires an inventory of purpose, not merely utilisation.

A server at five per cent utilisation may be justified.

A server at five per cent utilisation with no owner, recovery role or shutdown decision is not reserve. It is forgotten demand.

Data has an environmental lifecycle

Data is often treated as cheap to retain because the marginal storage price is low.

Its infrastructure cost extends beyond the primary copy.

Data may be replicated, backed up, indexed, scanned, transferred, transformed and included in disaster-recovery systems. Metadata services track it. Security tools inspect it. AI systems may create embeddings or derived copies. Every retention decision can propagate across several layers.

The correct question is not “Can we afford to keep it?”

It is:

Which purpose requires this data to remain available, recoverable or readable—and for how long?

Operational storage, backup and archive have different lifecycles.

Live data may need fast access and frequent protection. Backups need historical states and tested expiry. Archives need long-term readability, integrity and authority. Keeping all three indefinitely does not create better stewardship.

It creates uncertainty about which copy matters.

Deletion is therefore part of sustainable infrastructure.

It must be governed, evidenced and connected to legal, research and operational requirements. Uncontrolled deletion destroys value. Refusing to delete anything transfers the decision to future teams while continuing to consume resources.

Good retention preserves what the organisation can justify.

Hardware lifetime belongs in the carbon model

Operational energy is only part of infrastructure impact.

Servers, storage devices, network equipment and cooling systems have embodied emissions from material extraction, manufacturing, transport and construction.

Replacing hardware can reduce electricity use while increasing the impact associated with producing new equipment and retiring the old system.

Research on data-centre sustainability argues for a lifecycle approach that includes construction, hardware sourcing, software efficiency, water, land and end-of-life management. It also warns that premature replacement can undermine the benefit of an efficiency improvement when embodied impacts are ignored. (Nature npj Urban Sustainability)

The correct replacement decision is therefore not:

Is the new hardware more efficient?

It is:

Will the avoided operating impact, over the expected life of the service, justify manufacturing and deploying the replacement?

That calculation will not always be precise.

It can still improve decisions.

Extending hardware life may require accepting lower density, repairing components, maintaining compatible software and separating workloads by performance need. Not every service requires the newest accelerator or storage tier.

Hardware should be replaced because its operating risk or total impact justifies replacement—not because a purchasing cycle has completed.

Location changes impact; it does not erase it

Moving work to a region with lower-carbon electricity can reduce operational emissions.

Location also affects water demand, land use, grid congestion, latency, resilience and legal control.

A data centre can purchase renewable certificates while still drawing physical electricity from a constrained local grid. A cooling design can reduce energy while increasing water use. A rural location can offer land and renewable generation while increasing network dependency. A dense urban location can reduce latency but compete with other uses for electricity and space.

The environmental boundary should match the architectural boundary.

A service that shifts compute elsewhere has not eliminated impact. It has changed where the impact occurs and who experiences it.

This is why procurement claims such as “powered by renewable energy” are too small on their own.

Teams need to understand:

physical and contractual electricity sources
marginal demand during the workload’s operating period
local grid and water constraints
hardware and building lifecycle
network movement
recovery and replication locations
the communities sharing those resources

Sustainability is not a colour assigned to a region.

It is a set of trade-offs that must remain visible.

AI makes the unit of work unstable

AI infrastructure sharpens the demand problem because one interaction can represent radically different amounts of computing.

A short classification, a long reasoning task, a generated video and an agent performing several tool calls may all be counted as one “request”.

The IEA’s 2026 analysis notes that energy use per simple AI task has fallen quickly, while reasoning, video generation and agentic workloads can consume far more electricity per query than basic text generation. It identifies efficiency, rapidly growing use and the arrival of more intensive applications as the forces shaping AI demand. (IEA)

This makes request counts a poor sustainability metric.

AI systems need workload classes.

Class A — deterministic or lightweight local processing
Class B — small-model inference
Class C — large-model generation
Class D — extended reasoning or multimodal generation
Class E — agentic work with repeated model and tool calls

The exact classes will differ by organisation.

The principle is stable: expensive computation should be visible at the decision point.

A team should know when a feature has moved from one class to another, which user outcome justifies it and what cheaper path was considered.

The most sustainable model is not always the smallest model.

It is the smallest complete system that produces an acceptable result.

A practical sustainability review

Area	Weak signal	Stronger evidence
Demand	Resource use is tracked	Workloads have owners, purposes and retirement conditions
Efficiency	Platform efficiency improved	Resource intensity per meaningful service outcome improved
Capacity	Utilisation is low or high	Reserve and headroom are tied to explicit resilience or performance needs
Data	Storage growth is monitored	Retention, replication, backup and archive purposes are separated
Hardware	New equipment is more efficient	Operating savings are assessed against embodied impact and remaining life
Location	A green region is selected	Grid, water, land, latency and resilience trade-offs are recorded
AI	Queries are counted	Workload classes expose reasoning depth, tools, retries and model size
Recovery	Duplicate environments exist	Recovery capacity has a tested purpose and activation path
Evidence	Annual emissions are reported	Architecture teams can connect changes to measurable service-level impact

The review should not punish useful computing.

Digital infrastructure supports research, public services, communication, security and economic activity. Some workloads justify substantial resources.

The discipline is to make that justification explicit.

Sustainability is a quality of operation

Sustainable infrastructure is not a special platform purchased at the end of an architecture process.

It is what emerges when systems have clear purposes, bounded lifecycles, appropriate capacity, controlled data growth and evidence about the work they perform.

Efficient hardware helps.

Cleaner electricity helps.

Better cooling helps.

The largest gain may still come from the job that no longer runs every five minutes, the dataset that no longer has twelve unexplained copies, the model that was replaced by a deterministic rule or the server kept in service because it remains adequate.

Sustainability begins before optimisation.

It begins when an organisation is willing to decide that some technically possible work should not become permanent infrastructure.

One question for the next architecture review

Select the fastest-growing workload in the estate and ask:

What useful outcome is growing with its resource consumption—and what would we stop, simplify or redesign if electricity, hardware and water were treated as governed capacity rather than invisible supply?