Cloud costs can grow when launch capacity stays in place, snapshots have no retention policy, services transfer data across zones, and unused projects remain running. Use this checklist to review those costs each month.
Why cloud bills grow: architecture, utilization, pricing, and process
Review four sources of cost growth. Architecture: a system sits in the wrong place or uses a heavyweight service for a simple job. Utilization: capacity was sized for the worst day and never revisited. Pricing: commitments and spot capacity go unused. Process: nobody owns tagging or expiration, so waste persists. Review these categories on your bill and record which costs can be reduced.
Cloud resource checklist
- Terminate or hibernate idle instances older than 30 days.
- Downsize instances with
CPUUtilizationp95 under 40% for two weeks. - Enable lifecycle rules: S3 to IA/Glacier, logs with 30–90 day expiry.
- Remove unattached EBS volumes and orphaned snapshots.
- Tag owner and purpose; quarantine resources without both.
Monthly and quarterly reviews
Run the quick list above every month, then reserve one quarterly session for deeper moves: consolidate low‑traffic services, move steady internal apps to flat‑rate hosting, and replace per‑GB network chokepoints. Assign a person to run a 45‑minute review and record the follow-up work.
Resource tags and cost allocation
Start with two required resource tags: owner (team or person) and purpose (service or project). Quarantine resources without both.
Keep cost allocation simple: a top‑level split by product or business unit is enough to make directionally correct decisions. Once owners see their own line item, unowned waste stops being invisible.
Workloads, pricing options, and targets
| Workload | Action | Target |
|---|---|---|
| Steady 24x7 DB | Convert to Savings Plan / RIs | 60–80% coverage |
| Web tier | Right-size family + autoscale | p95 CPU 50–70% |
| Batch/ETL | Spot with interruption handling | 70% spot mix |
| Dev/QA | Schedules + stop at night/weekends | 40–60% runtime cut |
Reviewing instance size and pricing
Use utilization metrics to identify instances whose capacity exceeds the workload. Track p95 CPU for the last two weeks; anything under 40–50% is a downgrade candidate. Prefer newer instance families for better price/perf. For steady 24×7 services, use Savings Plans or reserved capacity—coverage near zero is the same as paying list price. Batch and ETL jobs can often run on spot with interruption handling. Schedule development and QA resources to stop when they are not needed.
Look at memory, IO, and connection limits too. A CPU graph at 60% can mask a database constrained by IOPS or a JVM running near max heap. Prefer fewer, larger instances over many tiny ones when inter‑service chatter is your constraint; prefer lower-capacity instances when bin‑packing spreads work across AZs you already pay for. Measure before and after, and record the cost and performance results for the next review.
Storage classes and retention policies
Stored data accumulates unless retention rules remove it. Add lifecycle policies the day a bucket or log group appears: objects move to IA or Glacier after 30–90 days; logs expire. Review snapshot chains older than ninety days and keep only what recovery requires. Review these policies as recovery and retention requirements change.
Set retention periods separately for recovery backups and historical archives. Keep restorable points that match your recovery plan, then move everything else to colder classes or delete it. For analytics buckets, partition by date and expire old partitions. For logs, aggregate to daily or hourly parquet and expire raw streams after your investigation window. These moves lower cost and improve query speed at the same time.
Data transfer charges to check
- NAT Gateway processing vs. interface endpoints (
PrivateLink). - Cross‑AZ chatter: co‑locate heavy talkers or use same‑AZ services.
- Egress from object storage or CDN misconfiguration.
- Uncached service‑to‑service calls across regions.
Data transfer charges
NAT Gateways charge per GB processed; cross‑AZ traffic charges in both directions. These charges can exceed the cost of the compute instances involved. Review interface endpoints for services with high NAT traffic. Place services that exchange large amounts of data closer together. Cache or batch cross‑region calls. Use the Cost and Usage Report to separate these charges from compute costs.
Cost checks during development and deployment
Make budget checks part of delivery. Add a terraform plan cost estimate gate before merge. Fail deploys that add resources without required tags. Provision short‑lived review environments with TTLs. Capture service‑level budgets in dashboards alongside latency and errors. Make the cost information available during code review and deployment planning.
Assigning responsibility and review thresholds
Write down ownership: which team holds the cloud account, the networking boundary, the database fleet. Give the monthly review a single accountable owner. Document three stop‑conditions that pause deploys: budget burn rate, error budget burn, and a security finding above your risk threshold. If you need outside help, our AWS cost optimization review starts with the same evidence and leaves you with policies the team keeps.