Azure Virtual Machines: IaaS Compute on Azure

Q: Azure VMs or a higher-level service (Container Apps, App Service, Functions)?

Use VMs when you need OS-level control, specific software, GPU/specialized hardware, or lift-and-shift of existing servers. Use higher-level services (Container Apps, App Service, Functions) for standard apps where you don't want to manage servers, patching, or scaling. The trend is toward the managed options; reach for VMs when you have a concrete reason to own the OS.

Q: How do I make Azure VMs highly available?

Deploy a Virtual Machine Scale Set spread across Availability Zones behind a load balancer. This gives autoscaling plus resilience to host, update, and datacenter-zone failures. A single VM has no such protection — for production, always design for multiple VMs across zones. See high availability.

Q: How do VMs access other Azure resources securely?

Use managed identities — the VM gets an Entra ID identity that other Azure services (storage, databases, Key Vault) authorize, with no credentials stored on the machine. It's the Azure equivalent of AWS IAM roles and the correct pattern — never embed access keys in the VM.

Azure Virtual Machines

Azure Virtual Machines (VMs) are Microsoft Azure's infrastructure-as-a-service compute — on-demand virtual servers where you control the operating system, installed software, and configuration. They're Azure's equivalent of AWS EC2 and Google Compute Engine: the flexible, full-control compute option you reach for when you need a specific OS, custom software, legacy workloads, or fine-grained control that higher-level services (Azure Container Apps, Functions, App Service) abstract away.

With that control comes ownership: you patch the OS, secure the machine, and manage scaling and availability yourself. Azure VMs are especially prevalent in enterprise and Microsoft-centric environments — Windows Server workloads, SQL Server, Active Directory, and lift-and-shift migrations from on-premises data centers, where Azure's tight Windows/enterprise integration is a real advantage.

TL;DR

Azure VMs are IaaS: you get a virtual server with full OS control (Windows or Linux) and own everything above the hypervisor — patching, security, scaling.
You pick a VM size (series like B/D/E/F for burstable/general/memory/compute) and an image (marketplace OS images or your own).
Virtual Machine Scale Sets (VMSS) provide elasticity and HA — a managed group of identical VMs that autoscale behind a load balancer.
Managed disks provide durable block storage; VMs live in a virtual network (VNet) with network security groups controlling traffic.
Availability comes from Availability Zones and scale sets; a single VM is a single point of failure.
Choose VMs when you need OS-level control or specific software; prefer higher-level Azure services (Container Apps, Functions, App Service) when you don't want to manage servers.

Core Concepts

VM Sizes and Images

Azure offers families of VM sizes optimized for different workloads:

You launch from an image — Azure Marketplace images (Windows Server, Ubuntu, RHEL, etc.), or a custom image you've built (via Shared Image Gallery) for repeatable, pre-configured VMs. Right-sizing matters for cost: an oversized VM running 24/7 is a common source of waste.

Scaling and Availability

A single VM is one server — if it or its host fails, you're down. Production resilience comes from:

Virtual Machine Scale Sets (VMSS) — a managed set of identical VMs that autoscale based on load (add VMs under pressure, remove when idle) behind a load balancer. This is the elasticity primitive, analogous to EC2 Auto Scaling groups.
Availability Zones — deploy VMs across physically separate zones so a datacenter-level failure doesn't take you down (see high availability).
Load balancers / Application Gateway — distribute traffic across VMs and provide a stable entry point.

The pattern for reliable compute: a scale set spread across availability zones behind a load balancer — never a single hand-managed VM for anything important.

Storage and Networking

