Azure Virtual Machines & Scale Sets

Configuring Azure Virtual Machines and VM Scale Sets well is less about the portal wizard and more about three decisions you make once and live with forever: how the instances are placed, how they grow and shrink, and how you know when something is wrong.

High availability architecture

Distribute instances across availability zones rather than pinning them to a single one. Azure gives three zones per region, each with independent power, cooling and networking, and a zone-redundant placement gets you to the 99.99% SLA.

The important property of VM Scale Sets here is that they rebalance automatically. If a zone goes away, the set works back toward its desired capacity in the surviving zones without you scripting anything.

Auto-scaling that doesn’t thrash

Scale out on sustained pressure, not on spikes. A workable default pair:

• Scale out when average CPU is above 70% for 5 minutes.
• Scale in when it drops below 30% for 10 minutes.

The asymmetry is deliberate — you want to add capacity quickly and remove it slowly, because a premature scale-in during a lull costs you a cold start right when traffic returns. Where the workload is predictable, predictive autoscaling ahead of the historical curve removes most of the latency at the start of a spike.

Cost

• Reserved Instances for the predictable baseline, up to ~72% off pay-as-you-go.
• Spot VMs for interruptible work, up to ~90% off, accepting eviction when Azure needs the capacity back.
• Automatic shutdown schedules for non-production. This is usually the single largest saving available in a dev/test subscription.

Monitoring

Azure Monitor for the platform metrics — CPU, memory, disk I/O, network — with alerts on thresholds that actually mean something, and Log Analytics as the single query surface for logs across the fleet. An alert that fires without a documented first action is noise, so each one gets a runbook link before it goes live.