Lesson 10 — VM Scale Sets, Azure Bastion & JIT Access

Why This Lesson Completes the Compute Domain

Lesson 09 covered individual VM configuration. This lesson covers the three capabilities that matter most once you have VMs running in production: scaling them (VM Scale Sets), accessing them securely without exposing attack surface (Azure Bastion), and controlling emergency access to management ports (Just-In-Time VM Access). Together, these are the difference between a VM deployment that works and one that is production-grade.

On AZ-104, VMSS questions focus on orchestration modes and autoscale policies. Bastion questions focus on subnet requirements and SKU differences. JIT questions focus on the NSG mechanics. All three are regularly tested in scenario-based questions — know the operational details, not just the names.

VM Scale Sets — Overview

A VM Scale Set (VMSS) is an Azure resource that lets you deploy and manage a group of load-balanced VMs as a single unit. Scale sets solve the problem of manual fleet management: instead of deploying individual VMs, configuring them, and wiring them to a load balancer manually, a scale set handles instance provisioning, configuration, distribution across fault domains and availability zones, health monitoring, and autoscaling as a first-class feature.

• All instances in a scale set are created from the same base image and configuration (Uniform mode) or from a model with per-instance overrides (Flexible mode).
• Scale sets integrate natively with Azure Load Balancer (Layer 4) and Application Gateway (Layer 7) backend pools.
• Scale sets support Availability Zones — instances can be distributed across zones for high availability with no extra configuration.

Orchestration Modes: Uniform vs. Flexible

This is one of the most commonly tested VMSS topics on AZ-104. The two orchestration modes represent fundamentally different philosophies.

Scaling Policies

VMSS supports four distinct scaling approaches, which can be combined in a single scale set configuration:

1. Manual Scaling

Set the instance count explicitly via the portal, CLI, or API. No automation — you directly control the fleet size. Useful for predictable workloads or initial deployment.

2. Custom Autoscale (Metric-Based)

Define scale-out and scale-in rules based on metrics. A complete autoscale profile consists of:

• Scale-out rule: When metric X exceeds threshold Y for Z minutes, add N instances.
• Scale-in rule: When metric X falls below threshold W for Z minutes, remove N instances.
• Cooldown period: A waiting period after a scaling operation before another can trigger — prevents thrashing (rapid scale-in/scale-out cycles). Typical values: 5–10 minutes.
• Min/Max bounds: Hard floor and ceiling on instance count.

3. Schedule-Based Scaling

Increase or decrease capacity on a defined schedule — for example, scale to 20 instances at 08:00 Monday–Friday and scale back to 5 at 18:00. Useful for predictable business-hours load patterns.

4. Predictive Autoscale

Predictive autoscale uses Azure Machine Learning to analyse CPU usage history and predict future demand. Instead of reacting to a metric breach, it pre-provisions capacity before the demand spike hits — eliminating the latency gap between load increase and new instance readiness that standard reactive autoscale cannot avoid.

Scale-In Policy

When a scale-in event fires, Azure must decide which VM instances to delete. The scale-in policy controls this:

• Default: Balances instance removal across Availability Zones and Fault Domains first, then deletes the VM with the highest instance ID. This is the safest option for AZ-balanced deployments.
• NewestVM: Deletes the most recently created instances first — good for immutable infrastructure patterns where newer instances are less likely to have in-flight work.
• OldestVM: Deletes the oldest instances first — good for patching workflows where older instances may be running older software versions.

Instance Protection

You can mark specific VMSS instances as protected to prevent them from being deleted during scale-in or from receiving model updates (OS upgrades, configuration changes). Useful for instances running long-running batch jobs that should not be interrupted mid-job.

Updates, Health Probes & Rolling Upgrades

Keeping a VMSS fleet updated without downtime requires understanding the upgrade mode and health probe configuration:

For zero-downtime updates, configure a health probe (via Application Health Extension or Load Balancer probe) so Azure knows whether an instance is healthy before upgrading the next batch. Automatic OS image upgrades can also be enabled to automatically replace instances with the latest OS image version on a rolling basis.

Azure Bastion

Azure Bastion solves a fundamental enterprise security problem: how do you remotely administer VMs over RDP or SSH without exposing those ports to the public internet?

The Problem Without Bastion

Traditional approaches all have serious flaws:

• Assign a public IP to the VM and open port 3389/22 in the NSG — exposes the VM directly to internet scanning and brute force attacks.
• Use a jump box VM with a public IP — you still have a publicly exposed attack surface (the jump box itself).
• Use a VPN — requires VPN infrastructure, client software distribution, and ongoing management overhead.

How Azure Bastion Works

Azure Bastion is a fully managed PaaS service that proxies RDP and SSH connections through the Azure infrastructure, entirely within Azure's backbone network:

Azure Bastion SKUs

Deployment Requirements

Azure Bastion has specific infrastructure requirements that are frequently tested:

Just-In-Time (JIT) VM Access

Just-In-Time VM Access is a feature of Microsoft Defender for Servers (Plan 1 or Plan 2 required). It solves the persistent management port exposure problem using a different mechanism than Bastion.

The Problem JIT Solves

Even with disciplined NSG management, many teams leave RDP (3389) or SSH (22) open permanently in their NSGs — because removing access means re-adding it every time someone needs to do maintenance, which creates operational friction. Permanently open management ports are a significant attack surface: every IP on the internet can attempt brute-force or vulnerability attacks against them continuously.

How JIT Works — NSG Mechanics

Bastion vs. JIT — Which to Use?

Both Azure Bastion and JIT VM Access address the same problem (secure management access) but through fundamentally different mechanisms. Understanding when to recommend each is important:

Azure Serial Console

Azure Serial Console is an emergency access mechanism that provides a text-only, browser-based terminal connected to a VM's serial port — bypassing all network connectivity entirely. It is your last resort when everything else is broken.