Managed disks — Azure-managed block storage (the VM's OS and data disks), in tiers from Standard HDD to Premium/Ultra SSD by performance need. Managed disks handle replication and availability for you.
Virtual Network (VNet) — VMs live in a VNet (Azure's equivalent of AWS VPC), divided into subnets, with Network Security Groups (NSGs) as stateful firewalls controlling inbound/outbound traffic. Same public/private subnet discipline applies — keep databases and app servers off the public internet. See cloud networking.

Identity and Management

VMs integrate with Microsoft Entra ID (Azure's identity service) and use managed identities — so a VM can access other Azure resources (storage, Key Vault) without stored credentials, the equivalent of AWS IAM roles. Azure tooling (Azure Monitor, Update Manager, Bastion for secure SSH/RDP without public IPs) helps operate them.

Azure VMs vs AWS EC2

The concepts map almost one-to-one — both are conventional IaaS. Azure VMs' distinctive edge is enterprise and Microsoft integration: licensing benefits for Windows Server and SQL Server (Azure Hybrid Benefit), tight Active Directory/Entra ID integration, and being the natural home for organizations already invested in Microsoft. If your workload is Windows/enterprise-centric, Azure often has cost and integration advantages; for breadth of services, EC2/AWS leads. Both are excellent IaaS.

Common Mistakes

Running a Single VM in Production

One VM is a single point of failure — host failures, updates, and zone outages take it down. Use scale sets across availability zones behind a load balancer for anything that needs uptime. A lone hand-configured VM is fine for dev, dangerous for production.

Oversized VMs Running 24/7

Picking a large VM "to be safe" and leaving it always on is the top Azure cost leak. Right-size to actual usage, use burstable (B-series) for spiky low-baseline workloads, deallocate dev/test VMs when idle (auto-shutdown schedules), and consider reserved instances/savings plans for steady workloads. See cloud costs.

Public IPs and Open NSGs

Exposing management ports (RDP 3389, SSH 22) or databases directly to the internet via public IPs and open NSGs is a constant brute-force target. Keep VMs in private subnets, use Azure Bastion for secure RDP/SSH without public IPs, and scope NSG rules tightly. Same VPC security discipline as any cloud.

Choosing VMs When You Don't Need Them

If you're running a stateless web app or API, Azure Container Apps, App Service, or Functions remove all the OS management. Reaching for VMs by default means owning patching, scaling, and security you could have offloaded. Use VMs when you genuinely need OS control or specific software.

Neglecting Patching and Backup

You own the OS — unpatched VMs accumulate vulnerabilities, and un-backed-up VMs risk data loss. Use Azure Update Manager for patching and Azure Backup for snapshots. This operational responsibility is the price of IaaS control.

FAQ

Azure VMs or a higher-level service (Container Apps, App Service, Functions)?

Use VMs when you need OS-level control, specific software, GPU/specialized hardware, or lift-and-shift of existing servers. Use higher-level services (Container Apps, App Service, Functions) for standard apps where you don't want to manage servers, patching, or scaling. The trend is toward the managed options; reach for VMs when you have a concrete reason to own the OS.

How do Azure VMs compare to AWS EC2?

They're directly analogous IaaS offerings with mapping concepts (Scale Sets ≈ Auto Scaling, Managed Disks ≈ EBS, VNet ≈ VPC, managed identities ≈ IAM roles). Azure's differentiator is Windows/enterprise/Microsoft integration and licensing benefits; AWS's is the breadth of its ecosystem. For Microsoft-centric orgs, Azure VMs often win on cost and integration.

How do I make Azure VMs highly available?

Deploy a Virtual Machine Scale Set spread across Availability Zones behind a load balancer. This gives autoscaling plus resilience to host, update, and datacenter-zone failures. A single VM has no such protection — for production, always design for multiple VMs across zones. See high availability.

How do VMs access other Azure resources securely?

Use managed identities — the VM gets an Entra ID identity that other Azure services (storage, databases, Key Vault) authorize, with no credentials stored on the machine. It's the Azure equivalent of AWS IAM roles and the correct pattern — never embed access keys in the VM.

What makes Azure attractive for Windows workloads?

Azure Hybrid Benefit (reuse existing Windows Server/SQL Server licenses to cut costs), deep Active Directory / Entra ID integration, and being Microsoft's own cloud (first-class support for Windows, .NET, SQL Server, and enterprise tooling). Organizations already on Microsoft stacks often find Azure the path of least resistance and lowest licensing cost.