An engineering manager showed me a report from Azure Advisor listing 340 virtual machines flagged as underutilised, with an annualised saving of 1.2 million US dollars sitting at the top of the page. He wanted to know why nobody had actioned it in eight months. The answer was in row 12: a SQL Server instance running the month end close, averaging 4 percent CPU for 27 days and pinned at 90 percent for three. Somebody had tried to resize it the previous year, during the flat period, and finance had lost two days.

After that, the list became untouchable. One bad change had made 1.2 million US dollars of genuine opportunity politically radioactive, because the organisation had no way to tell the safe rows from the dangerous ones. That is the real problem with rightsizing. Finding the waste is trivial and the cloud providers will do it for free. Knowing which of those findings you can act on without an incident is the entire job.

What rightsizing actually changes on the bill

The FinOps Foundation defines rightsizing as taking measurements over time to assess what a workload periodically requires, then matching it to a resource sized to run it efficiently with minimum waste. Note the word periodically. Rightsizing is not about the average, it is about the shape of demand across a full cycle, and almost every failure in this discipline comes from someone optimising for the average and discovering the peak.

It helps to separate rightsizing from the two levers it gets confused with. Rate optimisation, covered in Part 12, changes the price you pay per unit through commitments and discounts. Elasticity changes how many units run at a given moment through autoscaling and scheduling. Rightsizing changes the size of each unit. All three multiply together, which is why the order you apply them in matters more than most teams realise, and I will come back to that at the end because getting it backwards is expensive.

There is also a sibling capability worth naming now: idle resource removal. An instance running at 2 percent CPU with no network traffic is not a rightsizing candidate, it is a deletion candidate, and mixing the two on one list slows both down. Google Cloud draws this line explicitly in its tooling, with a separate idle VM recommender from the machine type recommender. Split your list the same way. Deletions need a different conversation and a different approval, and they are usually the faster win.

Why the three clouds disagree about the same virtual machine

Practitioners running more than one cloud notice quickly that identical workloads get very different advice depending on where they run. This is not a quality difference. The engines are answering different questions with different inputs, and once you know what each one measures, the disagreement stops being mysterious and starts being useful.

AWS Compute Optimizer sorts every instance into one of three findings: Under-provisioned, meaning at least one dimension such as CPU, memory or network fails to meet the workload requirement; Optimized, meaning all dimensions meet requirements without excess; and Over-provisioned, meaning at least one dimension could be sized down while nothing is under-provisioned. That third definition is stricter than most people assume. An instance with idle CPU and saturated network will not be flagged as over-provisioned, which is correct behaviour and catches teams who expected a bigger list.

Verified against AWS, Microsoft and Google documentation in July 2026. Azure classifies a VM as low utilisation at 5 percent CPU or less with 7 MB or less outbound network across four or more days, and samples metrics every 30 seconds before aggregating to 30 minute maxima. Defaults change, so confirm in your own console before setting policy.

flowchart TD
  A[Recommendation appears on the list] --> B{Any traffic or CPU at all}
  B -->|None for 14 days| C[Route to the deletion queue, not here]
  B -->|Some| D{Does the workload have a monthly cycle}
  D -->|Yes| E[Extend lookback to 90 days before judging]
  D -->|No| F{Is the app memory bound}
  E --> F
  F -->|Yes and no memory metric| G[Install the agent, wait, revisit]
  F -->|No or metric present| H{Is it stateless and replaceable}
  H -->|Yes| I[Batch it into the next change window]
  H -->|No| J[Schedule singly with the owner and a rollback]
  I --> K[Resize, then watch for one full cycle]
  J --> K

The memory blind spot

This is the single most common way a rightsizing programme causes an outage, and it comes directly from a documented limitation rather than anything subtle. Hypervisors cannot see inside a guest operating system, so memory utilisation is not available to the cloud platform by default. AWS states plainly that memory utilisation is analysed only for resources with the unified CloudWatch agent installed. Azure Advisor goes further and does not consider memory at all for its resize recommendations, reasoning that CPU and outbound network are sufficient signals.

For a stateless web tier that reasoning holds. For a JVM application with a 24 GB heap, a Redis cache, an in memory analytics engine or a database, it is exactly wrong. These workloads sit at low single digit CPU precisely because they are waiting on memory or disk, and they are the ones the recommendation engine flags most enthusiastically. The pattern is consistent enough to state as a rule: the louder a CPU based recommendation shouts about a memory bound workload, the more dangerous it is.

The fix is unglamorous. Install the agent, or export the equivalent metric from whatever monitoring you already run, and wait a full lookback period before trusting any recommendation on a stateful workload. Teams skip this because it delays the savings by a month. That month is the cheapest insurance in the whole practice, and I have never regretted spending it.

How long should you look back

Every default lookback window on every major cloud is shorter than a calendar month. AWS defaults to 14 days, Google generates machine type recommendations from the previous 8 days of Cloud Monitoring data, and Azure looks at 7 days unless you change it. Meanwhile the FinOps Foundation guidance for rightsizing virtual machines points at a 30 to 90 day lookback and explicit collaboration with application owners before anything is reconfigured.

That gap is not an oversight by the vendors. A short window produces fresher, more responsive recommendations, which is the right default for a fleet of stateless services that change weekly. It is the wrong default for anything tied to a business rhythm: payroll, month end close, invoicing, regulatory reporting, retail peak. The chart below is the report from the opening story, and it shows why the SQL Server row was a trap rather than a saving.

