The Cloud Cost Review Checklist I Use Before Touching Architecture

Cloud cost optimization should not start with deleting resources. It should start with understanding what the spend is, who owns it, and whether it supports the business. Expensive is not always waste. Unexplained is the real problem.

This is the checklist I use before recommending architecture changes.

1. Separate production from everything else

Start by identifying production, staging, development, experiments, demos, and abandoned environments. Non-production waste is often easier to fix because the risk is lower and ownership is less ambiguous.

2. Check tags, labels, and ownership

If teams cannot attribute spend to a product, environment, customer, or owner, cost conversations become emotional. Tagging does not save money by itself, but it gives you the map needed to make responsible decisions.

3. Look for idle and orphaned resources

Common waste includes unattached disks, old snapshots, stopped databases that still carry storage cost, unused load balancers, forgotten IP addresses, abandoned Kubernetes clusters, and development resources running all weekend.

4. Review compute sizing

Rightsizing is not just CPU. Look at memory, network, disk I/O, request patterns, and peak windows. The wrong fix can create reliability issues, so rightsize with workload context instead of blindly following recommendations.

5. Inspect database and storage growth

Databases and storage usually grow quietly. Check backups, retention, logs, old exports, lifecycle policies, indexes, replicas, and whether non-production databases are larger than they need to be.

6. Watch network and NAT charges

Network spend is where many teams get surprised. NAT gateways, egress, cross-zone traffic, logs, and private connectivity can produce meaningful cost even when compute looks reasonable.

7. Commit only after cleanup

Savings plans, committed use discounts, and reservations can help, but they should come after rightsizing and waste cleanup. Committing to waste makes the waste cheaper; it does not make the architecture better.

8. Turn findings into an engineering backlog

A cost report is not useful if it stops at screenshots. Each finding should have an owner, estimated impact, implementation effort, risk, and next action.

9. Create a monthly cost habit

Cloud cost management is not a one-time cleanup. The team needs a lightweight monthly review: what changed, what spiked, what was launched, what can be cleaned up, and what needs architectural attention.

If your AWS or GCP bill is climbing and nobody can explain it clearly, the Cloud Cost & Waste Review turns spend into a ranked roadmap your team can act on.