Where Digital Systems Waste Energy and Resources

An SME does not need a detailed model of the global cloud industry to investigate waste in its own systems. It does need a clear boundary around the work it wants to improve.

Choose a service with an identifiable purpose: processing orders, publishing a catalogue, generating reports or supporting customer enquiries. Establish what a completed useful task looks like. Then identify the parts of the system involved in delivering it.

This prevents an apparently efficient component from obscuring the work happening elsewhere. A faster page may trigger more background requests. A smaller database may depend on repeated transfers from another service. A change that removes local processing may simply move it to a provider whose consumption is less visible.

The Software Carbon Intensity specification provides a method for relating operational and hardware-related emissions to a defined unit of work within a stated system boundary. Its value begins with making those assumptions explicit.

For an initial engineering review, a business may not have the data needed for a defensible emissions calculation. It can still document compute use, storage growth and data transfer as operational indicators. Label them accurately. They are useful evidence of resource demand, but they are not interchangeable with measured carbon emissions.

Agree what the review includes, what it excludes and why. Keep that boundary stable when comparing a proposed change with the current system. Otherwise an improvement may reflect a different accounting choice rather than a change in what the service consumes.

Consider a hypothetical distributor whose portal refreshes every product's availability repeatedly, even when nobody is viewing most products. The first question is whether that work is necessary at the chosen frequency.

The answer depends on the service promise. Customers may need an accurate availability check at order confirmation without needing every background record refreshed continuously. A technical redesign could reduce redundant activity while preserving the point at which accuracy matters.

Look for similarly specific opportunities. A report may be regenerated despite unchanged inputs. A temporary environment may remain active after the work ends. An image may be transferred at a size the interface never displays. An old integration may continue polling a system nobody uses.

Each case has an owner and a business reason that can be examined. Removing it should follow evidence, not a blanket instruction to minimise everything.

Check the consequences before changing the workload. A cached result needs an appropriate freshness rule. A paused environment needs a dependable restart process. A reduced data feed must still support the decisions people make. The aim is to eliminate unnecessary work while keeping necessary work trustworthy.

AWS's sustainability design principles recommend relating resource use to business output and setting improvement goals. For an SME, that can mean choosing one measurable service and one avoidable source of demand, rather than declaring the entire technology estate sustainable.

Retest the whole task after the change. It should remain correct under normal use and the exceptions that matter. Resource efficiency is a useful engineering outcome only when the service still does its job.

Storage deserves its own review because its growth can be easy to overlook. A team may approve the capture of a new log, upload or export without deciding when the information is no longer useful.

Identify the main categories of stored material and the reason each exists. Customer records, operational logs, backups, generated files and abandoned test data have different purposes. They should not share one indefinite retention rule by default.

Ask who uses the information, what decision or obligation it supports and how its retention is controlled. If a dataset has no owner, establish ownership before assuming it can safely be removed.

Be particularly careful with backups. A duplicate-looking copy may exist to support recovery from a distinct failure. Deleting it without understanding that role can weaken the business while producing a superficially favourable storage graph.

A sensible improvement may involve adjusting the detail of repetitive logs, removing obsolete generated artefacts or changing the way large files are delivered. Record the operating effect as well as the storage effect. If diagnosis becomes harder after a logging change, that cost belongs in the assessment.

The same principle applies to software that demands newer devices from customers or staff. Before adding a heavy interaction or increasing minimum requirements, consider whether it serves the task and whether a lighter approach would work. Hardware lifetime is part of the wider environmental question, although attributing its effect to one software change requires more evidence than a performance test.

Give the team a clear rule: reduce avoidable demand, preserve required records and recovery capability, and make the reason for each exception visible.

A lower bill can result from a pricing change without any reduction in resource consumption. Better hardware utilisation can alter resource demand without producing an equivalent change in the invoice. Electricity-related emissions depend on more than the number of units purchased from a cloud provider.

Keep these measures in separate columns when assessing a change. Record what was observed directly, what a supplier reported and what was estimated.

An emissions estimate should explain its coverage and assumptions. Does it cover the relevant services and region? What period does it represent? How are shared resources allocated? Has the method changed since the baseline? A number presented without that context can imply a precision the evidence does not support.

Location and timing also matter. Moving a workload is not a purely environmental choice: latency, data obligations, availability and operational support may constrain it. A business should assess those conditions together rather than select a region from one headline claim.

Ask providers for information at the level the decision requires. If only a broad annual estimate is available, use it for an appropriately broad comparison. Do not turn it into a supposedly exact footprint for a single customer interaction.

Avoid reducing the entire environmental impact of a service to a carbon label. The scope of a particular calculation may omit other resource demands. A clear, limited claim about a measured improvement is more useful than a sweeping statement about an environmentally neutral product.

The cloud bill is a financial record, not an environmental measurement. It can help locate a workload worth investigating, but the resulting claim needs evidence suited to that claim.

Making each task more efficient does not establish that the service's total demand has fallen. Usage may grow, or the product may add new work that outweighs the saving.

The International Energy Agency's 2026 analysis of energy and AI distinguishes improving task efficiency from increasing uptake and more demanding uses. That distinction is useful well beyond AI.

Track the chosen unit measure and the total over the same period. For example, a report-generation service can become less resource-intensive per completed report while producing many more reports. Both findings matter. One describes efficiency; the other describes the total load the business is choosing to create.

Review the usefulness of new demand too. If a feature encourages repeated generation that nobody reads, improving the generator may address only part of the problem. Product decisions can determine how much work the architecture must perform.

Set an owner and review point for the improvement. Preserve the baseline, the service requirements and the measurement method. If usage changes substantially, explain that change before comparing the next result.

A focused cloud engineering or software development review can start with a practical brief: identify unnecessary work in one service, propose a safe change and measure what actually happened. That gives the business an evidence base it can extend. It also gives it language precise enough to describe progress without claiming more than the measurement can show.