Cloud cost
Cloud Cost Optimization: Find and Remove Unused Resources
Cloud cost optimization usually starts with a dashboard and ends with a shrug. The bill is high, the graphs are noisy, and every resource looks like it might belong to someone.
The better starting point is cleanup. Before resizing databases or negotiating discounts, remove the resources that no longer do useful work. You are not trying to redesign the whole platform. You are finding idle systems, proving they are idle, and retiring them safely.
Start with an inventory that has owners
Unused cloud resources survive because they are anonymous. A VM named api-test-2 might be safe to delete, or it might be the only thing keeping a customer demo alive. You cannot know from the name.
Create a simple inventory with five fields:
| Field | Why it matters |
|---|---|
| Resource type | Compute, database, storage, IP address, load balancer, queue, snapshot |
| Monthly cost | Enough precision to rank the cleanup work |
| Owner | Person, team, repository, or service name |
| Last meaningful activity | Not just created date; look for traffic, CPU, writes, reads, or deploys |
| Decision | Keep, resize, archive, delete, or investigate |
Do not make the inventory perfect. Make it good enough to identify the first ten obvious cleanup targets.
Look for quiet waste first
The safest cleanup targets are resources with low ambiguity. They are usually not dramatic, but they add up because nobody looks at them after launch week.
Good first targets:
- Idle compute instances with no traffic and no recent deploys.
- Stopped or detached disks from old machines.
- Snapshots kept long after the recovery window passed.
- Preview environments for merged or abandoned branches.
- Object storage buckets with old build artifacts or duplicate exports.
- Load balancers, NAT gateways, and public IPs without active services behind them.
- Databases with no recent writes, or read replicas that no longer serve traffic.
The useful question is not “can this be deleted?” The useful question is “what evidence would prove this still earns its keep?”
Use a delete ladder
Cloud cleanup gets risky when teams jump from “unknown” to “deleted.” Use a ladder instead.
| Step | Action | Good for |
|---|---|---|
| Label | Add owner, expiry, and service tags | Unknown but possibly active resources |
| Freeze | Stop new writes or deploys | Old environments and temporary databases |
| Snapshot | Take a backup before removal | Data stores and disks |
| Disable | Turn off or detach while monitoring | Compute, routes, scheduled jobs |
| Delete | Remove after the waiting window | Confirmed stale resources |
The waiting window depends on your system. A staging environment may only need a day. A reporting database might need a full business cycle because it is used at month end.
Prevent recurrence
Cleanup is useful once. A cleanup system is useful every month.
Add expiration dates to temporary environments. Require an owner tag for billable resources. Send a weekly report of unowned resources to the platform channel. Put resource cost in pull request templates when infrastructure changes are proposed. Most importantly, close the loop by deleting the resources that nobody claims.
Turn the biggest category into a small cleanup sprint: one owner, one service area, one week, one measurable bill reduction.
Cloud cost optimization does not have to begin with complex rightsizing work. The first win is often simpler: find what is unused, prove it is unused, remove it carefully, and make sure the same waste does not return.