A platform's infrastructure is over-provisioned but nobody can say by how much. What is the systematic approach to finding and removing waste?

The categories of waste, in rough order of size

• Idle non-production environments. Development, staging and test running twenty-four hours a day for a team that works eight. Turning them off outside working hours is trivial and frequently a meaningful share of compute spend.
• Over-provisioned instances, where the requested resources far exceed observed usage. Usually set once at a guess and never revisited, and the guess was conservative because the consequence of being wrong was an incident.
• Orphaned resources: unattached volumes, unused addresses, old snapshots, load balancers with no targets, clusters from a project that ended. These accumulate silently and nobody owns them.
• Over-retained data, with no lifecycle policy, growing monotonically.
• Redundant tooling, where several products do the same job because different teams bought them.
• Duplicated data, where the same dataset exists in several systems because each pipeline made its own copy.

The systematic approach

1. Attribute everything to an owner. Unattributable spend cannot be reduced, because nobody is accountable for it — and this is where the exercise usually stalls. Structural attribution (account or project per workload) beats tagging, which never survives contact with reality.
2. Measure requested against used, per workload, over a representative period including peak.
3. Rightsize with headroom, and automate the recommendation rather than doing it once.
4. Set lifecycle policies by default on storage, logs and snapshots, so the default is bounded rather than infinite.
5. Schedule non-production, which needs no analysis and delivers immediately.
6. Delete orphans, which requires an owner check and is otherwise straightforward.

The organisational point

Rightsizing done once is undone within two quarters. Waste accumulates continuously as workloads change, and the only durable fix is continuous visibility with a named owner — a recurring report to the team that owns the spend, not to a central function that can only file tickets.

The caution

Rightsizing removes headroom, and headroom is what absorbs a spike. An instance sized to observed average usage will fail at peak. The exercise must use peak observation with a deliberate margin, and it should exclude anything whose failure mode is expensive.

Cost optimisation that causes an incident has cost more than it saved, and the fastest way to lose the organisation's appetite for efficiency work is to demonstrate that once.