Rightsizing
Rightsizing is changing a cloud resource to the smallest size or type that still meets its workload's real needs, based on measured CPU, memory, storage and network use. It's one of the largest usage savings in FinOps, and it should come before buying commitments, so you don't commit to capacity you don't need.
In plain English
Think of driving a seven-seater to work alone every day. Rightsizing is noticing the empty seats and switching to a car that fits the trip, while keeping enough room for the weekend when the family comes along.
Formula and worked example
Rightsizing saving = current cost − cost at the recommended size
- Current cost
- = what the resource costs now, at its current size
- Cost at the recommended size
- = what the smallest size that fits peak use, plus headroom, would cost
| 10 instances at the current size, on demand | $3,000 a month |
|---|---|
| Peak CPU over 14 days | 28% |
| Peak memory over 14 days | 35% |
| 10 instances one size smaller: half the vCPU, memory and price | $1,500 a month |
| Rightsizing saving | $1,500 a month |
At the smaller size the same peaks run at about 56% CPU and 70% memory, which still leaves headroom. That $1,500 is part of the cloud waste Northwind Labs found in March.
Why rightsizing matters
Most resources are sized once, at launch, for a guess at peak load, and never looked at again. Rightsizing replaces the guess with measured use, and because a smaller size costs less every hour it runs, the saving repeats every month.
It also has to come first. Savings Plans, Reserved Instances and committed use discounts lock in a level of spend for one or three years, so rightsize before you commit, or you'll be committing to the waste.
Common mistakes
- Looking at CPU alone. Memory is often the real limit, and AWS Compute Optimizer only sees an EC2 instance's memory if the CloudWatch agent reports it. A size that fits the CPU can still run out of memory.
- Sizing for the average. A 10% average can hide a daily spike to 90%. Size for the peak plus headroom, over a period long enough to include your busiest days.
- Committing first. Rightsizing after buying a commitment leaves part of the commitment unused. Rightsize, then commit to the smaller baseline.
- Treating it as a one-off. Workloads change with every release. Review recommendations on a schedule, and consider a newer instance generation while you are there.
Where to find it in AWS, Azure and Google Cloud
| Cloud | What it is called | Where to find it |
|---|---|---|
 AWS | AWS Compute Optimizer | Recommends sizes for EC2 instances, Auto Scaling groups, EBS volumes, Lambda functions, ECS services on Fargate and RDS databases from the last 14 days of CloudWatch metrics, or up to 93 days with enhanced infrastructure metrics. EC2 memory needs the CloudWatch agent. Cost Optimization Hub collects the results across accounts. |
 Azure | Azure Advisor | Cost recommendations resize or shut down underused VMs and scale sets. Advisor looks at the last 7 days by default, which you can extend to 14, 21, 30, 60 or 90 days, against a CPU threshold you set per subscription. |
 Google Cloud | Machine type recommendations | Recommender suggests a machine type for each VM from the last 8 days of CPU and memory use in Cloud Monitoring, smaller or larger. With the Ops Agent installed, it uses the agent's more accurate memory data. |
How CloudYali helps
CloudYali Cost Savings brings rightsizing recommendations from AWS Cost Optimization Hub and Google Recommender together with its own checks on AWS, Azure and Google Cloud, prices each one per month, and tracks it to Implemented with the savings it recorded.
Related terms
Optimization
Idle resources
Idle resources are cloud resources you still pay for that do no useful work: instances with almost no CPU or network traffic, unattached disks, unused IP addresses, and snapshots or load balancers nobody uses. They are the simplest cloud waste to remove, because stopping or deleting them usually changes nothing for users.
Optimization
Cloud waste
Cloud waste is cloud spend that buys nothing the business needs: idle resources, over-provisioned resources and commitments paid for but not used. It's measured in money rather than resources, and removing it lowers the bill without changing what users get, which is why cost optimization usually starts there.
Commitments & rates
Savings Plan (SP)
A Savings Plan is an AWS or Azure commitment to spend a fixed amount per hour on eligible compute for one or three years. Usage up to that amount is billed at lower rates, and the discount follows your usage across instance sizes and, with the most flexible plans, instance families and regions.
Commitments & rates
Commitment utilization
Commitment utilization is the share of a commitment you paid for that your usage actually consumed: used commitment ÷ total commitment. Anything below 100% is commitment you paid for and didn't use, so it shows how well a Reserved Instance, Savings Plan, Azure reservation or committed use discount fits real usage.
Optimization
Spot instances
Spot instances are spare cloud capacity sold at a steep discount, up to 90% off on-demand prices on AWS and Azure and up to 91% on Google Cloud, which the provider can reclaim at short notice. They suit work that can stop and restart, such as batch jobs, CI pipelines and stateless services.
Billing & cost types
On-demand price
On-demand price is the public, pay-as-you-go price for cloud usage with no commitment: you pay per second, hour, gigabyte or request for what you use. It is the baseline that every commitment discount, and metrics such as coverage and effective savings rate, are measured against.
Frequently asked questions
Should I rightsize before buying Savings Plans or Reserved Instances?
Yes. A commitment locks in a level of spend for one or three years. Rightsize first, so the commitment matches what you'll actually run, then commit to the smaller baseline.
Is rightsizing only about making things smaller?
No. A resource that regularly runs hot should move up a size or to a different type. Rightsizing means matching the resource to its workload, in either direction.
Does rightsizing need downtime?
Often. Changing a VM's size on AWS, Azure or Google Cloud usually means stopping or restarting it, so plan the change with the team that owns the workload.
