Microsoft Azure — Virtual Machines

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers virtual machines with production-ready configurations, best practices, and hands-on examples.

Azure VMs: The Foundation of IaaS

Azure Virtual Machines are the bread and butter of Infrastructure as a Service (IaaS) on Microsoft's cloud. They give you full control over the operating system, installed software, and networking. Unlike PaaS services, VMs require you to manage patching, scaling, and high availability yourself. This is both a blessing and a curse: you get flexibility, but you also inherit operational overhead. In production, the most common mistake is treating VMs like on-premises servers—spinning them up, installing everything manually, and hoping they never fail. That approach leads to configuration drift, security gaps, and painful recovery. Instead, treat VMs as cattle, not pets. Use infrastructure as code (IaC) to define every aspect: size, disk, network, and extensions. Start with a clear naming convention and tagging strategy. For example, use env:prod, app:payment, role:web to filter and manage resources at scale. Without tags, you'll drown in a sea of unnamed VMs.

#!/bin/bash
# Create a production VM with tags and managed disk
az vm create \
  --resource-group prod-rg \
  --name prod-web-001 \
  --image UbuntuLTS \
  --size Standard_D2s_v3 \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --storage-sku Premium_LRS \
  --os-disk-size-gb 128 \
  --tags env=prod app=web role=app

Choosing the Right VM Size and Series

Azure offers dozens of VM series: general-purpose (D-series), compute-optimized (F-series), memory-optimized (E-series), and more. Picking the wrong size leads to either overspending or performance bottlenecks. For production, never use the B-series burstable VMs for steady-state workloads—they rely on CPU credits and will throttle under sustained load. Instead, start with D-series for most web apps and APIs. Use E-series for in-memory caches or databases. For GPU workloads, NC or ND series. Always benchmark with your actual workload. A common trap is choosing a VM with too little memory, causing the OS to swap and kill performance. Use Azure Monitor to track memory pressure. Also consider the new generation: Dv5 and Ev5 offer better price-performance than older Dv3. For disk, always use Premium SSD for OS disks in production—Standard HDD is only for dev/test. For data disks, consider Ultra Disk for high IOPS workloads like databases.

# List available VM sizes in a region with vCPU and memory
Get-AzVMSize -Location eastus | Where-Object {$_.Name -like "Standard_D*"} | Select-Object Name, NumberOfCores, MemoryInMB | Format-Table -AutoSize

Networking: VNet, Subnets, and NSGs Done Right

Every Azure VM lives inside a Virtual Network (VNet). You must plan your IP address space carefully—don't use /16 for everything. Use /24 subnets per tier: web, app, data. Network Security Groups (NSGs) are your first line of defense. Default-deny inbound, allow only necessary ports. For production, never open SSH (22) or RDP (3389) to the internet. Use Azure Bastion or a jumpbox. Also, enable NSG flow logs to detect anomalies. Another common mistake: placing all VMs in the same subnet. If one VM is compromised, lateral movement is trivial. Use Application Security Groups (ASGs) to group VMs by role and define NSG rules based on ASGs, not IPs. This decouples security from IP addresses. For high availability, deploy VMs in an Availability Set or Availability Zone. Availability Sets protect against rack failures; Zones protect against datacenter failures. For critical workloads, use Zones.

#!/bin/bash
# Create VNet with subnets and NSG
az network vnet create \
  --resource-group prod-rg \
  --name prod-vnet \
  --address-prefix 10.0.0.0/16 \
  --subnet-name web-subnet \
  --subnet-prefix 10.0.1.0/24

az network nsg create \
  --resource-group prod-rg \
  --name web-nsg

az network nsg rule create \
  --resource-group prod-rg \
  --nsg-name web-nsg \
  --name AllowHTTPS \
  --protocol tcp \
  --priority 100 \
  --destination-port-ranges 443 \
  --access allow \
  --direction inbound \
  --source-address-prefixes Internet \
  --destination-address-prefixes VirtualNetwork

Storage: Managed Disks, Caching, and Backup

Azure Managed Disks are the default and should always be used over unmanaged disks (storage accounts). They offer better reliability, availability, and integration with availability sets. For OS disks, Premium SSD is the minimum for production. For data disks, choose based on IOPS needs: Standard SSD for general purpose, Premium SSD for high performance, Ultra Disk for extreme latency-sensitive workloads. Disk caching can significantly improve read performance: set OS disk caching to ReadWrite, data disks to ReadOnly for read-heavy workloads. But be careful—write-heavy databases should disable caching on data disks to avoid data corruption. Always enable Azure Backup for VMs. It provides application-consistent backups for Windows and file-consistent for Linux. Set a retention policy that meets your RPO/RTO. For critical data, also use Azure Site Recovery for cross-region replication. A common mistake is forgetting to back up data disks attached to a VM—backup only covers the VM by default, but you can include data disks.

# Enable Azure Backup for a VM
$vault = Get-AzRecoveryServicesVault -ResourceGroupName prod-rg -Name prod-vault
Set-AzRecoveryServicesVaultContext -Vault $vault

$policy = Get-AzRecoveryServicesBackupProtectionPolicy -Name "DailyPolicy"
Enable-AzRecoveryServicesBackupProtection `
  -ResourceGroupName prod-rg `
  -Name prod-web-001 `
  -Policy $policy

High Availability: Availability Sets vs Zones

For production, you need redundancy. Azure offers two options: Availability Sets and Availability Zones. Availability Sets distribute VMs across up to 3 fault domains (racks) and update domains (maintenance windows). They protect against hardware failures and planned maintenance within a datacenter. Availability Zones place VMs in physically separate datacenters within a region, protecting against entire datacenter failures. For most production workloads, use Availability Zones—they offer higher SLA (99.99% vs 99.95% for multi-VM in set). However, Zones incur inter-zone network latency (typically <2ms). For stateful applications like databases, you need to handle data replication yourself (e.g., SQL Always On, MongoDB replica sets). A common mistake is deploying VMs in the same zone thinking they're in different zones—always check the zone property. Also, load balancers must be zone-redundant or zone-specific. Use Azure Standard Load Balancer with zone-redundant frontend.

#!/bin/bash
# Create VMs in different availability zones
for zone in 1 2 3; do
  az vm create \
    --resource-group prod-rg \
    --name prod-web-00$zone \
    --image UbuntuLTS \
    --size Standard_D2s_v3 \
    --zone $zone \
    --vnet-name prod-vnet \
    --subnet web-subnet \
    --public-ip-address "" \
    --admin-username azureuser \
    --ssh-key-values ~/.ssh/id_rsa.pub
done

Scaling: Scale Sets and Autoscale

For stateless workloads, use Virtual Machine Scale Sets (VMSS) with autoscale. VMSS allows you to manage a group of identical VMs that can scale in/out based on metrics like CPU, memory, or custom metrics. Always use a custom image or VMSS with the latest OS image to ensure consistency. For production, configure a minimum instance count (e.g., 2) and maximum (e.g., 10). Set scale-out rules to be aggressive (e.g., CPU > 75% for 5 minutes) and scale-in rules to be conservative (e.g., CPU < 30% for 15 minutes) to avoid thrashing. Use Azure Monitor autoscale with multiple profiles for different times of day. A common mistake is not setting a scale-in policy—by default, the newest VM is removed, which may cause connection draining issues. Use the 'NewestVM' or 'OldestVM' policy based on your needs. Also, integrate with Azure Load Balancer health probes to ensure only healthy instances receive traffic.

# Create a VMSS with autoscale
$vmssConfig = New-AzVmssConfig `
  -Location eastus `
  -SkuName Standard_D2s_v3 `
  -InstanceCount 2 `
  -UpgradePolicyMode Automatic

$vmss = New-AzVmss `
  -ResourceGroupName prod-rg `
  -Name web-scale-set `
  -VirtualMachineScaleSet $vmssConfig

# Add autoscale rule
$rule = New-AzAutoscaleRule `
  -MetricName "Percentage CPU" `
  -MetricResourceId $vmss.Id `
  -Operator GreaterThan `
  -MetricStatistic Average `
  -Threshold 75 `
  -TimeGrain 00:01:00 `
  -TimeWindow 00:05:00 `
  -ScaleActionCooldown 00:05:00 `
  -ScaleActionDirection Increase `
  -ScaleActionValue 1

Add-AzAutoscaleSetting `
  -ResourceGroupName prod-rg `
  -Name web-autoscale `
  -Location eastus `
  -AutoscaleProfiles (New-AzAutoscaleProfile -Name default -DefaultCapacity 2 -MaximumCapacity 10 -MinimumCapacity 2 -Rules $rule)

Configuration Management with Extensions and Desired State

