Cloud Rightsizing: Stop Overpaying for VMs

Why it exists

Cloud providers make it easy to provision powerful resources, but it's just as easy to over-provision and waste money on idle capacity. Rightsizing exists to systematically correct this overspending by aligning resource capacity with actual application needs, ensuring you only pay for what you truly use.

The mental model

Think of rightsizing like choosing the right size moving truck. You wouldn't rent a semi-trailer to move a studio apartment's contents. Similarly, you shouldn't run a small application on a massive virtual machine. Rightsizing is the process of checking your VM against its workload and swapping it for a more appropriate, cheaper model if it's too big.

How it works

The process is a collaboration. First, a FinOps practitioner uses a tool like Azure Advisor to identify underutilized VMs by analyzing CPU and memory metrics over a 30-to-90-day lookback period. Second, these findings are presented to the application owners and engineers. This is a crucial checkpoint to discuss the workload's performance profile, including any periodic spikes or special vendor requirements. Third, after getting buy-in, the team coordinates the resize, ideally testing the new configuration in a non-production environment first. Finally, the team reports on the cost savings and continues to monitor performance.

When to use it

Apply rightsizing continuously for any long-running virtual machines, especially in development and staging environments which are often over-provisioned. It's a core practice for managing cloud costs, particularly for stable workloads with predictable usage patterns where historical data is a reliable predictor of future needs.

When not to use it

Avoid rightsizing without sufficient data; a short lookback period might miss quarterly or monthly peaks. Do not resize mission-critical applications without thorough performance testing and a rollback plan. Be cautious with workloads that have very spiky, unpredictable traffic, as average utilization metrics can be misleading and lead to performance bottlenecks. Also, do not resize if it violates a software vendor's specific hardware requirements.

One canonical example

A FinOps analyst sees a VM with an average CPU utilization of 5% over the last 90 days. They propose downsizing it from a Standard_D8s_v3 (8 vCPUs) to a Standard_D2s_v3 (2 vCPUs). They present this data to the app owner, who confirms the service only runs intensive jobs overnight. After a successful test, they apply the change, reducing the VM's cost by about 75% without impacting performance.