Azure Virtual Machines

Azure Fundamentals

Chapter 3 · Azure Virtual Machines

AWS Fundamentals Chapter 3 covered EC2 — AWS's own foundational, day-one compute service. Azure's own virtual machine service has a real, genuinely different history: Azure itself launched in February 2010 as a platform-as-a-service offering first, and general-purpose Windows and Linux virtual machines weren't announced until June 2012, over two years later — VMs were a real, deliberate later addition to Azure, not its original foundation the way EC2 was for AWS.

Real VM Sizes & Series

Azure organizes VM sizes into real families, each tuned for a different workload shape — genuinely analogous in spirit to AWS's own instance families (Chapter 3 of AWS Fundamentals), though named and structured differently:

Family	Type	Tuned For
A-family	General purpose	Entry-level, economical workloads — dev/test, small databases
B-family	General purpose	Burstable — a real, distinctive CPU credit model (below)
D-family	General purpose	Balanced CPU/memory — enterprise applications, the real default choice
F-family	Compute optimized	High CPU-to-memory ratio — web servers, batch processing, gaming
E-family	Memory optimized	Relational databases, in-memory analytics
M-family	Ultra memory optimized	Extremely large in-memory databases, real massive RAM needs
L-family	Storage optimized	High disk throughput — big data, NoSQL databases
N-family (NC/ND/NG/NV)	GPU accelerated	AI/ML training, rendering, cloud gaming
H-family (HB/HC/HX)	High performance compute	Scientific simulations, genomics, computational fluid dynamics

A Real, Distinctive Feature: B-Series CPU Credits

Unlike every other Azure VM family, B-series instances run on a real CPU credit model: while a B-series VM's actual usage stays below its own baseline CPU performance level, it accumulates real credits; when usage rises above that baseline, it spends those accumulated credits to burst to higher performance. Once all credits are exhausted, the VM is throttled back down to its own base performance level until it accumulates enough credits to burst again. This makes B-series VMs a genuinely good real fit for workloads with unpredictable, spiky-but-mostly-idle demand — web servers, dev environments, proof-of-concept projects.

Real Pricing Models

Pay-As-You-Go — billed per second/hour, no commitment, the most flexible and most expensive real rate.
Reserved VM Instances — commit to 1 or 3 years for a real, significant discount, broadly comparable in spirit to AWS's own Reserved Instances.
Spot VMs — real discounts of up to 90% off Pay-As-You-Go pricing, using Azure's own spare capacity.

A Real, Genuine Difference From AWS Spot

Azure Spot VMs can be evicted for two real, distinct reasons — not just one: capacity-based eviction (Azure needs the compute capacity back, the same real reason AWS Spot instances get reclaimed), and a second, genuinely Azure-specific mechanism, price-based eviction — you set a maximum price you're willing to pay, and if the real current Spot price rises above it, your VM is evicted even if capacity is otherwise available. A Spot VM workload needs to tolerate both real interruption reasons, not just one.

Network Security Groups (NSGs)

A Real, Genuine Structural Difference From AWS

AWS Fundamentals Chapter 5 taught two genuinely separate constructs — stateful security groups at the instance level, and stateless NACLs at the subnet level. Azure uses just one real construct instead: the Network Security Group (NSG), which is stateful (a flow record tracks each connection, so an allowed inbound request automatically permits its own reply back out) — and can be applied at either the subnet level, the individual network interface level, or both at once. There's no separate stateless equivalent to AWS's own NACLs in Azure's model at all.

An NSG's own rules are evaluated in real priority order — a number between 100 and 4096, with lower numbers evaluated first. Once traffic matches a rule, evaluation stops; no lower-priority rule (a higher number) is ever checked after a match. Every new NSG automatically receives three real default inbound rules and three real default outbound rules (allowing traffic within the virtual network and from the Azure Load Balancer, denying everything else) at the lowest possible priority — you can't remove these defaults, but you can override them with your own, genuinely higher-priority custom rules.

A Real, Striking Coincidence: Azure's Own Instance Metadata Service

The Same Real Address as AWS

Azure exposes real per-VM instance metadata at 169.254.169.254 — the exact same real special address AWS's own IMDS (Chapter 3 of AWS Fundamentals) uses. Azure also uses a second real address, 168.63.129.16, for platform services like DNS, licensing, and health monitoring. Both are real, Microsoft-owned virtualized addresses, and by default, traffic to them isn't subject to your own NSG rules at all — unless you deliberately target them with specific service tags (AzurePlatformDNS, AzurePlatformIMDS, AzurePlatformLKM) to override that default.

EC2 vs. Azure VM

Property	AWS EC2	Azure VM
Real launch	2006, AWS's foundational service	June 2012, added over 2 years after Azure itself launched
Burstable family	T-series	B-series — real CPU credit model
Instance/network firewall	Two constructs — security groups (instance) + NACLs (subnet)	One construct — NSGs (subnet, NIC, or both)
Spot eviction reasons	Capacity only	Capacity AND price-based
Metadata service address	169.254.169.254	169.254.169.254 (same address)

Hands-On Exercises

Exercise 1

A dev/test VM sits idle most of the day, with occasional short bursts of real CPU-intensive work. Recommend a real VM family for this workload, and explain how its own specific real mechanism fits the described usage pattern.

📄 View solution

Exercise 2

A team sets a maximum Spot VM price well below the current real market rate for that VM size, expecting to only lose the VM if Azure runs out of capacity. Explain, in your own words, what real, second eviction reason they may have overlooked, and why.

📄 View solution

Exercise 3

A team with prior AWS experience assumes they'll need two separate real constructs in Azure - one for instance-level filtering, one for subnet-level filtering - the way AWS uses security groups and NACLs. Explain, in your own words, why this assumption doesn't carry over correctly to Azure's own real NSG model.

📄 View solution

Chapter 3 Quick Reference

Azure VMs — launched June 2012, a real later addition to Azure, unlike AWS's own EC2-from-day-one foundation
VM families — A (economical), B (burstable, real CPU credits), D (balanced default), F (compute), E/M (memory), L (storage), N (GPU), H (HPC)
Real pricing — Pay-As-You-Go, Reserved (1/3-year), Spot (up to 90% off, with TWO real eviction reasons: capacity and price)
NSGs — one real, stateful construct, applicable at subnet, NIC, or both levels — genuinely unlike AWS's split security-group/NACL model
Real priority-based rule evaluation — lower number = higher priority, first match wins, defaults can't be removed but can be overridden
Azure's own real IMDS uses the same real address as AWS's, 169.254.169.254, plus a second address (168.63.129.16) for platform services