The practical setting I use is a 90 day window for anything stateful or finance adjacent, and the shorter default for stateless services that get redeployed constantly and where a mistake is one deploy away from being reversed. Then judge on the 95th percentile rather than the average, meaning the level below which utilisation sits 95 percent of the time. The average tells you what the machine usually does. The 95th percentile tells you what it needs to survive, and the size has to be chosen for the second number.

Leave headroom above that figure. AWS makes this configurable with memory headroom options of 30, 20 or 10 percent and a default of 20, which is a reasonable starting point for most workloads. Below 10 percent you are trading real risk for a small saving on a single instance, and the arithmetic on that trade is rarely worth it once you price in one incident.

What the savings actually look like

Rightsizing on a modern instance family usually halves cost per step down, because sizes double as you go up. That makes the arithmetic pleasant and the risk concentrated: one step is a 50 percent saving, two steps is 75 percent, and the second step is where people get hurt. The table below is a representative first batch from a mid sized estate.

Illustrative figures sized to realistic proportions rather than quoted from a live price list. Note the fourth row: the recommendation engine flagged the cache tier hardest and it was the one row that had to be left alone. Rejecting a recommendation with a written reason is a result, not a failure.

Making the change without a war room

Rightsizing on the major clouds means stopping the instance, changing the type and starting it again, so the change carries downtime unless the workload sits behind a load balancer with more than one node. Stateless services, meaning services that hold no session or data locally, can be replaced one node at a time with no customer impact at all. Stateful ones cannot, and the difference decides how you schedule.

The Foundation is explicit that this is a collaborative capability: review recommendations, verify with application owners and engineers that the change will not affect performance or violate a vendor requirement, secure buy in, then coordinate execution with performance testing before the new configuration goes live. That last clause about vendor requirements catches people. Plenty of commercial software is licensed per core or has a supported minimum specification, and downsizing can quietly put you out of compliance or out of support while saving 200 US dollars a month.

sequenceDiagram
  participant F as FinOps
  participant O as App owner
  participant E as Platform engineer
  F-->>O: Send batch with p95 and headroom shown
  O-->>F: Confirm or reject each row with a reason
  F-->>E: Raise change for approved rows only
  E-->>E: Resize in non production first
  E-->>E: Resize one production node, hold 24 hours
  E-->>O: Report latency and error rate
  O-->>E: Approve the rest of the batch
  E-->>F: Confirm completion and new run rate
  F-->>F: Watch one full business cycle before closing

Rightsize before you commit

Sequencing matters more than any individual technique here, and the FinOps community has argued about it for years under the heading of whether to optimise usage or rates first. My answer is not balanced, because the arithmetic is not balanced. Rightsize first, then commit.

Consider the reporting database line from the table. Commit to three years of the current r6i.4xlarge footprint at a 40 percent discount and you pay 1,920 US dollars a month for 36 months, feeling pleased. Rightsize first and commit to the smaller footprint at the same discount and you pay 960 US dollars. The commitment discount was identical in both cases. The difference is that in the first version you signed a three year contract to keep paying for capacity nobody was using, and you cannot rightsize your way out of it afterwards because the commitment is already sunk.

The counterargument is that rightsizing takes months of negotiation with application teams while a commitment can be bought this afternoon, and organisations under pressure to show a number reach for the fast lever. If that is your situation, buy a shorter or more flexible commitment covering only the baseline you are confident will survive rightsizing, and revisit once the estate has settled. What you must not do is commit to the full current footprint because it is easier, and then discover the rightsizing programme has nothing left to save. Commitments are covered properly in Part 12.

Start with 20 stateless instances and a 90 day window

Here is the recommendation for this part, stated plainly. Turn on the native recommender for your primary cloud, set the lookback to the longest window available, and install the memory agent everywhere before you look at a single row. Then filter the output hard: take only stateless workloads behind a load balancer, only over-provisioned findings, only one step down, and cap the first batch at 20 instances. Split anything genuinely idle into a separate deletion list and run that in parallel, because it is faster and it needs different approvals.

Run that batch through one change window, hold a single production node for 24 hours before doing the rest, and publish the before and after run rate. The point of the first batch is not the money, it is proving to application owners that a rightsizing request from you is a safe thing to say yes to. Once that reputation exists, the stateful workloads and the second step down become conversations you can actually have. Without it, you get the 1.2 million US dollar report that sits untouched for eight months.

Part 12 moves from changing the size of what you run to changing the price you pay for it, covering reserved instances, savings plans and committed use discounts, which is the lever that compounds on top of everything you have just resized. The visibility this depends on was built in Part 7, the efficiency measures that prove it worked came from Part 10, and every part so far is indexed on the Cloud FinOps guide.

One thing to do this week: open your cloud recommender, sort by estimated saving, and check whether the top row is memory bound. If you cannot tell from the console, you have found the first thing to fix.

References

• Get EC2 instance recommendations from Compute Optimizer, AWS documentation
• Rightsizing recommendation preferences, AWS Compute Optimizer user guide
• Optimize VM or VMSS spend by resizing or shutting down underutilized instances, Azure Advisor
• Apply machine type recommendations to VM instances, Google Compute Engine documentation
• Usage Optimization capability, FinOps Framework, FinOps Foundation

Instance types, monetary figures and utilisation percentages in the tables and charts are illustrative and sized to realistic proportions rather than quoted from a live price list. Lookback windows, finding classifications, headroom options and utilisation thresholds were verified against vendor documentation in July 2026 and change over time.

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts