Cost Optimization
Intermediate 15 min read Cost Optimization

Rightsizing & Removing Wastage

The fleet you run vs. the fleet you need

Right-sized instances + zero idle waste: analyze utilization (CPU/IO/memory), downsize or change families, and hunt the three classic leaks: idle/unused resources, over-provisioned storage, and talkative-but-boring network egress.

rightsizingutilizationidlewastagedownsizeunattachedstorage lifecycle
Prerequisites: Cost Fundamentals & Billing
Before we start

What you will learn

  • Analyze utilization to find over- and under-provisioned instances
  • Identify and remove idle resources safely
  • Cut storage and egress waste
In 60 seconds

Rightsizing = match instance size to real utilization (CPU/RAM from CloudWatch/Monitor days of data): downsize the 90%-idle db.m5.xlarge, upsize the starved one. Wastage = paying for things you don't use: unattached volumes, snapshots, idle dev/test, and egress leftovers — a periodic sweep.

Introduction

What is this?

Analyze: CloudWatch metrics (CPUUtilization, Memory, IOPS, Network) at 1/5-min averages over ≥7-14 days; Azure Monitor/insights, GCP utilization; top-right recommendations from advisor/logs. Right-size math: p95 utilization × headroom → new family/size (resize without outage with some services; resize others with a swap). Storage: GB-months on hot tier vs cold/archive, lifecycle policies, snapshot creep (deleted volumes leave orphans), unattached EBS, over-provisioned IOPS. Instances: idle dev (night/weekend off), NAT/LB excess, lone instances vs fleet savings, costliest-per-CPU. Egress cleanup: cross-region data replication vs once, CDN cache fill, backup out-of-region copies by need. Automation: instance scheduler for dev/test (stop at 6pm), lifecycle policies, and monthly 'orphan hunt' scripts. Guardrails: don't right-size the spiky SRE infra (latency, redundancy), size for availability not just p95.

Motivation

Why do you need it?

  • Right-sizing + idle removal is usually the second-biggest lever after commitments — and it's greener.
  • Idle clusters are pure burn: dev environments at 3am cost the same as at 3pm.
  • Storage/eometrics creep silently: snapshots and tiers bill forever even after 'deletion'.
  • Downsizing is instant money: no new contract, just a smaller instance minus the risk.
Think about it

Mental model

Imagine

A mover who rented a 10-ton truck for a living-room move

Think of

Over-provisioning

You pay for the truck, not the cargo. Downsizing (rightsizing) = rent the right truck; the cargo (workload) is what should size the vehicle — most clouds let you swap mid-trip.

Mechanics

How it works

  • Collect utilization over a representative window (≥7 days, include a peak).
  • Rank instances by p95 CPU/RAM; set per-tier slack (e.g., 15-30% headroom).
  • Migrate/downsize below-slack instances; investigate idle ones.
  • Sweep storage: orphans, snapshots, hot-vs-cold tiering, lifecycle.
  • Add automation (schedulers, policies) + a monthly orphan-hunt report.

Rightsize loop.

Measurement
Rank
Downsize/migrate
Sweep idle
Automate + review
Hands-on

Examples

Right-size decision table

Right-size decision table
# instance m5.xlarge (4vCPU/32GB) avg 8% CPU, 14% mem peak
#  → p95 CPU ~25% over 14d. Headroom 20% → needs ~1.5 vCPU
#  → downsize to m5.large (2vCPU/8GB): savings ~50% SKU.
# Instance db.r5.xlarge IOPS 12% avg: keep (DB redundancy + I/O bursts) —
#  rightsizing rule: size for availability, not p95, on tier-1.

The p95-based downsizer is conservative by design — enough signal to act, not so aggressive that outages follow.

Real world

In production

  • Scheduler stops non-prod at 20:00 (e.g., AWS Instance Scheduler, Azure automation, GCP scheduler).
  • Monthly orphan-hunt: unattached EBS, dead snapshots, idle ASGs, empty LBs.
  • Storage lifecycle: hot→cold→archive via policy; snapshot retention reviewed.
Guidelines

Best practices

  • Measure ≥7 days and include a peak day; p95 + slack, not p95 alone.
  • Downsize tier-1 carefully: DBs size for availability + bursting, not just p95.
  • Idle sweep before commitments: don't commit to dead instances.
  • Automate dev/test stop; document the overnight pause as intended.
  • Revisit monthly: fleets drift; the rightsizing report is a standing review.
Watch out

Common mistakes

  • Downsizing on CPU-only data while memory is the real constraint (OOM swap).
  • Idle hunting in prod that's 'quiet-during-off-peak' — that's capacity, not waste.
  • Deleting 'unattached' volumes without checking the snapshot/backup dependency first.
  • Right-sizing the DB from p95 alone → outage when the burst arrives.
When things break

Debugging tips

  • Downsized box OOMs at midnight → look at memory (not CPU) utilization history; revert or add swap.
  • 'Idle' instance truly busy in-latency → its metric is latency, not CPU; exclude from sweep.
  • Snapshots keep growing after 'delete' → the snapshot chain you kept; prune series correctly.
  • Egress peaked after a migration → replication strategy choice; batch or reduce scope.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

The classic wrong metric for rightsizing a DB:

2

Cheapest first waste to hunt each month:

Go deeper

Official documentation

AWS Compute Optimizer
docs
Azure Advisor recommendations
docs
GCP recommendations
docs