5.1.1.1. Design for Azure Virtual Machines
5.1.1.1. Design for Azure Virtual Machines
💡 First Principle: Infrastructure as a Service (IaaS) provides the ultimate control over the computing environment, making it the ideal choice for migrating legacy applications, running custom software, or meeting specific operating system requirements.
Scenario: You are designing a solution for a company that needs to host a specialized scientific simulation application. This application requires a custom Linux distribution with specific kernel modules and real-time GPU processing, which isn't supported by standard Azure PaaS offerings.
Azure VMs are on-demand, scalable computing resources that give you control over the operating system.
Key Design Considerations:
- Workload Suitability: Ideal for lift-and-shift migrations, custom software, or when full control over the environment is necessary.
- Scalability: Achieved through Virtual Machine Scale Sets (VMSS) for automatic scaling.
- High Availability: Leverage Availability Sets (within a datacenter) or Availability Zones (across datacenters).
- Storage: Choose appropriate managed disk types (Standard HDD, Standard SSD, Premium SSD, Ultra Disk) based on performance and cost.
- Networking: Integrate VMs into Azure Virtual Networks (VNets) for secure communication.
- Management: Requires patching, updating, and managing the OS and installed software. Use Azure Automation and Azure Monitor to assist.
- Cost: Pay-as-you-go, reserved instances, and Azure Hybrid Benefit can optimize costs.
Design decisions in practice:
| Decision | Choose this when | Because |
|---|---|---|
| Standard HDD | Backup targets, archival, dev/test that tolerates latency | Cheapest per GB, no IOPS guarantee |
| Standard SSD | Light production, web servers, low-IOPS line-of-business apps | Consistent latency without Premium cost |
| Premium SSD | Production databases and any single-instance SLA | The single-VM SLA requires Premium or Ultra on all disks |
| Premium SSD v2 / Ultra Disk | Sustained high IOPS, sub-millisecond latency, tier-1 databases | IOPS and throughput are provisioned independently of size |
Availability Set or Availability Zone? An Availability Set spreads instances across fault and update domains inside one datacenter, which covers rack failure and host patching. An Availability Zone spreads them across physically separate datacenters in the region. Zones are the stronger guarantee and the two are mutually exclusive for the same VM set — you pick one. Choose Availability Sets only where the region offers no zones, or where an existing deployment already uses them.
Cost levers, in the order they usually pay off: right-size first from actual utilization (over-provisioning is the largest single waste), then Azure Hybrid Benefit if the organization holds Windows Server or SQL Server licences with Software Assurance, then Reserved Instances or a savings plan for steady-state workloads, and Spot only for interruptible work. Note that a reservation is a billing commitment, not a capacity or spending cap — it discounts usage but never limits it.
⚠️ Exam Trap: "the VM needs a 99.9% single-instance SLA" is a disk requirement in disguise. Standard HDD or Standard SSD disqualifies the VM from that SLA no matter how the rest of the design looks.
⚠️ Common Pitfall: Using VMs for workloads that could be run more efficiently and cost-effectively on PaaS or Serverless platforms. This leads to unnecessary operational overhead for patching and maintenance.
Key Trade-Offs:
- Control vs. Management Overhead: VMs offer maximum control but come with the highest management responsibility (patching, security, configuration) compared to other compute options.
Reflection Question: How does designing for Azure Virtual Machines (IaaS), leveraging its granular control over the operating system, custom software installations, and networking configurations, fundamentally enable the migration of legacy applications and support highly customized environments in the cloud?
