Compute
Beginner 12 min read Compute

Virtual Machines and Instances

Managed virtual servers on shared hardware

A VM is a virtual computer that runs an operating system on shared physical hosts. Cloud providers expose them as instances (EC2), VMs (Azure) and Compute Engine (GCP) with sizes, images and networking.

VMinstanceEC2Compute Enginehypervisorinstance typevirtual machine
Prerequisites: Virtualization and Hypervisors
Before we start

What you will learn

  • Explain how instances map to a hypervisor and shared physical hosts
  • Compare instance naming across AWS, Azure and GCP
  • Describe disks, images, networking and metadata on a VM
In 60 seconds

Promises hardware abstraction: you provision a size (CPU/RAM), pick an OS image, attach disks, join a network, and get a virtual machine that can be started, stopped and replaced — all without owning a rack.

Introduction

What is this?

Cloud VMs are virtual machines backed by a hypervisor (Nitro/KVM/Hyper-V) running on massive fleets of physical hosts. AWS calls them EC2 instances (m5.large, t3.small); Azure calls them VMs (Standard_D8s_v5); GCP calls them Compute Engine instances (e2-standard-4). Each instance has vCPUs (virtual cores), memory, local/ephemeral or attached persistent disks, at least one NIC on a VPC/VNet, a metadata service for instance facts and credentials.

Motivation

Why do you need it?

  • Instant compute without capital expenditure or lead time.
  • Resizable: change family/size to match workload need.
  • OS isolation lets teams run arbitrary software safely.
  • Per-second/per-minute billing and autoscaling remove idle waste.
Think about it

Mental model

Imagine

Renting an apartment with shared plumbing and electricity

Think of

Cloud virtual machines

You control your unit (the OS, apps, files) and only pay for your floor space, while the building (the physical host, network, power) is shared, maintained and metered by the landlord.

Mechanics

How it works

  • A hypervisor multiplexes one physical host among many VMs, enforcing isolation on CPU, memory and I/O.
  • You request an instance type: a hardware profile with vCPUs, memory, network bandwidth and local SSD options.
  • The image (AMI/Azure image/Compute Engine image) boots the VM with a chosen OS and configuration.
  • Persistent disks are network-attached storage (EBS, managed disks, Persistent Disk) that survive stop/start.
  • The metadata service (IMDS) gives every instance its identity, tags, user-data and short-lived role credentials.

One boot-to-run VM flow.

Pick size + image
Attach network + disks
Hypervisor schedules
Instance boots
Ready
Hands-on

Examples

Launch a compute instance everywhere

Launch a compute instance everywhere
# AWS
aws ec2 run-instances --image-id ami-12345678   --instance-type t3.micro --key-name dev --count 1
# Azure
az vm create -n web-01 -g app-rg --image UbuntuLTS   --size Standard_B1s --generate-ssh-keys
# GCP
gcloud compute instances create web-01 --machine-type=e2-micro   --zone us-central1-a --image-family ubuntu-2204-lts

All three treat a VM as an API resource: a size, an image, a network and a key. The cloud schedules, runs and bills it.

Real world

In production

  • A platform team runs a fleet of t3.medium EC2 for web tiers behind an ASG + ALB.
  • Azure burstable B-series VMs handle dev and CI spikes at low base CPU.
  • GCP e2-standard instances run batch workers started by Cloud Scheduler.
Guidelines

Best practices

  • Use AMIs/images from a pipeline so every VM is exactly reproducible.
  • Attach tags to instances and disks for cost and ownership.
  • Put instances behind managed groups (ASG/VMSS/MIG) instead of standalone VMs.
  • Disable password auth; use SSH keys backed by your IdP.
Watch out

Common mistakes

  • Treating VMs as pets: patching, fixing and naming them as unique snowflakes.
  • Choosing huge instance types 'just in case' instead of autoscaling small ones.
  • Forgetting instance metadata (IMDSv1) open to SSRF attacks.
  • Mixing sizes of a family and making capacity planning guessing work.
Root cause analysis

Common issues

Error
Instance unreachable via SSH
Root cause

Security group/firewall or key mismatch

Fix

Check SG inbound 22, NACL return rules, and that the key matches the one provided at launch.

Error
Insufficient capacity when launching
Root cause

Region/AZ out of capacity for that instance type

Fix

Add capacity across AZs or switch instance type; use On-Demand Capacity Reservations for critical fleets.

When things break

Debugging tips

  • Cannot reach instance? Check SG/NSG/firewall rules, route tables and NACLs, not just the OS.
  • Slow boot: inspect cloud-init/user-data logs in /var/log.
  • No SSH? Verify key permissions, allowlists and the instance's public IP assignment.
  • Terminate + relaunch is often faster to debug than 'fixing' a broken instance.
Interviews

Interview checkpoint

Practice

Hands-on lab

Provision Your First Cloud VM from the CLI
25 min · beginner
In progress
Objectives
  • Launch, inspect and terminate a compute instance on any provider
  • Use the metadata service for instance facts
  • Understand stop vs terminate and billing implications

Provision Your First Cloud VM from the CLI

25 min · beginner

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

What enforces isolation between cloud VMs sharing a physical host?

Go deeper

Official documentation

AWS — Amazon EC2
docs
Azure — Virtual machines
docs
GCP — Compute Engine
docs