Somebody picked an instance size during a launch week, when the safe choice was “bigger than we think we need”. The launch ended, the traffic settled, and the instance kept its size. It still does. That unglamorous gap between what a server is and what it needs is what rightsizing is for.
What rightsizing means
Rightsizing is changing a cloud resource’s configuration to match what the workload actually uses. That covers instance type, number of CPUs, memory, storage tier, databases and more. The target is not “smaller”. The target is “no larger than the job requires, with some headroom”.
The FinOps Foundation places it under usage optimisation, and describes the typical candidate this way: “Resources that cannot be scaled but which have consistently low utilization may be candidates for rightsizing.” The qualifier matters. A resource that scales up and down with demand already sizes itself. The ones to look at are fixed-size resources that sit mostly idle: the database that was provisioned for a peak that never came, the build server nobody revisited.
How cloud tools find oversized resources
Each major cloud ships a tool that reads your usage history and proposes a different size. They work on the same principle with different details.
AWS Compute Optimizer analyses the specifications and the CloudWatch utilisation metrics of your resources for the last 14 days by default. For EC2 that includes CPU, network and disk. If you turn on its paid enhanced infrastructure metrics preference, the lookback extends to 93 days. It uses the maximum utilisation point within each five-minute interval, which keeps one busy minute from being averaged away.
AWS Cost Explorer has its own rightsizing recommendations for EC2, which identify opportunities by “downsizing or terminating instances”. AWS now recommends Cost Optimization Hub as the place to look for these opportunities.
Azure Advisor recommends either shutting down or resizing a virtual machine. It analyses seven days by default, and you can change the lookback to 7, 14, 21, 30, 60 or 90 days. For a resize, it aims for a cheaper size on which the workload still fits: for user-facing workloads, P95 of CPU and outbound network at 40% or lower and P99 of memory at 60% or lower on the new size; for non user-facing workloads, 80% or lower on each.
The numbers are worth reading, because they show the shape of a sound rule: a percentile of the busy period, not the average, with a ceiling well under 100%.
What the tools can’t see
Recommendations are a starting list. Four gaps come up in the vendors’ own documentation.
- Memory may be invisible. AWS Compute Optimizer analyses memory only for EC2 instances that have the CloudWatch agent installed, or that feed it metrics from supported observability products. Without one, a recommendation is built without that evidence. Azure Advisor’s shutdown rule ignores memory by design.
- A short window misses long cycles. The FinOps Foundation advises checking for longer-cycle peaks, such as month-end, before downsizing. A 14-day window taken mid-month will not see a month-end batch run.
- Purpose isn’t in the metrics. Azure lists cases where a recommendation shouldn’t be adopted: capacity provisioned for upcoming traffic, a machine kept for disaster recovery, a box under specific testing, or a need to keep sizes uniform.
- Savings can be overstated. Azure says its figures use retail rates and ignore reservations and savings plans, so some changes could raise your costs.
Rightsizing is not free of risk
The FinOps Foundation is direct: “Rightsizing typically requires recreating or reconfiguring resources, which can involve service disruptions.” It also tells you to coordinate with engineering and to take care with resources that have warranty, contractual or software performance requirements.
That is why rightsizing is a conversation between the person who sees the bill and the person who owns the workload, not a script run by finance. A saving of a few hundred ringgit a month is not worth an outage on a payroll database. Estimate the saving and the effort before you touch anything. Both belong in the ticket.
- Misses memory pressure
- Misses month-end peaks
- Ignores why it was sized up
- CPU, memory and network
- A window that spans a full cycle
- Owner confirms purpose
- Test, then resize
A short checklist before you resize
- Memory is being collected for the instance (agent installed), not just CPU.
- The lookback window covers a full business cycle, including month-end.
- The owning team has confirmed the resource isn’t sized for a known upcoming event, or for disaster recovery.
- Reserved Instances or Savings Plans covering the old size have been checked. Our piece on Reserved Instances or Savings Plans explains why you should resize before you commit.
- The change is tried in a non-production copy first, in a planned window, with a way back.
- The expected saving and the effort are written down, so you can tell afterwards whether it worked.
How often to do it
Once is a project; the FinOps Foundation’s approach at higher maturity is to automate the implementation of recommendations with minimal manual intervention. Most teams are not there yet. A monthly review of the top recommendations, owned by the team that runs the workload, is a sensible rhythm: new instances get launched oversized all the time, and last quarter’s savings erode quietly.
Where Auris fits
If your cloud bill has grown faster than anyone can explain, a rightsizing review is usually one of the first things a FinOps practitioner will propose, alongside tagging and commitment planning. Auris works with certified FinOps practitioners who run that kind of review for a company’s cloud estate. The FinOps page explains how an engagement works.
The bottom line
Rightsizing is matching what you pay for to what the workload uses, one resource at a time. The cloud tools will give you a list; your job is to check memory, peaks and purpose before you act on it, and to resize before you buy commitments.