The meter keeps running after the need disappears
A test environment is created for a project. A storage volume is detached but not deleted. A server is sized for a peak that never arrives. A database survives after an application is replaced. Each decision can be reasonable when it is made. The waste appears when nobody owns the decision to shrink or remove the resource later.
Unlike a once-off hardware purchase, cloud consumption keeps translating yesterday's decisions into today's invoice. That is useful when demand is real and expensive when it is not.
For a small or mid-sized business the amounts may look modest month by month, which is exactly why they persist. A forgotten staging server or an unattached disk rarely triggers an alarm on its own. It is the accumulation across months, accounts and projects that turns a tidy cloud bill into one nobody can explain, a problem we look at more broadly in cloud costs rising without explanation.
Why unused cloud spend survives
Provisioning is often distributed across engineering and operations while the invoice arrives centrally. Teams can therefore understand what a resource does without seeing its full cost, while finance sees the cost without knowing whether the resource is still required.
AWS Compute Optimizer is designed to analyse resource configuration and utilisation in order to provide rightsizing recommendations and identify idle resources. AWS's Well-Architected guidance recommends decommissioning unused resources, triggered by events such as periodic audits or changes in usage, and notes that the effort spent searching for unused resources should reflect the potential savings. Microsoft's Azure Advisor does similar work on its platform, flagging virtual machines that show very low utilisation for shutdown or resizing. The common principle is not vendor-specific: cloud optimisation is an operating discipline, not a once-off migration task.
The UK National Cyber Security Centre adds a security angle that is easy to overlook. In its asset management guidance it observes that assets which are no longer required become liabilities, because they can open up vulnerabilities or expose information without any corresponding benefit. An orphaned server is a cost line and an unpatched entry point at the same time.
A worked example
Picture a Cape Town software company with around 40 staff that builds client portals. Each new client project gets its own development and test environment. Projects end, developers move on, and the environments stay. Eighteen months later the monthly bill has crept upward while revenue has been flat. When the operations lead exports resource-level costs, she finds test databases for two clients who left last year, several volumes not attached to any server, and production servers sized for a launch-week spike that happened once. None of it was negligent. Nobody had been asked to own the end of a resource's life.
How the pain becomes money
- Direct consumption: idle compute, storage, databases, network services and other resources continue to bill.
- Overprovisioning: resources sized above actual demand consume more budget than the workload requires.
- Support overhead: unnecessary resources still need monitoring, patching, security and ownership.
- Budget distortion: waste makes useful cloud workloads look more expensive than they really are.
- Scaling cost: uncontrolled resource creation allows infrastructure spend to grow faster than the value delivered.
The commercial signal. If a resource has a monthly cost but no named owner, current workload or retirement date, it is a candidate for investigation.
Calculate the waste from your own bill
Start at resource level rather than using a generic percentage benchmark.
| Measure | Calculation |
|---|---|
| Annual idle-resource exposure | monthly cost of confirmed idle resources × 12 |
| Annual rightsizing exposure | current annual cost − annual cost of the validated right-sized configuration |
Keep idle resources separate from merely underutilised resources. A resource with low average utilisation may still be necessary for peaks, resilience or latency. Optimisation should remove cost without silently removing required capacity.
Provider recommendations are a starting point, not a verdict. Microsoft's own documentation lists situations where a resize recommendation may not apply, including capacity provisioned for upcoming traffic, machines kept for disaster recovery and environments used for specific testing. It also cautions that savings estimates are based on retail rates and do not account for existing discounts or reservations, so listed savings can be higher than what is actually achievable. Validate before you count the money.
Why buying discounts first can be the wrong move
Commitment discounts can reduce unit prices, but they do not answer whether the underlying resource should exist. Committing to unnecessary capacity can lock a lower price onto the wrong operating baseline. Usage optimisation and ownership should therefore precede or accompany rate optimisation.
The order matters in practice. If the Cape Town company above had bought a one-year commitment before its clean-up, it would have locked in a discount on servers it was about to delete or shrink. Clean the baseline, then commit to what remains.
How to diagnose the problem
Three questions reveal most of the picture quickly:
- Can every material resource be traced to an owner? Look at tags or naming. If a large share of spend is untagged, ownership is the first gap, as discussed in cloud costs without business owner allocation.
- What does the provider's own tooling flag? Idle and rightsizing recommendations are free signals in most platforms. Note how long each has been ignored.
- Which resources belong to finished projects or replaced systems? Compare the resource list with the project register and application inventory.
When this becomes commercially urgent
Priority rises when cloud spend grows faster than revenue or transaction volume, monthly bills surprise finance, test environments have no shutdown policy, resources cannot be mapped to owners or products, or teams keep increasing capacity to solve performance problems without measuring utilisation.
What good looks like
Every material resource is attributable to an owner, workload and cost centre. Budgets and anomaly alerts exist. Idle resources are reviewed on a cadence appropriate to spend. Rightsizing decisions use actual utilisation and business requirements. Retirement is part of the resource lifecycle rather than an exceptional clean-up exercise.
The same lifecycle thinking applies to software subscriptions, which accumulate in much the same way; see unused software licences as financial waste. And like most hygiene work, it is cheaper done routinely than in a crisis, as argued in why recurring systems maintenance is cheaper than emergency repair.
Trade-offs
Aggressive clean-ups carry their own risk. Deleting a volume that turns out to hold the only copy of an old client's data, or shrinking a server just before month-end processing, can cost far more than the savings. AWS's guidance on decommissioning advises completing final checks, such as taking snapshots or backups, before disposal. A short retention period for snapshots of deleted resources is cheap insurance.
Practical next actions
- Export resource-level cost and usage for the last three to six months.
- Find unattached, stopped, idle and persistently low-utilisation resources.
- Assign an owner and business purpose before changing anything.
- Validate resilience and peak-demand requirements.
- Delete confirmed waste and rightsize safe candidates.
- Set budgets, anomaly alerts and recurring optimisation reviews.
- Track realised savings after changes, not just theoretical recommendations.
What to do first
If you only have an afternoon, do two things. First, list every resource with no owner tag and send the list to team leads with a two-week deadline to claim or release. Second, make "who switches this off, and when" a required field for every new environment. The first recovers past waste; the second stops new waste from forming.
Bottom line
The cloud's commercial advantage is elasticity. Paying indefinitely for capacity nobody needs throws that advantage away. The fix is not indiscriminate cost cutting; it is making resource ownership, utilisation and retirement visible enough that spend follows business demand.
Method note: no generic cloud-waste percentage is applied. Use actual billing, utilisation and validated workload requirements to calculate avoidable spend.
Sources and further reading
- What is AWS Compute Optimizer? - AWS Compute Optimizer (last verified 10 October 2026)
- COST04-BP03 Decommission resources - Cost Optimization Pillar (last verified 10 October 2026)
- Optimize virtual machine (VM) or virtual machine scale set (VMSS) spend by resizing or shutting down underutilized instances - Azure Advisor (last verified 10 October 2026)
- Asset management (last verified 10 October 2026)
- Workload Rightsizing - AWS Compute Optimizer - AWS (last verified 10 October 2026)
- Usage Optimization Opportunities (last verified 10 October 2026)
Related Mellorca reading
- Paying for Server Capacity the Business Does Not Use
- When Nobody Owns the Business Software You Pay For
- How Many Software Subscriptions Do You Pay For? The Cost of Not Knowing