After provisioning a VM, you need to configure it—install software, apply settings, join domains. Azure VM Extensions automate this. Common extensions: Custom Script Extension (run scripts), DSC (Desired State Configuration), Chef, Puppet. For production, use Custom Script Extension to bootstrap configuration, but avoid embedding secrets in scripts. Instead, use Azure Key Vault to pull secrets at runtime. For Windows, DSC is powerful for ensuring consistent state. For Linux, use cloud-init for initial setup and then configuration management tools like Ansible or Chef. A common mistake is relying on manual SSH/RDP to configure VMs—this is error-prone and not repeatable. Always use extensions or configuration management tools. Also, extensions run as part of VM provisioning; if they fail, the VM may be in an inconsistent state. Monitor extension status and set up alerts. For scale sets, use the extensions profile to apply to all instances.

#!/bin/bash
# Install Nginx via Custom Script Extension
az vm extension set \
  --resource-group prod-rg \
  --vm-name prod-web-001 \
  --name customScript \
  --publisher Microsoft.Azure.Extensions \
  --settings '{"commandToExecute": "apt-get update && apt-get install -y nginx"}'

Monitoring and Diagnostics: Azure Monitor and Log Analytics

You can't manage what you don't measure. Enable Azure Monitor for every VM. At minimum, collect metrics like CPU, memory, disk IOPS, and network. Use Azure Monitor alerts to notify on high CPU, disk space, or VM unavailability. For deeper analysis, install the Log Analytics agent (or Azure Monitor agent) to collect logs and performance counters. Create a Log Analytics workspace and configure data sources. For production, set up alerts for common failure modes: disk space < 10%, memory > 90%, CPU > 80% for extended periods. Also enable boot diagnostics to capture serial console output—invaluable for troubleshooting boot failures. A common mistake is not setting up alerts for VM heartbeat—if a VM stops responding, you want to know immediately. Use VM Insights (previously Service Map) to visualize dependencies between VMs and processes. This helps during incident response.

# Enable Azure Monitor for VM
$vm = Get-AzVM -ResourceGroupName prod-rg -Name prod-web-001

# Enable boot diagnostics
Set-AzVMBootDiagnostic -VM $vm -Enable -ResourceGroupName prod-rg -StorageAccountName proddiag

# Install Log Analytics agent
Set-AzVMExtension -ResourceGroupName prod-rg -VMName prod-web-001 -Name "OmsAgentForLinux" `
  -Publisher "Microsoft.EnterpriseCloud.Monitoring" -ExtensionType "OmsAgentForLinux" `
  -TypeHandlerVersion "1.0" -Settings @{workspaceId = "workspace-id"} `
  -ProtectedSettings @{workspaceKey = "workspace-key"}

Security: Identity, Encryption, and Updates

Security for Azure VMs starts with identity. Use managed identities for Azure resources instead of storing credentials in VMs. This allows VMs to authenticate to Azure services without secrets. For OS-level access, use Azure AD authentication for Windows VMs (SSH key for Linux). Enable Azure Disk Encryption (ADE) for OS and data disks using Azure Key Vault. ADE uses BitLocker for Windows and DM-Crypt for Linux. For production, encrypt all disks. Also, enable just-in-time (JIT) VM access from Microsoft Defender for Cloud to reduce exposure of management ports. For patching, use Azure Update Management to schedule updates and get compliance reports. A common mistake is not applying security updates promptly—use automatic VM guest patching for Windows (available in preview) or schedule maintenance windows. Also, restrict network traffic with NSGs and use Azure Firewall for egress filtering. Finally, enable Azure Defender for Servers for threat detection.

#!/bin/bash
# Enable Azure Disk Encryption
az vm encryption enable \
  --resource-group prod-rg \
  --name prod-web-001 \
  --disk-encryption-keyvault prod-keyvault \
  --key-encryption-key mykey \
  --volume-type all

Cost Management and Right-Sizing

Azure VMs can be expensive if not managed. Start with right-sizing: use Azure Advisor recommendations to identify underutilized VMs (CPU < 5% and memory < 20% for 7 days). Downsize or shut them down during off-hours. Use Azure Cost Management + Billing to set budgets and alerts. For production VMs that run 24/7, buy Reserved Instances or use Azure Savings Plan for compute. For dev/test, use Azure Dev/Test pricing or spot VMs (if interruptible). Another cost-saving technique: use Azure Hybrid Benefit if you have Windows Server or SQL Server licenses with Software Assurance. Also, consider using Azure Dedicated Hosts only if you need physical isolation—they're expensive. A common mistake is leaving VMs running when not needed. Use auto-shutdown for dev VMs. For production, use autoscale to scale in during low traffic. Finally, monitor egress costs—data transfer out of Azure can be significant.

# Get Azure Advisor cost recommendations
Get-AzAdvisorRecommendation -Category Cost | Where-Object {$_.Impact -eq "High"} | Select-Object ResourceName, ShortDescription, ImpactedField

Disaster Recovery: Backup and Site Recovery

Disaster recovery is not optional. Azure Backup provides simple, automated backups for VMs. Configure daily backups with retention up to 99 years. For cross-region recovery, use Azure Site Recovery (ASR) to replicate VMs to a secondary region. ASR provides continuous replication with RPO of seconds. For production, test your recovery plan regularly—at least quarterly. A common mistake is not testing failover. When a real disaster hits, you'll discover missing dependencies, incorrect network configurations, or insufficient capacity. Use ASR's test failover feature to validate without impacting production. Also, ensure your backup vault and ASR vault are in different regions. For critical databases, consider application-level replication (e.g., SQL Always On) in addition to VM-level backup. Finally, document your RPO and RTO and ensure your solution meets them.

# Configure Azure Site Recovery for a VM
$vault = Get-AzRecoveryServicesVault -ResourceGroupName prod-rg -Name prod-asr-vault
Set-AzRecoveryServicesVaultContext -Vault $vault

$policy = Get-AzRecoveryServicesAsrPolicy -Name "24-hour-retention"
$protectionContainer = Get-AzRecoveryServicesAsrProtectionContainer -Fabric (Get-AzRecoveryServicesAsrFabric)

$vm = Get-AzVM -ResourceGroupName prod-rg -Name prod-web-001
$asrVM = New-AzRecoveryServicesAsrProtectableItem -VM $vm -ProtectionContainer $protectionContainer

Enable-AzRecoveryServicesAsrReplication `
  -ProtectableItem $asrVM `
  -Policy $policy `
  -RecoveryResourceGroupName prod-dr-rg `
  -RecoveryCloudServiceName "" `
  -RecoveryAzureNetworkName prod-dr-vnet

