02 — EC2: Renting a Virtual Machine, Explained Honestly

The first EC2 console I opened looked like a wall of options, and "just rent a VM" didn't explain any of them. The frame that fixed it: an EC2 instance is a configurable recipe — instance type plus AMI plus storage plus keypair plus user data — and the only real decisions are how big, what image, and how much I'm willing to commit [1]. Everything else is the provider's plumbing. Once I saw it as a recipe rather than a machine, the long list of EC2 options stopped feeling random.

The instance itself

EC2 — Elastic Compute Cloud — is a web service that hands me a resizable virtual machine in seconds [1]. "Virtual" is the load-bearing word: I am not getting a physical box, I am getting a slice of one, carved out by a hypervisor alongside other tenants. The slice has CPU, memory, storage, and network capacity in proportions AWS decided when it designed the instance type.

The elasticity is the other half. I can launch one, launch a thousand, stop, start, terminate, resize — all through an API. The "server" is now a programmable object, which is the whole reason cloud changed how ops works.

Instance types: picking the recipe

Instance types are named families, and the naming encodes what they're optimized for [2]:

• General Purpose (t, m) — balanced CPU, memory, network. The default for web servers and small apps. t3.micro is the free-tier one most people meet first.
• Compute Optimized (c) — more CPU relative to memory. Batch processing, video encoding, dedicated game servers.
• Memory Optimized (r, x) — large RAM footprints. In-memory databases (the ElastiCache and Redis kind), big analytics.
• Storage Optimized (i, d) — fast, direct-attached storage. Data warehouses, NoSQL nodes that need local disk.
• Accelerated Computing (p, g, inf) — GPUs or custom accelerators. ML training, rendering.

The name itself is a decode key: c6g.large = compute-optimized, generation 6, Graviton (ARM) silicon, large size. Reading the name tells me the workload class without a docs lookup.

CPU credits: the burst trick

This caught me once. The t family (General Purpose burstable) doesn't run at full speed all the time — it earns CPU credits when idle and spends them to burst above a baseline when busy [3]. A t3.micro gets credits continuously; when it has them, it can burst to full-core performance; when the balance hits zero, it drops to baseline.

Two practical consequences: a mostly-idle small server costs almost nothing and still bursts when poked, but a t instance under sustained load will eventually throttle unless I enable Unlimited mode (which charges for credits over budget). The way of thinking: t instances are for spiky, low-average workloads, not steady-state ones. For steady load I want a non-burstable family.

Storage: EBS volumes

An instance needs a disk. That disk is EBS — Elastic Block Store — a network-attached volume that replicates inside its Availability Zone [4]. Key facts I had to nail down:

• EBS is AZ-scoped. A volume in us-east-1a cannot be attached to an instance in us-east-1b. Cross-AZ means snapshot-and-restore.
• It behaves like a physical drive: I format it with whatever filesystem, mount it, and it persists independently of the instance. Stop the instance, the volume stays. Terminate the instance, and (by default) the root volume goes too — unless I uncheck "delete on termination."
• It's designed for data that changes often: OS root disks, databases, anything needing frequent updates.

The durability model is "replicated within the AZ," which is why the well-architected answer to "what if the AZ fails" is multi-AZ plus EBS snapshots to S3.

Keypairs: the way in

To log in to a Linux instance I use a key pair — a public half AWS keeps, a private half I download once [5]. SSH presents the private key; the instance checks it against the public one. Two non-obvious rules:

• Keypairs are region-scoped. The key I made in us-east-1 does not exist in eu-west-1; I need a separate one per region.
• The private key is shown exactly once at creation. Lose it and the instance is effectively locked — recovery is ugly.

For Windows, the same key pair decrypts the administrator password the instance generates on first boot. The principle is identical: prove you have the private half.

Elastic IPs: a stable address

When I stop and start an instance, its public IP changes. That breaks DNS records and any caller holding the old address. An Elastic IP is a static IPv4 I reserve against my account and attach to whichever instance I want [6]. The address stays mine until I release it; I can re-point it to a replacement instance in seconds, which is the cheap version of failover.

The non-obvious part: Elastic IPs are free while attached to a running instance, and billed when allocated-but-unattached. The charge exists to discourage hoarding IPv4 space. If I'm paying for an EIP, it usually means I forgot to release one.

User data: boot-time scripting

User Data is a script (up to 16 KB) that runs as root when an instance first boots [7]. The classic use: install packages, pull code, register with a config service, start the app — so a freshly launched instance becomes a working node with no SSH required.

The detail that bit me: by default, user data runs only on the initial launch, not on stop/start or reboot. If I want it on every boot I have to opt in via cloud-init's per-boot mechanism. This is what makes "treat instances as cattle, not pets" actually operable — a new instance configures itself.

#!/bin/bash
yum update -y
yum install -y httpd
systemctl enable httpd
systemctl start httpd

That scrap of user data turns a bare Amazon Linux AMI into a running web server on first boot. No SSH, no manual steps.

Purchasing options: the price dial

This is where EC2 stops being "rent a VM" and becomes "trade commitment for discount." AWS sells the same compute under several pricing models [8]:

• On-Demand — pay per second/hour, no commitment. The default; expensive, zero risk. Right for short, unpredictable workloads.
• Reserved Instances / Savings Plans — commit to one or three years of consistent usage, get up to ~72% off. The right answer for steady-state baseline load.
• Spot — bid on AWS's spare capacity, get up to 90% off, but AWS can reclaim it with two minutes' notice. Right for batch, stateless, or anything checkpoint-able.
• Dedicated Hosts — a whole physical box just for me, for licensing or compliance that forbids multi-tenant virtualization.

The way of thinking I use: On-Demand is for the spikes, Reserved is for the baseline, Spot is for the tolerant. Most production bills are a mix. The biggest single cost mistake is running steady baseline load on On-Demand because nobody committed to a Reservation.

How I use this

EC2 is now the option of last resort, not the default. When I need a VM I ask first whether a managed runtime (Lambda, Fargate, ECS) would do — most stateless services don't need me to patch an OS. When I do reach for EC2, I pick the smallest instance type that fits, store nothing irreplaceable on local disk (EBS plus S3 snapshots), bake configuration into user data so the instance is disposable, and put baseline load on a Reservation with spikes on On-Demand or Spot. The instance is a recipe and a price decision — treating it as either more or less than that is where the bills and the outages come from.

References

[1] Amazon Web Services, "Amazon EC2 — concepts," EC2 User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html

[2] Amazon Web Services, "Amazon EC2 instance types," 2024. [Online]. Available: https://aws.amazon.com/ec2/instance-types

[3] Amazon Web Services, "Burstable performance instances and CPU credits," EC2 User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html

[4] Amazon Web Services, "What is Amazon EBS?," EBS User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/ebs/latest/userguide/what-is-ebs.html

[5] Amazon Web Services, "Amazon EC2 key pairs," EC2 User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html

[6] Amazon Web Services, "Elastic IP addresses," EC2 User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html

[7] Amazon Web Services, "User data scripts," EC2 User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html

[8] Amazon Web Services, "Instance purchasing options," EC2 User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html