Updated 13 Oct 2026 • 5 mins read
Rightsizing in the Cloud: How to Do It Safely
Rightsizing matches each cloud resource to what its workload actually uses, and it is the largest usage-side saving in most estates. This guide covers why console recommendations get ignored, the metrics beyond CPU that make rightsizing safe, a step-by-step method, before-and-after examples in US dollars across clouds, and how Opslyft's Atlas inventory makes it safe at scale.
Rightsizing has the best savings-to-effort ratio of anything in cloud cost management and the worst reputation among the engineers who have to do it. The numbers are not in dispute: most estates run compute at 20 to 40 percent average utilization, stepping an instance down one size roughly halves its cost, and the cloud consoles will cheerfully list a hundred candidates by Tuesday. What is in dispute is whether any of those changes can be made without an incident, and every engineer who has shrunk a server on the strength of a CPU graph and watched it fall over under a memory spike knows why the recommendations sit unactioned.
This guide is about doing it safely: which metrics actually predict whether a resource can be shrunk, why console recommendations based on utilization alone get ignored, a step-by-step method that treats each recommendation as a hypothesis to test, worked before-and-after examples across AWS, Azure, GCP, and Kubernetes in US dollars, and why having a live inventory that knows what each resource is for, a Cloud CMDB, is what makes rightsizing safe at scale rather than safe one server at a time. For the AWS-specific tooling, our guide to AWS Compute Optimizer is the companion to this one.
The short answer: Cloud rightsizing is matching each resource's size to what its workload actually uses, and it typically cuts the cost of affected resources by 30 to 50 percent. It is safe when four conditions hold: you measure memory, disk, network, and application latency as well as CPU, over at least two to four weeks including peaks; you know what the resource is for and how critical it is before changing it; you step down one size at a time with a rollback ready and watch application metrics afterward; and someone owns the change. Console recommendations fail the first two conditions, which is why they go unactioned. A live inventory with owner, purpose, criticality, and change history for every resource, a Cloud CMDB, is what makes the method work across an estate rather than one resource at a time, and it is how Opslyft's Atlas generates recommendations that weigh a workload's purpose rather than its utilization alone.
Key Takeaways
- Rightsizing is usually the largest usage-side saving available, ahead of commitments, and should always happen before buying Reserved Instances or Savings Plans.
- CPU utilization alone is a dangerous basis for a change; memory, disk I/O, network, burst patterns, and application latency are what predict whether a smaller size will hold.
- Console recommendations get ignored because they do not know what a resource is for, who owns it, or how critical it is; those three facts are what make a change safe.
- Step down one size at a time, in a window, with rollback, and watch application metrics for a full business cycle afterward.
- A Cloud CMDB, a live inventory with owner, purpose, cost, and change history per resource, is the difference between rightsizing one server safely and rightsizing an estate safely.
Why Console Recommendations Get Ignored
Every major cloud offers a rightsizing recommender, and every one of them produces a long list that engineers mostly do not act on. The pattern is consistent enough to have causes rather than excuses.
- They measure the wrong thing. Most recommendations rest on CPU utilization over a short window, often 14 days. CPU is the metric least likely to be the constraint on a modern workload; memory pressure, disk throughput, and connection counts cause far more incidents after a downsize, and a 14-day window misses month-end, quarter-end, and seasonal peaks.
- They do not know what the resource is for. A recommendation to shrink a payment-processing node looks identical to one for a nightly batch box. The console cannot tell them apart, so the engineer has to, which means investigating every item before acting on any of them.
- They have no owner. The list sits in a console that belongs to nobody. A recommendation that arrives as a ticket assigned to the team that runs the workload gets considered; one in a central dashboard gets reviewed quarterly and deferred.
- They optimize for the minimum, not the safe step. Recommending the smallest instance that fits the observed average invites an outage at the first peak. Engineers who have been burned once discount every recommendation after.
These are the same reasons the broader cloud waste problem persists: the finding is cheap and the action is expensive, and nothing connects the two. Safe rightsizing is mostly about fixing that connection.
The Metrics That Make Rightsizing Safe
A resource can be shrunk safely when you can answer, with data, whether the smaller size will hold under the workload's real peaks. That takes more than one number.
| Metric | What it tells you | Why CPU alone misses it |
|---|---|---|
| CPU utilization (average and p95) | Compute headroom | The one metric consoles use; often not the constraint |
| Memory utilization (peak) | Whether a smaller memory footprint will swap or be killed | Memory pressure is the most common post-downsize incident |
| Disk I/O and throughput | Whether storage performance is tied to instance size | Many instance families scale disk throughput with size |
| Network throughput | Whether bandwidth limits bind at smaller sizes | Smaller instances have lower network caps |
| Burst and seasonality (4 to 8 weeks) | Peaks that a short window hides | Month-end and campaign spikes sit outside 14 days |
| Application latency and error rate | Whether users will notice | Utilization can look fine while p99 latency doubles |
| Database query time and connections | Whether a smaller DB class holds under load | CPU on a database rarely predicts query latency |
| Kubernetes requests versus usage | How much reserved capacity is never used | Requests, not usage, drive cluster cost |
For storage and databases, the IOPS and throughput characteristics of each size matter as much as capacity, and for Kubernetes the gap between requests and usage is the whole game, as our guide to finding and eliminating idle Kubernetes resources sets out.
A Step-by-Step Method
1. Inventory and classify before you measure
Know what every candidate resource is, who owns it, what it is for, and how critical it is. A resource with no owner is not a rightsizing candidate; it is an idle-resource candidate. A resource that is critical gets a more conservative step and a longer observation window. This classification is what a Cloud CMDB provides, and without it every subsequent step is slower and riskier.
2. Measure across the full cycle
Collect the metrics in the table above for at least four weeks, and eight where seasonality matters. Use p95 or p99 for anything that affects users, not averages. For databases, lead with query latency; for Kubernetes, lead with requests against actual usage per container.
3. Decide the step, not the target
Choose the next size down that leaves headroom above measured peak on every metric, not the smallest size that fits the average. One step at a time; a second step after the first proves stable is cheaper than a rollback.
4. Change in a window with a rollback ready
Schedule the change, snapshot or record the prior configuration, and have the reversal scripted. For stateless fleets, roll a subset first. For databases, use read replicas or blue-green where available.
5. Watch application metrics for a full cycle
Utilization will look fine; the question is whether latency, error rates, and queue depths changed. Keep the rollback ready until the resource has been through its real peak.
6. Record the result and move to the next step
Log the saving, the metrics before and after, and whether a further step is warranted. Rightsizing is a continuous practice, not a project, because new resources are provisioned oversized every week.
7. Only then, commit
With the estate settled at its real size, measure the stable baseline and buy commitments against that. Committing before rightsizing locks the waste in; our guides to Reserved Instances, Savings Plans, and Spot and how commitment discounts are sized and managed start from that assumption.
Before and After: Four Worked Examples
US list prices as of October 2026, monthly, always-on. Each example shows what the console would recommend, what the safe step was, and why they differ.
| Resource | Observed usage | Console recommendation | Safe step taken | Before | After | Saving |
|---|---|---|---|---|---|---|
| AWS m6i.2xlarge app server (8 vCPU, 32 GB) | CPU avg 12%, p95 38%; memory peak 19 GB; month-end spikes | m6i.large (2 vCPU, 8 GB) | m6i.xlarge (4 vCPU, 16 GB): memory peak needs headroom the recommendation ignores | $280 | $140 | $140 (50%) |
| Azure E8s v5 reporting DB (8 vCPU, 64 GB) | CPU avg 9%; memory peak 44 GB; query p95 stable | E4s v5 (4 vCPU, 32 GB) | Keep E8s v5: 44 GB memory peak would not fit; move to reservation instead | $368 | $368 (then reserved ~$150) | $0 from rightsizing; $218 from commitment |
| GCP n2-standard-16 batch node (16 vCPU, 64 GB) | CPU p95 71% for 3 hours nightly, idle otherwise | n2-standard-8 | n2-standard-8 on a schedule (runs 4 hours a day) | $560 | $47 | $513 (92%) |
| Kubernetes deployment, 12 pods | Requests 2 vCPU / 4 GB each; usage p95 0.4 vCPU / 1.1 GB | Set requests to 0.5 / 1.5 | Requests 0.75 vCPU / 2 GB: headroom for the p99 the p95 hides | ~$1,050 of node capacity | ~$395 | ~$655 (62%) |
Three of the four examples differ from the console recommendation, and in each case the difference is a metric the console did not use: memory peak, query latency, and the gap between p95 and p99. The second example is the honest one: the right answer was not to rightsize at all, because memory would not fit, and the saving came from a commitment instead. A recommendation engine that weighs purpose and criticality, and reads memory and query time rather than CPU alone, would have proposed the safe step in all four cases. For how each platform's sizes and prices line up, see our guides to
Azure virtual machine costs, what an AWS server really costs, and EC2 instance types.
Why the Cloud CMDB Makes Rightsizing Safe
Every step in the method above depends on knowing three things about a resource that no utilization graph contains: who owns it, what it is for, and what happened to it before. A Cloud CMDB, a live inventory of every resource across every cloud with owner, purpose, cost, compliance status, and a change history, is the system that holds those facts, and it changes rightsizing in four ways.
- Criticality shapes the recommendation. A payment service and a test box with identical utilization get different advice: a conservative step and a long watch for one, an aggressive step for the other. Without purpose and criticality, every recommendation has to be the cautious kind, and most go unactioned.
- Ownership makes the change happen. A recommendation with an owner becomes a ticket; one without becomes a backlog. The CMDB is where ownership lives, and where resources without an owner are flagged before anyone considers shrinking them.
- Change history makes rollback precise. When a downsized resource misbehaves, the question is what it looked like before. A timeline of changes answers it immediately and also catches the opposite case: a resource that was upsized during an incident and never returned.
- Cost on every resource turns findings into priorities. A thousand candidates sorted by saving, with the cost attached to each, is a plan. The same thousand as a flat list is a chore.
How Opslyft Does This
Opslyft's Atlas is built as the Cloud CMDB described above. It keeps one live inventory of every resource across every connected cloud, AWS, Azure, GCP, OCI, Kubernetes, and Snowflake, with an owner and a cost on each, tracks ownership and compliance in real time so nothing runs without an owner, and keeps a change history so any cost movement can be traced back to the change that caused it. On that foundation, its optimization recommendations weigh each workload's purpose and criticality rather than utilization alone, and draw on workload metrics such as memory, storage, and query time so that engineers can act on them with confidence: the second worked example above, where memory would not fit, is the kind of recommendation Atlas would not make, and the third, a schedule rather than a shrink, is the kind it would. Rightsizing resources and removing idle infrastructure without hurting performance is the stated goal, not a side effect.
The rest of the platform closes the loop the method requires. Tickets turns each recommendation into an assigned ticket pushed to Jira, ServiceNow, or Asana, tracked from detection to fix with the saving it delivered, so step six of the method, record the result, happens automatically. Monitor watches for anomalies after a change with a root-cause explanation, so a downsize that causes a cost or behavior spike surfaces in the owner's Slack channel with the reason attached. Explorer shows the before-and-after by team, service, or namespace, and Canvas puts the rightsizing program's savings on one screen that engineering and finance both read. And Iris answers the question every rightsizing program eventually gets asked, which teams still have the most oversized capacity and why, in plain English.
Proof: Purplle, $200,000 saved on GCP in one month
Purplle, India's largest online beauty and wellness store serving 4 million customers, moved its GCP operations from reactive firefighting to automated cost governance with Opslyft. Within minutes of integration, idle and underutilized resources were surfaced with their cost impact: unattached disks, low-CPU VMs, and unused compute clusters. The result was more than $200,000 saved in a single month, with zero engineering bandwidth spent finding the waste. Read the full story: Purplle saves $200K on GCP in one month.
Common Rightsizing Mistakes
- Shrinking on CPU alone, then discovering memory was the constraint.
- Using a 14-day window and meeting the quarter-end peak in production.
- Jumping to the recommended minimum instead of stepping down one size.
- Rightsizing a resource nobody owns, so nobody notices when it breaks.
- Buying commitments first and stranding them when the estate shrinks.
- Treating it as a one-off project; new oversized resources arrive every week.
- Rightsizing Kubernetes nodes without fixing pod requests, which simply moves the waste.
The Bottom Line
Rightsizing is the largest usage-side saving in most cloud estates and the one most often left on the table, because the recommendations are cheap and the confidence to act on them is not. The confidence comes from measuring the right metrics over the right window, knowing what each resource is for and who owns it, stepping down one size at a time with a rollback ready, and watching the application rather than the utilization graph afterward. At the scale of one server that is discipline; at the scale of an estate it is a system, a live inventory that carries owner, purpose, criticality, cost, and history for everything you run, and that is what makes recommendations trustworthy enough to become tickets that close. That system is what Opslyft's cost control is built around. Bring a month of your bill and an oversized fleet, and see which candidates are safe.
FAQs
Rightsizing is matching each cloud resource's size, instance type, disk, database tier, or container request, to what its workload actually uses, rather than what someone guessed it would need when it was created. Most estates run compute at 20 to 40 percent average utilization, so rightsizing typically cuts the cost of affected resources by 30 to 50 percent. Done carelessly it also causes outages, which is why the method matters as much as the recommendation.
Measure more than CPU: memory, disk I/O, network, and for databases query latency, over at least two to four weeks including peaks. Know what the resource is for and how critical it is before changing it, step down one size at a time rather than to the recommended minimum, change in a maintenance window with a rollback ready, and watch application metrics, not only utilization, for a full cycle after. Treat the recommendation as a hypothesis to test, not an instruction.
Three reasons. They are based on utilization alone, usually CPU over 14 days, so they miss memory pressure, bursty peaks, and workloads sized for latency rather than throughput. They do not know what the resource is for, so a recommendation to shrink a payment service looks identical to one for a test box. And they land in a console nobody owns, so no one is accountable for acting. Recommendations that weigh purpose and criticality, use richer metrics, and arrive as a ticket with an owner get acted on.
A Cloud CMDB (configuration management database) is a live inventory of every resource across every cloud, with its owner, purpose, cost, and a history of changes. It makes rightsizing safe because it answers the questions a utilization number cannot: who owns this, what is it for, how critical is it, and what changed last time someone touched it. Opslyft's Atlas is built as this inventory, which is why its recommendations can weigh criticality and why a rollback can be traced to the exact prior configuration.
On the resources it touches, commonly 30 to 50 percent, since stepping an instance down one size roughly halves its compute cost and most over-provisioned resources are at least one size too large. Across a whole estate the figure is lower because not everything is oversized, but rightsizing combined with idle-resource removal is usually the largest usage-side saving available, ahead of commitments. Purplle saved more than $200,000 on GCP in a single month largely from idle and underutilized resources surfaced automatically.
Before, always. A commitment locks in the size of what you commit to; rightsizing afterward strands part of the commitment. Rightsize, let the estate settle for a few weeks, then measure the stable baseline and commit to that. Teams that commit first routinely find a third of their commitment covering capacity they no longer need.
It applies everywhere a resource is sized. In Kubernetes, rightsizing means setting container CPU and memory requests to actual usage, because requests reserve capacity whether used or not and are the largest source of cluster waste. For managed databases it means instance class, storage, and provisioned IOPS, judged by query latency rather than CPU. For storage it means volume size and tier. Each needs its own metrics, which is why a single CPU-based recommendation engine is insufficient.