Azure Virtual Machines: Compute in the Cloud — A Beginner's Guide for DevOps

Azure Virtual Machines are the compute building block of Azure: on-demand virtual servers you can provision in minutes, resize as demand changes, and tear down when done. This lesson covers regions, availability zones, VM sizes, images, managed disks, VNet networking, NSG security, SSH authentication, and pricing models — plus a step-by-step launch of your first Linux web server. It is the natural next stop after Azure Fundamentals & IAM on the Azure roadmap.

1. Learning Objectives

By the end of this lesson, you will be able to:

• Explain what Azure Virtual Machines are and where they fit in the Azure IaaS model
• Identify the core building blocks: regions, availability zones, VM sizes, images, and managed disks
• Configure the networking essentials: virtual networks, subnets, public IPs, and network security groups
• Choose the right authentication method: SSH keys versus passwords
• Launch a Linux virtual machine with the Azure CLI in under ten minutes
• Compare Azure pricing models: pay-as-you-go, reserved instances, and spot VMs
• Clean up resources properly to avoid surprise monthly bills

2. Why This Matters

Imagine your company application server is running on aging hardware in a rented data center rack. A marketing campaign goes live next week and traffic is about to triple. Buying, racking, and provisioning a new physical server takes weeks. With Azure Virtual Machines you provision a new server in minutes, right-sized for the workload, pay only while it runs, and delete it the moment the campaign ends.

For DevOps engineers, VMs are also where the rest of the Azure story comes together. The IAM controls you learned in the previous lesson decide who is allowed to create them, the networking services you will meet in the next lesson keep them reachable and secure, and managed disks give them durable storage that survives reboots, resizes, and even VM replacement.

3. Core Concepts

A virtual machine in Azure is really three things bundled together: compute (vCPUs and memory), storage (the disks that hold the operating system and your data), and networking (how the world reaches it). Azure provisions each piece as a managed service and lets you assemble them with a single command.

Regions and availability

Every Azure resource lives in a region, a geographic area such as eastus or westeurope. To survive hardware failures, spread VMs across availability zones (physically separate data centers within one region) or group them in an availability set, which distributes them across fault domains (separate racks, power, and network) and update domains (groups patched one at a time so the application never goes fully down).

VM sizes

Azure offers hundreds of VM sizes grouped into families: B-series for burstable dev and test workloads, D-series for general purpose compute, E-series for memory-optimized workloads, F-series for compute-optimized tasks, and M-series for large in-memory workloads. A size such as Standard_B1s means 1 vCPU and 1 GiB of RAM — enough for a small test server, too small for production traffic.

Images

An image is a template for the operating system. The Azure Marketplace provides official images such as Ubuntu2204, Debian11, and Windows Server 2022, and you can capture your own custom images and share them through the Azure Compute Gallery for consistent, pre-configured baselines across your fleet.

Managed disks

Every VM has an OS disk (where the operating system lives) and can have additional data disks for applications and databases. Azure managed disks are block storage that Azure replicates for durability; performance tiers range from Ultra and Premium SSD down to Standard SSD and Standard HDD for cost-sensitive workloads.

Networking essentials

VMs attach to a virtual network (VNet) and a subnet, receive a private IP address, and optionally a public IP. A network security group (NSG) is the firewall that filters traffic to and from your VM — by default it blocks most inbound traffic, so you must explicitly allow ports such as 22 for SSH and 80/443 for web traffic.

Authentication

For Linux VMs, SSH public key authentication is the secure default: Azure stores your public key on the VM and you connect with the matching private key. Password authentication is simpler but far easier to brute-force — avoid it for anything exposed to the internet.

The Azure CLI

You can manage VMs from the portal, but DevOps work is automated, repeatable, and scriptable. The Azure CLI (az) is the command-line tool you will use throughout this lesson, and the same commands drop naturally into CI/CD pipelines.

4. Hands-On Practice

In this walkthrough you will launch an Ubuntu VM, connect over SSH, install nginx, open it to the internet, and then tear everything down. You need the Azure CLI installed and logged in.

