Compute

Why it matters

Virtual machines are the oldest and most flexible cloud building block. Even teams that mostly use containers or serverless still run VMs for build agents, databases, GPU training jobs and legacy software. A cloud engineer should be able to launch one, connect to it securely and clean it up without thinking twice. A machine learning engineer will rent GPU VMs for training and must know how to stop paying for them.

The core idea

A cloud VM (AWS EC2 instance, Azure Virtual Machine, Google Compute Engine instance) is a slice of a physical server that you rent by the second. When you launch one, you choose:

• Image: the starting disk, such as Ubuntu Server LTS or Amazon Linux. On AWS this is an AMI (Amazon Machine Image).
• Instance type (size): CPUs, memory and sometimes GPUs, for example t3.micro (2 vCPUs, 1 GiB). Families are tuned for general, compute, memory or GPU work.
• Storage: a block disk (AWS EBS volume) attached as the root drive.
• Network: which VPC and subnet the VM goes in, and whether it gets a public IP.
• Firewall: a security group that lists which ports are open to which sources.
• Key pair: the SSH public key placed on the VM so you can log in with your private key.

Instances move through states: pending, running, stopping, stopped, terminated. Stopped keeps the disk (and its charges); terminated deletes the instance, and by default its root disk too.

Worked example: a secure first launch

The safe pattern for a practice VM looks like this:

1. Pick the region you used in your pricing estimate.
2. Choose an Ubuntu Server LTS image and a size labelled Free tier eligible in the console.
3. Create a new key pair and download the private key file, for example practice-key.pem. You only get to download it once.
4. Create a security group that allows SSH (port 22) from My IP only, not from 0.0.0.0/0 (the whole internet).
5. Keep the default 8 GB disk.

Then connect from your own terminal (macOS, Linux or Windows PowerShell all include ssh):

chmod 400 practice-key.pem          # ssh refuses keys that others can read
ssh -i practice-key.pem ubuntu@203.0.113.25

Replace the address with your instance's public IPv4 address. The default user is ubuntu on Ubuntu images and ec2-user on Amazon Linux. Once in, the Linux skills from the previous course apply directly:

uname -a
df -h
curl -s http://checkip.amazonaws.com    # shows the public IP the internet sees

User data: automating setup

Most real VMs are not configured by hand. A user data script runs once at first boot:

#!/bin/bash
apt-get update -y
apt-get install -y nginx
echo "Hello from $(hostname)" > /var/www/html/index.html

Better still, you capture a configured VM as an image, or you describe the whole setup in infrastructure-as-code (covered in the DevOps & Cloud Delivery course). The goal is that any VM can be thrown away and rebuilt automatically.

Scaling compute

• Vertical scaling: stop the VM and change its size. Simple, but it has a ceiling and causes downtime.
• Horizontal scaling: run more identical VMs behind a load balancer, managed by an auto scaling group that adds or removes VMs on a schedule or based on CPU load.

Common mistakes

• Opening SSH to the whole internet. Bots scan every public IP within minutes.
• Losing the only copy of the private key, or committing it to Git.
• Choosing a large or GPU instance "to be safe" and leaving it running.
• Forgetting that a stopped instance's disk and public IP still cost money.
• Treating a VM as a pet that is hand-tuned and irreplaceable, instead of something you can rebuild from a script.

Quick recap

• A VM is defined by image, size, disk, network, security group and key pair.
• Allow SSH from your IP only, keep the private key safe and connect with ssh -i.
• Stop to pause compute charges; terminate (and delete leftover disks and IPs) to stop all charges.

Try it

The Do tab walks you through launching, connecting to and deleting a free-tier VM.