This guide is about cloud resources, not staff, since “rightsizing” is also used for cutting headcount. It is for IT heads, cloud and platform owners and engineers at mid-size companies in India and the GCC. They run workloads on AWS, Azure or both and already have a list of oversized resources. It sets out cloud rightsizing as a method: match each resource to what the workload really uses, in a safe order. The order is to measure, read the peaks, choose one step, check with the owner, test, change, verify and repeat.
Last reviewed 2026-11-01 by Manish Sharma.
Cloud Rightsizing: The Short Answer
Move one resource at a time, from evidence to a verified change. The order matters more than the tool, because each step ends with something you can show. A recommendation from a tool is where the work starts, not where it ends. For how the main kinds of recommender differ, see native, multi-cloud and Kubernetes sizing tools.
Rightsizing Is Not Downsizing
Rightsizing is data-driven, so it can scale a resource up as well as down. Downsizing is cutting without utilization data. Utilization is the share of a resource’s capacity that is in use. Three things make a recommendation misleading: a short window, an average used in place of a peak, and no memory data.
If a tool recommends a smaller size, ask which window, which statistic and which dimensions it used before you act on it.
The Method in Five Steps
Five steps take a candidate to a verified change. Our cloud cost optimization checklist is the scan that finds the candidates, and this method starts when you have one. Our explainer on cloud waste shows what counts as waste and where it hides.
One resource, a named owner and a window that covers a full cycle.
Use percentiles and look beyond CPU.
One size step, confirmed by the person who knows the workload.
Staging, a controlled change, and a full cycle of watching.
Needs change, so the sizes do too.
Cloud Rightsizing, Step 1: Pick the Candidate, Owner and Window
Work on one resource at a time, with a named owner, and measure over a window that covers a full normal cycle. Include the month-end or seasonal peak.
The tools look back over a limited window by default. AWS Compute Optimizer analyzes the last 14 days of utilization by default, and enhanced infrastructure metrics, an optional feature, extend that to 93 days for selected resources. Azure Advisor defaults to the last 7 days and lets you change the look-back to 7, 14, 21, 30, 60 or 90 days (both as of November 2026, per AWS documentation and Microsoft documentation). Our explainer on rising cloud costs covers the default windows too.
A resource that looks oversized over 7 days may run a month-end batch that fills it. Choose a window that includes the busiest period.
Cloud Rightsizing, Step 2: Read Peaks and Memory, Not Averages
Use the 95th and 99th percentiles (P95 and P99) instead of the average, because they show how the resource behaves at its busiest. An instance with a low average and high P99 spikes is not a safe candidate, since the average hides the spikes that cause failures.
Check memory, disk and network as well as CPU, and for some workloads GPU. CPU alone is not enough. Azure Advisor’s shutdown recommendation does not consider memory, while its resize recommendation does. AWS Compute Optimizer can take in outside memory metrics from observability products when the platform does not report memory itself.
The percentages inside the tools are settings, not rules. As of November 2026, Azure Advisor’s page gives targets for a recommended size: P95 CPU and outbound network at 40% or lower and P99 memory at 60% or lower for user-facing workloads, and 80% for each for non-user-facing ones, measured on the recommended new size. Treat them as that tool’s settings and set your own headroom, which is the spare capacity you keep above the observed peak.
Cloud Rightsizing, Step 3: Choose One Step and Check With the Owner
Change one size step at a time, or change the family when the workload needs it. Scale up if a bottleneck costs more than spare capacity. Headroom is your decision, set from observed peaks, so do not copy a number from a guide. If users already feel a slowdown, the six causes of a slow application show whether size is the cause.
The owner confirms what the tool cannot know, such as planned launches, batch jobs, compliance limits and dependencies. Azure Advisor’s page lists cases in which to dismiss or postpone a recommendation: a machine sized for upcoming traffic, one that uses other resources, one under specific testing, one that must stay a homogeneous size, or one used for disaster recovery.
| Resource | What to read before changing | What to watch for |
|---|---|---|
| Virtual machine | P95 and P99 for CPU, memory, disk and network, because an average hides peaks | Spikes behind a low average, since they cause failures |
| Database | Memory working set, IOPS, connection limits and query latency, so you see real demand | Latency, if it rises after the change |
| Container | Requests and limits against real use, so you see the gap | Evictions and throttling, when limits are set too low |
| Storage | Access pattern and throughput, before you pick a tier | Slower reads and writes, if throughput drops |
Key Takeaway The owner, not the tool, decides whether a resource may change.
Cloud Rightsizing, Step 4: Test, Change and Verify
Test in staging, on a clone or with a canary first. Compare latency, errors, saturation and the baseline you took before. Saturation is how full the tightest resource is.
Then change through a controlled process, with the previous configuration recoverable, in a maintenance window, one node or service at a time. Keep watching for a full business cycle, not a day, and write the result next to the baseline. The precautions for removing a resource are in the warning-box of the same checklist. Our 19-check rightsizing checklist turns these steps into checks with owners and evidence.
If the change cannot be reversed quickly, test it more than you would otherwise.
Cloud Rightsizing, Step 5: Repeat on a Cadence
Workloads, traffic and available sizes change, so rightsizing is ongoing. AWS’s own right-sizing page calls it an ongoing process. Review on a cadence you set, monthly or quarterly, and keep the evidence for each change.
In our practice, rightsize before you buy any commitment, because a commitment made on an oversized baseline fixes the waste in place. Azure Advisor’s savings figures also ignore reservations and savings plans you already hold.
Cloud Rightsizing for Databases, Containers and Machines to Leave Alone
Stateful systems, container platforms and recovery machines each need extra care.
A database holds data, so a wrong change can lose it or slow every user. Check the memory working set, IOPS, connection limits and query latency against a replica or clone before you change production.
For containers, rightsize requests and limits, and watch evictions and throttling afterward. Avoid letting vertical and horizontal autoscalers work against each other. Azure Advisor recommends turning on the Vertical Pod Autoscaler’s recommendation mode to rightsize resource requests and limits, as of November 2026.
Some machines are best left alone, such as disaster-recovery copies, machines sized for a known launch and anything without an owner.
Resizing it can break the plan it exists for.
Key Takeaway For stateful, container and recovery cases, test on a copy first and keep the way back open.
Four Mistakes That Make Rightsizing Unsafe
A recommendation list is a set of candidates, not a set of instructions.
For the wider picture, see how Signisys helps you right-size cloud resources and cut waste. Our page on cloud cost optimization and FinOps adds detail. See also our cloud services and platform engineering.
FAQ: Cloud Rightsizing
What is cloud rightsizing?
How long should I measure before resizing?
Why is CPU alone not enough?
Can rightsizing mean making a resource bigger?
Should I rightsize before or after buying commitments?
How often should I rightsize?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.