az login
az account show --output table

az group create \
  --name rg-devops-lab \
  --location eastus

A resource group is a container that holds related resources so you can manage, monitor, and delete them as one unit. Everything you create next goes into rg-devops-lab.

az vm create \
  --resource-group rg-devops-lab \
  --name vm-web-01 \
  --image Ubuntu2204 \
  --size Standard_B1s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

The --generate-ssh-keys flag creates a key pair for you and installs the public key on the VM. Note the publicIpAddress in the output — you will need it to connect.

ssh azureuser@52.167.1.23

The default administrative user is the one you set with --admin-username (azureuser in this example). You are now inside a real Ubuntu server in Azure. Install and start nginx:

sudo apt-get update
sudo apt-get install -y nginx
sudo systemctl enable --now nginx
systemctl status nginx --no-pager

nginx is running, but the network security group still blocks port 80, so nobody outside can reach it yet. Open the port with the CLI:

az vm open-port \
  --resource-group rg-devops-lab \
  --name vm-web-01 \
  --port 80

Now open http://<public-ip-address> in a browser and you should see the nginx welcome page. When the load grows, resize the VM to a larger size (this requires a brief restart):

az vm resize \
  --resource-group rg-devops-lab \
  --name vm-web-01 \
  --size Standard_B2s

Finally, when you are done, delete the resource group. This removes the VM, its disks, the public IP, the VNet, and the NSG in one command — the cleanest way to avoid ongoing costs:

az group delete --name rg-devops-lab --yes --no-wait

5. Common Errors & Solutions

SSH connection refused or timed out. The VM is still booting or the NSG blocks port 22. Wait a minute and retry; list the rules with az network nsg rule list and allow the port with az vm open-port --port 22 if it is missing.

Permission denied (publickey). The private key does not match the key installed on the VM, or you used the wrong username. Connect with the exact user from --admin-username and point ssh at the correct key file with -i ~/.ssh/id_rsa.

QuotaExceeded. The subscription vCPU quota for the region is exhausted. Check usage with az vm list-usage --location eastus --output table, request a quota increase, use a smaller size, or pick a different region.

Public IP unreachable after install. nginx runs but the browser cannot connect. The NSG still blocks port 80 — run az vm open-port --port 80, and confirm the service is listening with sudo ss -tlnp | grep :80 on the VM.

Billing continues after deleting the VM. The OS and data disks, public IP, and other resources survive VM deletion. Delete the whole resource group with az group delete to remove everything at once.

6. Summary Checklist

• A VM bundles compute, storage, and networking into one managed resource
• Choose a region, then spread workloads across availability zones or sets for resilience
• Pick a size family that matches the workload: B, D, E, F, and M series
• Start from Marketplace images; capture custom images for consistent baselines
• Use managed disks: an OS disk plus data disks, sized by performance tier
• Secure VMs with NSGs and SSH keys — never open more ports than needed
• Launch everything with az vm create --generate-ssh-keys
• Clean up with az group delete to avoid surprise costs

7. Practice Exercise

Build a two-resource lab to reinforce the concepts. First, create a resource group named rg-practice. Then create a VM named vm-app-01 with Ubuntu 22.04, size Standard_B1s, and SSH key authentication, attaching a 32 GiB Premium SSD data disk. Connect over SSH, format the new disk and mount it at /data (sudo mkfs.ext4 /dev/sdc, sudo mkdir /data, sudo mount /dev/sdc /data). Install nginx, open port 80, and verify the welcome page in your browser. Finally, resize the VM to Standard_B2s, confirm the data on /data survives, and delete the resource group. If the disk contents survive the resize, you have correctly separated compute from storage — the core idea behind managed disks.

8. Next Steps

You have launched and managed your first Azure compute. The next lesson in the Azure Cloud series builds the network layer underneath it: Azure Networking — virtual networks, subnets, network security groups, Azure Load Balancer, and Azure DNS. After that, Azure Storage covers blob storage, file shares, and durable disk options so your applications have a reliable place to put data.