practice
Waste Elimination
Removing spend that produces no value at all — the least controversial and most consistently available saving.
Definition
Waste is resource spend with no corresponding benefit: nothing uses it, nobody reads it, nothing depends on it. It differs from inefficiency in that removing it involves no trade-off, which is what makes it the right place to start.
The categories, in rough order of typical value
- Idle non-production environments running nights and weekends. Usually the single largest item and fixable with a schedule.
- Orphaned resources — volumes from terminated instances, unattached addresses, idle load balancers, empty clusters, forgotten environments from a project that ended.
- Over-provisioned resources far beyond any headroom requirement — a database at 3% utilisation, a volume ten times its used capacity.
- Snapshots and backups retained indefinitely. Frequently larger than the primary data.
- Logs and metrics nobody queries, retained at full indexing cost.
- Duplicate tooling — three monitoring products, two CI systems, because each was adopted by a different team.
- Zombie workloads — a service still running that nothing has called in months. Traffic data answers this definitively and is rarely consulted.
- Data transfer that should not exist — cross-zone chatter, traffic through a NAT gateway that a private endpoint would bypass.
Making it stick
One-off cleanups regress within a year. What holds:
- Automated detection, running continuously, reporting to owners rather than to a central team.
- Ownership tags enforced at creation, so "who owns this?" has an answer.
- Expiry by default on non-production resources: created with a lifetime, extended deliberately, deleted automatically.
- Deletion as the default for the unclaimed, after notice. If nobody responds to "this will be deleted in 14 days", it was not needed.
The care required
- Verify before deleting. A resource with no traffic may be a disaster recovery standby, a quarterly job, or a compliance archive.
- Snapshot before deleting where practical, so a mistake is recoverable.
- Notify the owner and give a window, or you will delete something important and lose the mandate for the whole programme.
Failure scenarios
- A cleanup that deletes a standby, discovered during the next failover.
- One-off cleanups with no prevention, so waste re-accumulates.
- No ownership data, so nothing can be safely deleted and everything is kept.
- Waste elimination pursued while a large architectural inefficiency is ignored, because the small wins are easier to demonstrate.
Interview question
"How would you identify workloads that are running and serving no purpose, and how would you make it safe to remove them?"