Azure Virtual Machines provide operating-system control for custom software, migrations, development environments, and workloads that do not fit a managed application platform.
A VM design includes its image, size, disks, network interface, subnet, network security group, identity, availability option, patching method, and recovery plan.
Production VMs should be reproducible from images or automation and treated as replaceable capacity rather than unique hand-maintained servers.
Select a supported image and VM family based on CPU, memory, storage throughput, network throughput, architecture, and licensing. Use zones, availability sets, or scale sets according to the failure model.
Managed disks provide persistent block storage. Separate operating-system and application data where lifecycle or performance requirements differ, and define snapshots or Azure Backup from recovery targets.
Place VMs in appropriate subnets and restrict inbound traffic with NSGs. Prefer Azure Bastion, VPN, Just-in-Time access, or Run Command instead of exposing SSH or RDP to the internet.
Use Update Manager or a defined patch process, collect guest metrics and logs, and automate provisioning with images, cloud-init, extensions, or configuration tools.
A VM combines compute allocation, an OS disk, network interface, identity, extensions, and optional data disks. Starting, stopping, deallocating, restarting, redeploying, and deleting have different effects on compute billing, dynamic addresses, temporary disks, host placement, and attached resources. Deallocating compute does not automatically remove disks, snapshots, NICs, or public addresses.
Choose a supported Marketplace image or a controlled Azure Compute Gallery image with known publisher, offer, SKU, version, architecture, and patch process. Pin or promote approved image versions rather than accepting an unreviewed latest image in production. Track base-image and application release identities separately.
Treat VMs as replaceable. Keep durable data on managed services or explicitly protected data disks, bootstrap from versioned code, and prove that a new instance can join service without copying state from a unique server. A delete lock can prevent one accident but cannot replace reproducibility and recovery.
Availability Zones are separate locations within supported Regions. A zonal VM remains in one zone; resilience requires application instances, entry points, data, and dependencies distributed according to the failure goal. Availability sets spread supported VMs across fault and update domains within a datacenter-era model, while Virtual Machine Scale Sets manage a fleet from a common configuration.
Use flexible or uniform scale-set orchestration according to workload and management requirements, and verify the current feature support rather than assuming the modes are interchangeable. Define minimum, maximum, zone balance, upgrade policy, health signal, and scale-in protection for long-running work.
Test one instance failure, one zone loss, capacity shortage for a selected SKU, and a bad image rollout. A load balancer or application gateway health probe must represent readiness without causing every instance to be removed when one shared dependency is temporarily unavailable.
Managed disks provide block storage for OS and data volumes. Choose disk type, size, IOPS, throughput, caching, redundancy, and bursting behavior from measured demand and VM limits. Effective performance is constrained by both disk and VM, so a faster disk cannot exceed the attached VM path.
The temporary disk on VM sizes that provide one is not a managed data disk and can lose contents during host or lifecycle events. Use it only for caches and reconstructable scratch data. Place application data on data disks or managed data services, and understand whether an ephemeral OS disk is appropriate before selecting it.
Snapshots and Azure Backup protect different recovery workflows. Coordinate application-consistent backup for databases, encrypt disks and recovery data according to key policy, and test restoration into an isolated network. Expanding a disk may still require partition and filesystem work inside the guest.
A VM network interface receives private addresses in a subnet and can have NSGs at subnet and interface scope. Effective rules combine those controls with routes, Azure Firewall or appliances, public IP behavior, and the guest firewall. Use Network Watcher evidence and a path-oriented checklist instead of opening broad rules when connectivity fails.
Keep SSH and RDP private through Azure Bastion, VPN, ExpressRoute, Just-in-Time access, or a controlled administration path. Restrict source identity and network, log sessions where required, and remove direct public exposure. Run Command and VM extensions are privileged control-plane paths and need narrowly assigned RBAC.
Attach a managed identity for Azure APIs and protect the instance metadata endpoint from untrusted local processes and proxies. Use private endpoints or service endpoints where they meet downstream requirements, and test private DNS from the VM subnet.
Cloud-init, Custom Script Extension, image build, and configuration management can bootstrap a VM. Keep the process idempotent, bounded, versioned, and observable. Do not put long-lived secrets in custom data or scripts; retrieve them through managed identity and a vault. Capture extension status and guest logs when provisioning reports success but the application is not ready.
Azure VM extensions run with significant guest privilege and add their own publisher, version, network, and lifecycle dependencies. Install only required extensions, control automatic upgrades according to testing policy, and remove abandoned agents. A failed extension can block an infrastructure deployment even when the VM itself is running.
Use Azure Update Manager or another approved patch workflow, define maintenance windows and reboot behavior, and patch a representative group before the fleet. Image replacement often creates more reproducible systems than long-lived in-place mutation. Test rollback and application compatibility for kernel, runtime, and agent updates.
VM price is only part of the workload cost. Include disks, snapshots, backup, public addresses, load balancing, outbound transfer, monitoring, licenses, security tools, and idle scale-set capacity. Compare pay-as-you-go, reservation or savings options, and Spot only after measuring baseline usage and interruption tolerance.
Monitor platform availability, guest CPU, memory, disk space and latency, network, process health, patch state, backup, and application symptoms. Boot diagnostics, serial console, Activity Log, resource health, guest logs, and deployment history answer different failure questions. Route every alarm to a runbook owner.
Exercise an unhealthy instance replacement, lost zone, corrupt disk, failed extension, unavailable secret, quota limit, and backup restore. Preserve evidence before destructive redeploy when investigation is required. Recovery is complete when the workload serves a real request with validated data, not when a VM reaches running state.
Track operating-system image support, agent and extension support, VM-generation compatibility, SKU retirement, and region availability as scheduled operational work. Rebuild and test a replacement image before a support deadline; an unchanged application does not make an obsolete guest platform safe to keep running.
Use Run Command to verify package installation and basic application health without opening extra management ports just for troubleshooting.
az vm run-command invoke \
--resource-group rg-cloud-lab \
--name vm-web-01 \
--command-id RunShellScript \
--scripts "sudo apt-get update && sudo apt-get install -y nginx && systemctl is-active nginx && curl -I http://localhost"A manually patched VM differs from the approved image and fails compliance checks.
Constraints: Application state is external, disks have recovery points, and the service uses a load balancer health probe.
Decision: Capture diagnostics, build a corrected image through the image pipeline, and replace the instance rather than preserving drift.
Verification: The replacement joins healthy, the drift report clears, and rollback can redeploy the prior image version.
Failure test: Fail the health probe on the new image and verify traffic stays on healthy instances.Expected evidence: The replacement joins healthy, the drift report clears, and rollback can redeploy the prior image version.Explore 500+ free tutorials across 20+ languages and frameworks.