Automation and Infrastructure as Code

Manual VM management is a recipe for disaster. Use Infrastructure as Code (IaC) with ARM templates, Bicep, or Terraform. Define everything: resource group, VNet, subnets, NSGs, VMs, disks, extensions, and monitoring. Store templates in Git and use CI/CD pipelines (Azure DevOps, GitHub Actions) to deploy. For production, use deployment stacks to manage resource lifecycle. A common mistake is using the Azure Portal to make one-off changes—this creates configuration drift. Enforce that all changes go through IaC. Use Azure Policy to audit and enforce compliance (e.g., require tags, enforce disk encryption). For secrets, use Azure Key Vault and reference them in templates. Also, use Azure Blueprints to package policies, RBAC, and resource templates for consistent environments. Finally, automate VM shutdown/startup schedules using Azure Automation or Logic Apps to save costs.

param location string = resourceGroup().location
param vmName string = 'prod-web-001'
param adminUsername string

resource vnet 'Microsoft.Network/virtualNetworks@2021-02-01' existing = {
  name: 'prod-vnet'
}

resource nic 'Microsoft.Network/networkInterfaces@2021-02-01' = {
  name: '${vmName}-nic'
  location: location
  properties: {
    ipConfigurations: [
      {
        name: 'ipconfig1'
        properties: {
          subnet: {
            id: '${vnet.id}/subnets/web-subnet'
          }
        }
      }
    ]
  }
}

resource vm 'Microsoft.Compute/virtualMachines@2021-03-01' = {
  name: vmName
  location: location
  properties: {
    hardwareProfile: {
      vmSize: 'Standard_D2s_v3'
    }
    osProfile: {
      computerName: vmName
      adminUsername: adminUsername
      linuxConfiguration: {
        disablePasswordAuthentication: true
        ssh: {
          publicKeys: [
            {
              path: '/home/${adminUsername}/.ssh/authorized_keys'
              keyData: 'ssh-rsa AAAAB3NzaC1yc2E...'
            }
          ]
        }
      }
    }
    storageProfile: {
      imageReference: {
        publisher: 'Canonical'
        offer: 'UbuntuServer'
        sku: '18.04-LTS'
        version: 'latest'
      }
      osDisk: {
        createOption: 'FromImage'
        managedDisk: {
          storageAccountType: 'Premium_LRS'
        }
      }
    }
    networkProfile: {
      networkInterfaces: [
        {
          id: nic.id
        }
      ]
    }
  }
}