Learn Cloud Computing - Cloud Compute Services (Virtual Machines)

#Introduction

In episode 5, you built a VPC complete with public and private subnets. But a house without inhabitants is useless. Episode 6 covers the cloud's main "inhabitants": virtual machines (VMs) — called EC2 instances on AWS, Compute Engine on GCP, and Virtual Machines on Azure.

We'll look at how VMs are born on top of hypervisors, why VMs are grouped into several families, how purchasing models dramatically affect cost, and close with a comparison of the three major providers.

#From Physical to Virtual: The Role of the Hypervisor

A VM is a fully emulated computer: virtual CPU, memory, disk, and virtual network devices — all running on top of one physical machine shared by many tenants. The intermediary that divides the physical machine is called a hypervisor.

There are two types of hypervisor:

Type 1 (bare metal): runs directly on the hardware, with no guest operating system underneath. Examples: KVM, ESXi, Hyper-V. This is what all major cloud providers use because it has the smallest overhead.
Type 2 (hosted): runs on top of an existing operating system. Examples: VirtualBox, VMware Workstation. Suitable for local labs, not for cloud production.

Note

The hypervisor is like an apartment building manager: one physical building is divided into many rental units, each fully isolated from the others. A tenant in the next unit can't read your data because the hypervisor strictly isolates virtual memory, disk, and networking. This power is what lets the cloud share hardware without interfering with each other.

The practical consequence of virtualization is elasticity: adding a new VM only takes minutes, not the weeks that buying a physical server takes. You can scale capacity up when traffic rises and down when it's quiet — something impossible to do easily in the on-premise era.

#Instance Categories: Pick the Machine That Matches Your Workload

Not all workloads are the same. A web server needs a balance of CPU and RAM; video encoding needs very strong CPUs; large databases need lots of memory; machine learning training needs GPUs. That's why every provider groups VMs into instance families, each with a different resource balance:

General purpose: a balance of CPU/RAM/memory. Suitable for web servers, internal applications, and development environments.
Compute optimized: a higher CPU ratio. Suitable for batch processing, video encoding, and scientific computing.
Memory optimized: very large RAM. Suitable for databases, caches, and in-memory analytics.
Storage optimized: high disk throughput. Suitable for data warehouses, logging, and I/O-heavy workloads.
Accelerated computing (GPU): graphics cards for machine learning, rendering, and high-performance computing.

Family	Focus	AWS examples	GCP examples	Azure examples
General purpose	Web server, applications	`t3.medium`, `m6i.large`	`e2-medium`, `n2-standard-2`	`B2s`, `D2s_v3`
Compute optimized	High CPU	`c6i.2xlarge`	`c3-highcpu-8`	`F4s_v2`
Memory optimized	Large RAM	`r6i.2xlarge`	`m3-memory-16`	`E8s_v3`
Storage optimized	High I/O	`i4i.2xlarge`	high-memory + local SSD	`L8s_v2`
Accelerated (GPU)	ML, rendering	`g5.2xlarge`, `p4d.24xlarge`	`a2-highgpu-1g`	`NC6s_v3`

Instance names aren't just random codes — on AWS, the first letter shows the family (t for general, c for compute, r for memory), the number shows the generation, and the suffix shows the size. Understanding this pattern helps you "read" resource needs while avoiding two common mistakes: paying too much for resources you don't use, or choosing an instance too weak that the application slows down.

#Purchasing Models: On-Demand, Reserved, and Spot

Compute cost is one of the biggest line items on a cloud bill. Fortunately, all providers offer three purchasing models with the same trade-offs:

Model	Commitment	Discount	Risk	Best for
On-demand	None	0 percent	None	Unexpected load, development
Reserved / Savings Plans	1-3 years	around 30-70 percent	Overcommit if load drops	Stable workloads running 24/7
Spot / Preemptible	None	up to around 90 percent	Instance can be reclaimed anytime	Batch, ML training, stateless workloads

The on-demand model is the full per-second rate — flexible, but the most expensive. The reserved model (Reserved Instances or Savings Plans on AWS, Committed Use Discount on GCP, Reserved VM Instances on Azure) offers big discounts in exchange for a 1-3 year commitment — ideal for databases and applications that genuinely run continuously.

Warning

The spot model (Spot Instances on AWS, Preemptible VMs on GCP, Azure Spot Virtual Machines) offers discounts of up to around 90 percent on one condition: the provider may reclaim the instance at any time — on AWS you get a two-minute notice, on GCP thirty seconds. Never put a database or important data on a spot instance. Spot is only safe for stateless workloads that can be restarted from scratch: batch processes, rendering, or model training whose checkpoints are stored elsewhere.

Tip

A strategy many teams use: reserved covers the base load that's genuinely stable, then spot handles bursts. This way you pay a discounted price for capacity that will definitely be used, and pay very little for flexible capacity that can afford to be lost.

#Running Your First VM with the AWS CLI

Time to practice. The command aws ec2 run-instances creates a new VM in an existing subnet:

Creating an EC2 instance

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.medium \
  --key-name lab-key \
  --subnet-id subnet-0abc123 \
  --security-group-ids sg-0abc123 \
  --associate-public-ip-address

A brief explanation of each flag:

--image-id determines the initial operating system (AMI). Think of it as the computer's initial "template".
--instance-type determines the VM size, for example t3.medium, which belongs to the general purpose family.
--key-name selects the SSH key pair for logging into the server — your primary login access.
--subnet-id places the VM in a specific subnet; a public subnet means it gets a public IP.
--security-group-ids attaches firewall rules that allow specific traffic in.

Important

In episode 4 we covered IAM and temporary credentials — now that principle meets practice. Never create an instance with a static password or a shared key. Use a separate key pair per environment, then combine it with instance roles and temporary credentials so access can always be revoked and rotated.

#Comparing EC2, Google Compute Engine, and Azure VMs

Although the concept is the same, the three providers give different names and rules:

Aspect	AWS EC2	GCP Compute Engine	Azure Virtual Machines
Instance naming	`t3`, `m6i`, `c6i`	`e2`, `n2`, `c3`	`B`, `D`, `E`, `F`
Commitment discount	Reserved / Savings Plans	Committed Use Discount	Reserved VM Instances
Spot model	Spot Instances	Preemptible VMs	Azure Spot Virtual Machines
Billing	Per second (minimum 60 seconds)	Per second (minimum 60 seconds)	Per second

Tip

All providers bill per second with a one-minute minimum — turning on an instance "just for a moment" no longer wastes money like the per-hour billing era. However, be careful with quotas: every account has a vCPU limit per region. You need to request a quota increase before pursuing large capacity, so plan from the start, not when you're under pressure.

#Conclusion

In this episode 6, we've covered the foundations of cloud compute: the hypervisor as the divider of physical hardware, five instance categories each designed for different workloads, and three purchasing models with clear cost and risk trade-offs. You also saw the aws ec2 run-instances command and the comparison map of EC2, Compute Engine, and Azure VMs.

The keys to take away:

The hypervisor is the reason one physical machine can host many tenants with full isolation.
Choose the instance family based on your workload — picking the wrong category means paying more or slowing down.
On-demand is flexible, reserved is cheap for stable loads, spot is very cheap but can disappear at any time.

A running VM without storage is just a machine without data. In episode 7, we'll discuss Cloud Storage Solutions (Block, File & Object Storage) — EBS and Persistent Disk for block, EFS and Filestore for file, and S3, Cloud Storage, and Blob Storage for object, complete with lifecycle policies that automate cheap storage.