Skip to content

Portal | Level: L1: Foundations | Topics: Azure Virtual Machines, Cloud Deep Dive | Domain: Cloud

Azure Virtual Machines - Primer

Accuracy note: Azure changes quickly. Limits and defaults below were checked against Microsoft Learn documentation as of July 2026. Items marked verify for region/SKU are intentionally not presented as universal because Azure capabilities, quotas, and rollout status can differ by region, subscription, API version, and resource SKU.

Why This Matters

Azure Virtual Machines is Azure's general-purpose IaaS compute service and is the closest direct equivalent to Amazon EC2. The basic unit is still a VM created from an image, attached to network interfaces and block devices, but Azure's surrounding resource model is more explicit and more fragmented than EC2's.

A typical VM deployment creates or references several independent Azure Resource Manager (ARM) resources:

  • A Microsoft.Compute/virtualMachines VM resource.
  • One or more Microsoft.Network/networkInterfaces resources.
  • A subnet inside a VNet.
  • Optional public IP resources.
  • Managed OS and data disks.
  • Optional availability, identity, backup, monitoring, and update-management resources.

This matters operationally because deleting the VM does not necessarily delete every dependent resource. Disks, NICs, public IPs, snapshots, backup recovery points, and monitoring data can survive and continue costing money.

Images and Generations

VMs normally start from:

  • Azure Marketplace images.
  • Azure Compute Gallery image versions.
  • Managed images, now largely a legacy path for reusable fleet images.
  • Specialized disks/images that retain machine-specific state.

Azure Compute Gallery is the strategic equivalent of sharing and replicating AMIs, but it models image definitions and image versions separately and can replicate versions across regions. For Linux, cloud-init is the normal first-boot customization mechanism. Azure also supports VM extensions — platform-delivered agents/scripts installed after provisioning.

Generation 1 versus Generation 2 affects firmware, disk layout, Secure Boot/vTPM options, and supported VM sizes. Treat the image generation as immutable compatibility metadata; converting an existing deployed VM is not a routine resize operation.

VM Sizes and Quota Model

Azure VM sizes are grouped into families such as B, D, E, F, L, M, N, and H. Size naming encodes family, generation, CPU vendor, premium-storage capability, local temporary storage, constrained-core variants, and other properties. Do not assume two similarly named sizes are substitutable in every region.

Quota has two simultaneous dimensions:

  1. Total regional vCPU quota for the subscription.
  2. Per-VM-family regional vCPU quota.

A deployment must fit under both. This differs from the common AWS mental model where EC2 service quotas are often discussed mainly by instance family or running On-Demand vCPUs. Azure capacity availability is also separate from quota: quota approval does not guarantee that the requested SKU is physically allocatable in a zone.

Availability Choices

Azure exposes several related but non-equivalent mechanisms:

  • Availability Zone: A physically separate datacenter location within a region. A zonal VM is pinned to one numbered zone. To survive a zone failure, deploy independent instances across zones and put a zone-redundant load-balancing/data layer in front of them.
  • Availability Set: A logical grouping inside one datacenter/region that spreads VMs across fault domains and update domains. An availability set can have up to 3 fault domains and 20 update domains, fixed at creation. It does not protect against a full-zone or regional outage. (Microsoft Learn: Availability sets)
  • Virtual Machine Scale Set (VMSS): A fleet-management resource for a group of VMs. VMSS provides orchestration, autoscale integration, health repair, image rollout, and optional zone distribution.
  • Proximity Placement Group: Requests low physical latency between resources, often trading away some placement flexibility and capacity availability.
  • Capacity Reservation: Reserves compute capacity for specific VM sizes in a region/zone. This is not the same as a Reserved VM Instance billing discount.
  • Dedicated Host: Places VMs on dedicated physical hosts for isolation, licensing, or compliance.

VM Scale Sets: Flexible versus Uniform

VMSS has two orchestration modes that cannot be changed after creation:

  • Flexible orchestration: Individual VMs remain first-class VM resources and can be managed with normal VM APIs. Flexible supports heterogeneous operational patterns better and is the preferred mode for many new deployments.
  • Uniform orchestration: Instances are generated from a common model and managed primarily through the scale-set interface. Uniform remains useful for strongly identical, cattle-style fleets and some legacy patterns.

Scale sets can support up to 1,000 instances with supported Marketplace or Azure Compute Gallery images; older managed-image paths can have lower limits. (Microsoft Learn: VMSS overview and limits)

Storage

Azure Managed Disks are the normal block-storage model. Common disk types include:

  • Standard HDD.
  • Standard SSD.
  • Premium SSD.
  • Premium SSD v2.
  • Ultra Disk.

The VM size itself imposes aggregate cached/uncached disk throughput, IOPS, disk-count, and bandwidth ceilings. Provisioning a high-performance disk does not bypass the VM's own I/O cap. (Microsoft Learn: VM and disk performance)

The temporary disk on applicable VM sizes is local ephemeral storage. It is not a durable EBS-like volume. Its contents can disappear during redeployment, host movement, resize, maintenance, or deallocation. Some newer VM sizes have no temporary disk.

Ephemeral OS disks store the OS on local VM storage. They are optimized for disposable nodes and fast reimage, but they cannot be stop-deallocated and safely resumed like a managed OS disk; resize or redeploy can reimage and destroy OS-disk state. (Microsoft Learn: Ephemeral OS disks)

Identity and Management Plane

A VM can have:

  • A system-assigned managed identity, whose lifecycle is tied to the VM.
  • One or more user-assigned managed identities, which are independent resources reusable across VMs and other Azure services.

Managed identities obtain Entra ID tokens without storing a client secret on disk. They are closer to EC2 instance profiles than to a generic IAM role, but the underlying Azure object is a service principal and permissions are still granted through Azure RBAC or a service-specific data-plane role.

See Also

Wiki Navigation

Prerequisites

Related Content

  • AWS CloudWatch (Topic Pack, L2) — Cloud Deep Dive
  • AWS Devops Flashcards (CLI) (flashcard_deck, L1) — Cloud Deep Dive
  • AWS EC2 (Topic Pack, L1) — Cloud Deep Dive
  • AWS ECS (Topic Pack, L2) — Cloud Deep Dive
  • AWS General Flashcards (CLI) (flashcard_deck, L1) — Cloud Deep Dive
  • AWS IAM (Topic Pack, L1) — Cloud Deep Dive
  • AWS Lambda (Topic Pack, L2) — Cloud Deep Dive
  • AWS Networking (Topic Pack, L1) — Cloud Deep Dive
  • AWS Route 53 (Topic Pack, L2) — Cloud Deep Dive
  • AWS S3 Deep Dive (Topic Pack, L1) — Cloud Deep Dive