Compute
Intermediate 12 min read Compute

Right-Sizing and Utilization

Pay for what you actually use

Right-sizing matches running resources to actual demand using utilization data, and recovering idle resources is usually the fastest, safest cost win in any cloud estate.

rightsizingutilizationcostidleunderutilizedmetrics
Prerequisites: Compute Families and Sizing
Before we start

What you will learn

  • Measure CPU, memory and network utilization across a fleet
  • Identify idle and underutilized resources
  • Turn findings into a safe right-sizing rollout
In 60 seconds

Clouds are metered per unit you allocate. Utilization data tells you which instances run at <10% and can shrink, stop, or move to spot/serverless — after you've chosen a safe policy for downscaling.

Introduction

What is this?

Utilization = observed usage vs capacity (CPU%, memory, IOPS, network). Right-sizing changes instance size/type or moves to serverless/spot. Sources: AWS Compute Optimizer and Trusted Advisor, Azure Advisor and Azure Resource Graph, GCP Recommender (idle/resize), plus agent-based collectors (CloudWatch, Datadog, Prometheus). Idle = <1% usage or zero traffic for many days.

Motivation

Why do you need it?

  • Underutilization wastes 20-40% of many bills routinely.
  • Safe downsizing is reversible in minutes — the highest-value quick win.
  • Rightsizing reduces the blast radius of over-provisioned networks/firewalls.
  • Every resize decision well-documented becomes a repeatable cost-optimization playbook.
Think about it

Mental model

Imagine

A gym membership for a treadmill you run once a month

Think of

Idle/underutilized compute

You pay for capacity you don't use. Cancel (stop), downgrade (shrink) or switch to a pay-per-visit model (serverless) for the bits you actually use.

Mechanics

How it works

  • Collect metrics for 1-2 weeks (peak + trough) per instance across the fleet.
  • Score each: used<5% (idle), 5-20% (candidate to shrink), 20-80% (healthy), >80% (candidate to grow or split).
  • Recommenders compute estimated savings from cost per metric (e.g. 'this m5.xlarge could be m5.large').
  • Apply with a schedule: shrink after-hours first for spiky workloads, then widen.
  • Pair with autoscaling so future demand is met by fleet size, not oversize.

Right-sizing workflow.

Collect
Classify
Recommend
Apply on schedule
Verify + repeat
Hands-on

Examples

Spot idle instances with queries

Spot idle instances with queries
# AWS: find instances with low average CPU last 2 weeks
aws ec2 describe-vpcs --no-paginate >/dev/null  # placeholder for a metrics query
# Azure: Advisor reports idle VMs
az advisor recommendation list --category Cost
# GCP: recommender idles
gcloud recommender recommendations list   --recommender=google.compute.instance.IdleResourceRecommender   --location=global

Each provider exposes recommendation APIs you can script into quarterly reviews.

Real world

In production

  • A retail estate cut 31% by resizing always-on m5.large DB read replicas to r6g.large after p90 metrics.
  • A games studio stopped 40 dev instances outside office hours via a scheduler that also rightsizes them on re-enable.
  • Compute Optimizer flagged a fleet of 3-yr-old t2.medium; a lift to t3.small with autoscaling saved 45%.
Guidelines

Best practices

  • Use a rolling schedule (e.g. Friday night) so regressions surface before weekend traffic.
  • Record a baseline snapshot of metrics before each change so you can diff.
  • Exclude stateful/special instances (DBs, bastions) from blind automation.
  • Automate via IaC so size changes are reviewable, versioned, reversible.
Watch out

Common mistakes

  • Downsizing a CPU-bound app 'because Advisor said so' without checking peak windows.
  • Forgetting burst credits: t2/t3 baseline throttles when starving.
  • Automatically stopping instances that hold EBS volumes → storage bill remains.
  • Rightsizing once and never measuring again — utilization drifts yearly.
Root cause analysis

Common issues

Error
App slows after downsizing
Root cause

Peak metrics missed the averages collected

Fix

Re-profile with percentile metrics and restore the previous size; resize again with headroom.

Error
Idle detection flags a hot standby
Root cause

Standby has near-zero CPU but holds failover state

Fix

Exclude resources with failover/HA roles from automatic idle actions.

When things break

Debugging tips

  • If a 'rightsized' app gets slow, bump the family before the size — bottleneck might be I/O shape.
  • Compare p95/p99, not average, for capacity: averages hide spikes.
  • Watch for CPU credit balance when downsizing burstable types.
  • Correlate with cost: a savings report that ignores actual unit prices misleads.
Interviews

Interview checkpoint

Practice

Hands-on lab

Run a Right-Sizing Analysis on a Toy Fleet
30 min · intermediate
In progress
Objectives
  • Collect and classify utilization for a simulated fleet
  • Compute potential savings from a price table
  • Produce a written right-sizing recommendation

Run a Right-Sizing Analysis on a Toy Fleet

30 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

Average CPU is the best metric for right-sizing decisions.

Go deeper

Official documentation

AWS — Compute Optimizer
docs
Azure — Advisor cost recommendations
docs
GCP — Recommender
docs