Compute Fundamentals

Chapter 1 named IaaS as the layer this course spends the most hands-on time on — this chapter is why: virtual machines are the most common thing a support engineer actually gets tickets about, and the concepts here (sizing, lifecycle states, pricing model, auto-scaling) recur constantly in real troubleshooting work.

What a Virtual Machine Actually Is

A virtual machine is a software-emulated computer running on top of a hypervisor — a layer that lets one physical server safely host many isolated VMs at once, each unaware of the others. Cloud providers use bare-metal (type 1) hypervisors running directly on the physical hardware, rather than on top of a host operating system.

Worth distinguishing early: VMs virtualize the hardware — each one runs its own full operating system. Containers (this site's own docker1/docker2 courses) virtualize the operating system instead — much lighter weight, but a genuinely separate topic this course doesn't go deep on.

Launching a VM — What You Actually Choose

Spinning up a VM on any of the three providers involves the same core decisions, just under different menu names:

1. Machine image — a preconfigured OS-plus-software snapshot (an AMI on AWS, a VM image on Azure, an image on GCP).
2. Instance type/size — the CPU/RAM/network combination (Chapter 3's own next section).
3. Region and zone — where physically the VM runs.
4. Attached storage — covered fully in Chapter 4.
5. Networking and security group assignment — covered fully in Chapter 5.
6. Access credentials — an SSH key pair (Linux) or equivalent login credential, set at launch time.

Instance Families & Sizing

Every provider groups instance types into similar families, just with different names:

Sizing is fundamentally a vCPU + RAM + network throughput trade-off. Undersizing causes real performance problems and timeouts under load; oversizing simply wastes money — Chapter 9 covers cost management as its own topic, but the sizing decision made here is where that cost is actually determined.

Instance Lifecycle & States

Every provider's VMs move through the same core states: running, stopped, and terminated (or deleted). The distinction between stopped and terminated is genuinely important, not just semantic:

• Stopped — the VM isn't running, and you stop paying for compute — but its attached storage still exists and is still billed.
• Terminated/deleted — the instance and (usually) its storage are gone permanently, unless a snapshot was taken beforehand.

Pricing Models

• On-demand / pay-as-you-go — full flexibility, no commitment, the highest per-hour cost.
• Reserved / committed use — a meaningful discount in exchange for a 1-3 year usage commitment, appropriate for predictable, always-on workloads.
• Spot / preemptible instances — a deep discount, but the provider can reclaim the instance with very little notice.

Auto-Scaling — Elasticity in Action

This is Chapter 1's "elasticity" made concrete. Auto-scaling groups (AWS Auto Scaling Groups, Azure VM Scale Sets, GCP Managed Instance Groups) automatically add or remove VM instances based on defined metrics — CPU utilization, request count, or similar. The core mechanism is the same everywhere: a minimum, maximum, and desired instance count, a scaling policy defining what triggers a change, and automatic health checks that replace unhealthy instances without manual intervention. Auto-scaling groups typically sit behind a load balancer (Chapter 5) that distributes incoming traffic across whatever the current instance count happens to be.

A Support-Relevant Gotcha — Auto-Scaling Masking Real Problems

Auto-scaling is genuinely useful, but it has a real operational trap: it can quietly compensate for an underlying problem — a memory leak, inefficient code, an unoptimized query — by simply adding more instances, rather than the problem ever actually getting fixed. Cost climbs steadily in the background while the root cause goes unaddressed, until the auto-scaling group eventually hits its configured maximum instance count — at which point the original symptom reappears, now at a larger and more urgent scale than if it had been investigated in the first place.

Hands-On Exercises