How to rightsize cloud resources
On this page
- Why waste accumulates
- The metrics that matter
- The rightsizing process
- Step 1: Inventory and rank by cost
- Step 2: Collect 2 to 4 weeks of metrics, including memory
- Step 3: Classify every resource into four buckets
- Step 4: Change one size at a time, in a window, with a rollback
- Step 5: Sweep storage
- Step 6: Make it monthly
- What it’s worth: a worked example
- FAQ
- How much does rightsizing typically save?
- What metrics decide whether an instance is oversized?
- Is it safe to downsize production instances?
- How often should we rightsize?
Nobody sizes cloud instances scientifically on day one: you guess, add a safety margin, and ship. Rightsizing is the discipline of going back with real data, and it’s usually the fastest money in cloud cost work.
Why waste accumulates
Oversizing isn’t a mistake anyone makes once; it’s a default everyone applies constantly:
- Migration sizing carries over. Lift-and-shift maps on-prem servers (sized for 5-year peak capacity) to equivalent cloud instances, importing years of accumulated margin at hourly rates.
- Fear pads everything. “Let’s go one size up to be safe” costs 100% more, forever, and nobody ever files a ticket to undo it.
- Load changes, sizes don’t. The service that needed 8 vCPUs at launch has been rearchitected twice since; its instance hasn’t.
- Storage nobody looks at. Volumes provisioned at 500 GB holding 40 GB, premium IOPS tiers on dev databases, unattached disks from terminated servers.
The result is consistent across the accounts we review: 20 to 35% of compute and storage spend doing nothing. Unlike commitment discounts, recovering it requires no contract, just measurement and a maintenance window.
The metrics that matter
Pull 2 to 4 weeks of data per resource. Averages lie; collect peaks too.
| Metric | Where to get it | Oversized signal | Watch out for |
|---|---|---|---|
| CPU utilization | CloudWatch / Azure Monitor / Cloud Monitoring, built in | p95 below ~20% | Nightly batch spikes that justify the size |
| Memory utilization | Requires an agent on AWS (CloudWatch agent); built into Azure/GCP agents | Peak below ~50% | Caches and JVMs that grab memory by design |
| Disk IOPS and throughput | Built-in volume metrics | Provisioned IOPS with single-digit usage | Backup windows and month-end jobs |
| Network throughput | Built-in | A tiny fraction of the instance’s capacity | Instances sized up purely for network limits |
| Database connections/queries | DB engine metrics | A “production-sized” instance serving a trickle | Connection pools that mask real load |
The memory gap is the classic trap: teams downsize on CPU evidence alone, and the instance starts swapping because nobody was measuring memory. Install the agent first; the data pays for the effort in the first pass.
The rightsizing process
Step 1: Inventory and rank by cost
Export your bill grouped by resource (Cost Explorer, Azure Cost Management, GCP Billing reports). Sort descending. The top 20 resources typically carry 60 to 80% of spend; work those first and ignore the $3/month long tail until it’s automated.
Step 2: Collect 2 to 4 weeks of metrics, including memory
Deploy the monitoring agent where memory isn’t already collected. Resist acting on less than two weeks of data: you need at least a couple of full weekly cycles, and monthly jobs argue for four.
Step 3: Classify every resource into four buckets
- Idle (near-zero load, often forgotten): terminate, after a snapshot and an owner check. A stopped instance still bills for its storage; a terminated one doesn’t.
- Oversized (p95 CPU under ~20%, peak memory under ~50%): downsize one step.
- Right-sized: leave alone, and consider it for commitment discounts now that the size is trustworthy.
- Undersized (sustained CPU over ~70%, memory pressure, throttling): size up. Rightsizing cuts both ways, and finding the three genuinely starved instances buys credibility for the forty downsizes.
Check instance family as well as size: steady web workloads on compute-optimized instances, or old-generation instances (an m4 versus an m7g), often move to a cheaper family at equal performance. Provider recommender tools (AWS Compute Optimizer, Azure Advisor, GCP Recommender) generate these candidates free; treat them as leads to verify, not orders to execute.
Step 4: Change one size at a time, in a window, with a rollback
Resize during low traffic (most resizes are a stop-and-start taking minutes), keep the previous size documented for instant rollback, and watch dashboards for one to two weeks before taking the next step down. Two careful steps beat one heroic leap that causes an incident and gets rightsizing banned politically.
Step 5: Sweep storage
- Delete unattached volumes and orphaned snapshots (snapshot first if in doubt).
- Move general-purpose volumes to the current cheaper generation (gp2 to gp3 on AWS is ~20% off for the same performance, often with no downtime).
- Drop provisioned-IOPS tiers where metrics show baseline usage.
- Add lifecycle rules moving stale object storage to infrequent-access tiers.
Step 6: Make it monthly
Add rightsizing to the same monthly review that watches for bill shock: re-run the recommender, check the top movers, and re-classify anything new. Quarterly, do a deep pass. Waste is a garden; it regrows.
What it’s worth: a worked example
A real-shaped mid-size account, $21,000/month, first rightsizing pass:
| Finding | Action | Monthly saving |
|---|---|---|
| 6 idle instances from finished projects (~$1,100/mo) | Terminate | $1,100 |
| m5.2xlarge app fleet at 9% p95 CPU ($1,690/mo for 6) | Downsize to m5.xlarge | $845 |
| Oversized staging DB, db.r5.xlarge at 6% ($430/mo) | Downsize two steps | $320 |
| 4 TB unattached volumes and old snapshots | Delete | $400 |
| gp2 to gp3 across ~10 TB | Migrate | $200 |
| Dev/test running nights and weekends | Schedule off-hours shutdown | $900 |
| Total | ≈ $3,765/mo (18%) |
Roughly $45,000/year for about a week of engineering time spread over a month, and the fleet is now honestly sized, which is the precondition for buying commitments on top: the combined effect of rightsizing plus a 1-year commitment on the survivors typically lands 35 to 45% below the starting bill.
One caution: rightsize before you commit, never after. A reserved instance purchased at the wrong size locks the waste in at a discount, which is still waste.
FAQ
How much does rightsizing typically save?
Cost reviews of accounts that have never been rightsized routinely find 20 to 35% waste in compute and storage. A single downsizing step, say m5.2xlarge to m5.xlarge, halves that instance’s cost. On a $20,000/month bill, a first rightsizing pass commonly returns $4,000 to 6,000/month for one to two weeks of part-time work.
What metrics decide whether an instance is oversized?
Look at 2 to 4 weeks of data, using peaks as well as averages: if p95 CPU stays under about 20% and peak memory under about 50%, the instance is a downsizing candidate. Memory is the one to be careful with, and on AWS it requires installing the CloudWatch agent, since hypervisor metrics don’t include it. Never size on averages alone; a nightly job that spikes to 90% CPU is why the instance is that size.
Is it safe to downsize production instances?
Yes, with process: one size step at a time, during a low-traffic window, with the old size ready to restore and one to two weeks of observation before the next step. Most instance resizes are a stop-and-start operation taking a few minutes. The risk of a careful downsize is a brief maintenance window; the cost of not doing it compounds monthly.
How often should we rightsize?
A deep pass quarterly and a light review monthly, ideally in the same session where you review overall spend. Waste grows back: teams overprovision new services to be safe, traffic patterns shift, and yesterday’s correct size becomes today’s oversize. Mature teams automate detection with recommender tools and reserve human judgment for the resize decision itself.
Suspect your account is carrying that 20 to 35%, but don’t have the cycles to run the pass? Talk to a Webisoft cloud engineer. We’ll review your usage data, hand you a ranked list of safe resizes with the dollar figures attached, and help execute the ones you approve.
Frequently asked questions
How much does rightsizing typically save?
Cost reviews of accounts that have never been rightsized routinely find 20 to 35% waste in compute and storage. A single downsizing step, say m5.2xlarge to m5.xlarge, halves that instance's cost. On a $20,000/month bill, a first rightsizing pass commonly returns $4,000 to 6,000/month for one to two weeks of part-time work.
What metrics decide whether an instance is oversized?
Look at 2 to 4 weeks of data, using peaks as well as averages: if p95 CPU stays under about 20% and peak memory under about 50%, the instance is a downsizing candidate. Memory is the one to be careful with, and on AWS it requires installing the CloudWatch agent, since hypervisor metrics don't include it. Never size on averages alone; a nightly job that spikes to 90% CPU is why the instance is that size.
Is it safe to downsize production instances?
Yes, with process: one size step at a time, during a low-traffic window, with the old size ready to restore and one to two weeks of observation before the next step. Most instance resizes are a stop-and-start operation taking a few minutes. The risk of a careful downsize is a brief maintenance window; the cost of not doing it compounds monthly.
How often should we rightsize?
A deep pass quarterly and a light review monthly, ideally in the same session where you review overall spend. Waste grows back: teams overprovision new services to be safe, traffic patterns shift, and yesterday's correct size becomes today's oversize. Mature teams automate detection with recommender tools and reserve human judgment for the resize decision itself.