Resources Required for Virtual Machines
Slide deck explaining the resources required for Azure Virtual Machines, including compute, storage (persistent and ephemeral), networking (VNet, subnet, NIC), Network Security Groups, public vs private access, and common pitfalls.
Resources Required for Virtual Machines
Introduction to resources required for Azure Virtual Machines, covering compute, storage, and networking components.
Resources Required for Virtual Machines
Introduction to resources required for Azure Virtual Machines, covering compute, storage, and networking components.
A Virtual Machine (VM) is multiple resources
Creating a VM usually creates compute plus storage plus networking as separate resources. VM equals compute resource (the 'machine'). Needs storage to boot and keep data. Needs networking to communicate. The portal can create them together, but they remain separate.
Compute: the VM resource
The VM is the compute component: vCPU and RAM. Azure Virtual Machine (VM) equals compute component. Size defines virtual CPU (vCPU) and Random Access Memory (RAM). Compute is necessary, but not sufficient. Storage plus networking complete the working system.
Persistent storage: disks
A VM boots from an OS disk, and may use data disks for durable storage. Operating system (OS) disk: required for boot. Data disks: optional, for app/data storage. Often implemented as managed disks. Use persistent disks for important data.
Temporary (ephemeral) storage
Temporary storage is fast/useful, but you should assume it can be lost. Temporary (ephemeral) storage may exist on some VM sizes. Good for cache, scratch, intermediate files. Not durable: data can be lost. Important data belongs on managed disks.
Minimum private networking for a VM
Private-only still needs VNet plus subnet plus NIC for a private IP. Virtual Network (VNet): private network in Azure. Subnet: a segment inside the VNet. Network Interface (NIC): attaches VM to subnet. NIC provides a private IP for internal communication.
Private connectivity vs public internet
Internet reachability requires explicit configuration (public endpoint plus allowed inbound). VNet connection equals private communication. Public IP address equals public endpoint for internet reachability. No public endpoint → VM can still work privately. 'On a VNet' does not equal 'reachable from the internet'.
Network Security Group (NSG) basics
An NSG filters inbound and outbound traffic for subnets and NICs. Network Security Group (NSG) equals traffic filtering rules. Rules apply inbound and outbound. Attach to a subnet and/or a Network Interface (NIC). Public endpoint still needs allowed inbound rules.
Why you can't connect from the internet
Public access needs both a public endpoint and allowed inbound rules. Remote Desktop Protocol (RDP) and Secure Shell (SSH) need inbound access. VNet/subnet/NIC equals private IP only. Public IP address (or other public endpoint) enables public reachability. Network Security Group (NSG) must allow the inbound traffic.
Private access without a public endpoint
You can connect privately via VPN or ExpressRoute without exposing a public IP. Virtual Private Network (VPN): private tunnel to Azure. Azure ExpressRoute: private connectivity via a dedicated connection. VM can stay private (no public endpoint). Private connectivity still uses VNet/subnet/NIC.
Where VM resources live
Every related resource is placed in a subscription, resource group, and region. Subscription: management and billing boundary. Resource group: manage related resources together. Region: physical location (where resources are hosted). Placement affects governance, access, and cost tracking.
Common pitfalls (and quick fixes)
Most issues come from mixing up resources, storage durability, and public reachability. VM is not 'all-in-one': compute plus disks plus networking. VM needs an operating system (OS) disk to boot. Temporary (ephemeral) storage is not durable. Public access requires public endpoint plus NSG inbound rules.