Right-Sizing and Autoscaling

Right-sizing is the process of matching Azure VM or service SKUs to the actual resource requirements of your workload — neither over-provisioning (wasting money) nor under-provisioning (risking performance degradation). Most organisations initially over-provision by 30–50% out of caution when migrating from on-premises. Regular right-sizing analysis, typically monthly, can recover a significant portion of that over-spend without impacting application performance.

Use Azure Monitor metrics and VM Insights to collect CPU, memory, disk IOPS, and network throughput data over at least 30 days. Look for the peak (P95 or P99) utilisation, not the average, to ensure the right-sized VM can handle traffic spikes. Azure Advisor's right-sizing recommendation uses a 7-day lookback by default, but you can extend this to 30 or 60 days in the Advisor configuration for more representative data.

Azure VMs are organised into SKU families optimised for different workloads: D-series (general purpose), E-series (memory optimised), F-series (compute optimised), N-series (GPU), and L-series (storage optimised). If a VM's CPU usage is low but memory is high, moving from a D-series to an E-series at the same vCPU count gives more RAM at similar cost. Resizing a VM in Azure typically requires a brief restart of a few minutes.

Scheduled autoscaling is the right choice when workload patterns are predictable. A retail application that sees high traffic during business hours and near-zero traffic overnight can be configured with a scale-out schedule at 07:00 and a scale-in schedule at 22:00. Virtual Machine Scale Sets (VMSS) and App Service both support scheduled autoscale rules. This approach is simpler and more cost-predictable than metric-based autoscaling for known load patterns.

Metric-based autoscaling adds or removes instances dynamically in response to real-time metrics such as CPU percentage, HTTP request queue length, or custom metrics published via Azure Monitor. You define scale-out rules (when to add instances) and scale-in rules (when to remove instances) with cooldown periods to prevent rapid flapping. Best practice is to set a scale-out threshold lower than the scale-in threshold — for example, scale out at >70% CPU and scale in at <30% CPU — with a 5-minute cooldown.

Azure Spot VMs allow you to use unused Azure capacity at discounts of up to 90% compared to pay-as-you-go prices. The trade-off is that Azure can evict spot VMs with a 30-second notice when it needs the capacity back. This makes spot instances ideal for interruptible batch workloads like rendering, scientific computing, and data processing pipelines. VMSS supports mixing regular VMs (for a baseline) with spot VMs (for burst capacity) in the same scale set using a priority mix policy.

Azure App Service autoscaling works at the App Service Plan level — adding or removing worker instances based on rules you configure. Metric triggers available include HTTP queue length, CPU percentage, and memory percentage. The Standard tier and above support manual and autoscale; the Basic tier only supports manual scaling. For serverless workloads, consider using Azure Functions on the Consumption Plan, which scales to zero and charges only per execution, eliminating idle instance cost entirely.

Common autoscaling pitfalls: session affinity — if your app stores session state in VM memory, scaling in will lose sessions; use Redis Cache or database-backed sessions instead. Slow start-up times — if VMs or containers take 10 minutes to warm up, metric-based autoscaling cannot respond fast enough; pre-warm with scheduled scale-out before predicted peaks. Scale-in too aggressive — terminating instances while in-flight requests are processing causes errors; configure connection draining and a generous cooldown period.

Right-sizing applies to PaaS services too. Azure SQL Database on the DTU model can be downsized if the DTU percentage is consistently below 50%. The vCore model allows independent CPU and storage scaling. Azure Cache for Redis can be downsized from Premium to Standard tier if persistence and geo-replication are not needed. Azure Kubernetes Service node pools can use the Cluster Autoscaler to scale nodes in and out based on pod pending and idle states.

Right-sizing is not a one-time activity. Workloads change over time — traffic patterns shift, features are added, and user bases grow or shrink. Build a monthly right-sizing review into your FinOps process: pull Advisor recommendations, review the top 10 under-utilised VMs and over-provisioned PaaS services, and create work items for the owning teams. Track savings realised vs. recommendations generated to demonstrate FinOps ROI to leadership.

The optimal cost strategy is to right-size first, then reserve. Purchasing a Reserved VM Instance for an over-provisioned VM locks in a commitment to the wrong SKU. Right-size the VM to its correct size first, observe the new utilisation for 30 days to confirm stability, then purchase a reservation for that right-sized SKU. This two-step approach maximises the discount while avoiding wasted reserved capacity.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: right-sizing matches VM SKUs to actual workload requirements using performance metrics, scheduled and metric-based autoscaling dynamically adjust capacity to match demand, and Spot VMs offer up to 90% discounts for interruptible batch workloads. Next up we explore Azure Savings Plans and Reservations for committed workloads.