FinOps / Guide 3
Rightsizing
Using real usage to pick smaller or newer sizes, a safe way to make the change, and what to resize besides VMs.
Rightsizing means matching the size of a resource to what it actually uses. It is usually the biggest single saving after deleting unused resources, and in the cloud it is reversible: if a smaller size turns out to be too small, you move back with a restart. This guide covers how to choose candidates, how to make the change safely in each cloud, and what else to resize besides VMs.
Pick the candidates
Start with the recommendations from guide 02, then sanity-check them. Useful rules of thumb, based on the thresholds Azure Advisor uses:
| Pattern over 2 to 4 weeks | Likely action |
|---|---|
| Peak CPU (P95) under about 3% and almost no network traffic | Idle. Ask the owner; shut down or delete. |
| User-facing: P95 CPU under 40% and memory under 60% on a smaller size | Downsize one step. |
| Batch or back-end: P95 CPU under 80% and memory under 80% on a smaller size | Downsize; these workloads can run hotter. |
| Low average CPU with short bursts | Burstable sizes: Azure B-series, AWS T-family, Google Cloud e2-micro to e2-medium or shared-core. |
| High CPU most of the day | Leave it, or upsize. Rightsizing goes both ways. |
Ask the owner before changing anything. Usage data doesn't show a disaster recovery server that must stay large, or a month-end job that ran before your lookback window.
Make the change safely
- Agree a window with the owner. Most resizes need a restart.
- Check the target size supports what the VM uses today: number of disks, disk performance, network bandwidth, accelerated networking and the processor architecture.
- Take a backup or snapshot if the VM isn't already protected.
- Resize one step at a time (for example 8 vCPU to 4, not 8 to 2).
- Watch it for a week, then decide whether to go down another step.
# Azure: resize (the VM restarts; deallocate first if the new size isn't available on the current hardware)
$vm = Get-AzVM -ResourceGroupName 'rg-notes-test' -Name 'vm-notes-test-01'
$vm.HardwareProfile.VmSize = 'Standard_D2s_v5'
Update-AzVM -VM $vm -ResourceGroupName 'rg-notes-test'
# AWS: the instance must be stopped to change its type
$id = 'i-0123456789abcdef0'
Stop-EC2Instance -InstanceId $id
(Get-EC2Instance -InstanceId $id).Instances[0].State.Name # wait until 'stopped'
Edit-EC2InstanceAttribute -InstanceId $id -InstanceType 't3.medium'
Start-EC2Instance -InstanceId $id
# Google Cloud: stop, change the machine type, start
gcloud compute instances stop vm-notes-test-01 --zone=us-east1-b
gcloud compute instances set-machine-type vm-notes-test-01 --zone=us-east1-b --machine-type=e2-standard-2
gcloud compute instances start vm-notes-test-01 --zone=us-east1-b
Newer generations cost less
Each new VM generation usually gives more performance for the same or lower price. Moving from an old family to a current one is a rightsizing win even when the vCPU count stays the same.
| Azure | AWS | Google Cloud | |
|---|---|---|---|
| Move away from | v2 and v3 sizes | m4, c4, r4, t2 and other older families | N1 machine types |
| Consider | Current v5 and v6 sizes; Arm-based sizes (Cobalt, Ampere) for Linux workloads that support Arm | Current generation families; Graviton (Arm) for Linux workloads that support it | E2 for general workloads; N2, N2D or newer series; Arm-based series for supported workloads |
Arm-based sizes are often the cheapest per unit of performance, but test first: the operating system, agents and every application component must support Arm. Windows workloads generally stay on x86.
Rightsize more than VMs
- Disks: a disk sized for growth that never came. Disks can grow but generally can't shrink, so start small. Check the disk type too: see guide 06.
- Databases: managed database tiers (Azure SQL, Amazon RDS, Cloud SQL) are often sized once and forgotten. The same CPU and memory checks apply. Azure SQL Database serverless and Aurora Serverless scale down automatically for spiky workloads.
- App hosting plans: an Azure App Service plan or a container cluster sized for launch day. Check instance counts and node sizes.
- Scale sets and node pools: let autoscaling set the count instead of a fixed number sized for the peak.
Rightsize before you commit
Always right-size before buying reservations, savings plans or committed use discounts. Committing to an oversized fleet locks in the waste for one or three years. The order is: delete what's unused, right-size, schedule non-production, then commit to what's left.