EC2
EC2 is a computer you rent by the second. You pick a size, a disk image, and a network to put it in, and a few seconds later you have a Linux or Windows machine with an IP address and root access. Everything else in EC2 exists to answer the two questions that follow: how do I get more of them when traffic grows, and how do I stop paying for the ones I don't need?
Assumes Foundations. Accounts, the API model, IAM policy evaluation, regions and Availability Zones, ARNs, tags, and quotas are platform-wide and covered there. This topic links back rather than re-explaining them.
What it actually is
EC2 rents virtual machines. That's the whole service in one line — and the word doing the work is rents. EC2 does not run your code for you; it hands you a machine and steps back. The OS patches, the runtime, the process supervisor, the log rotation, the CVE response: all yours. That is simultaneously EC2's greatest strength and the reason most of the rest of the AWS compute catalogue exists.
The problem it solved wasn't "servers are hard." It was capital risk and lead time. Before EC2 you forecast peak demand eighteen months out, bought hardware for that peak, waited weeks for it to arrive and be racked, and then paid for it year-round while it sat at 8% utilisation in February. EC2 turned a capital expense with a fixed ceiling into an operating expense that tracks demand, and collapsed weeks of procurement into an API call.
The deeper consequence is the one worth carrying: EC2 made servers disposable. Once a machine can be replaced in sixty seconds, you stop lovingly repairing individual boxes and start treating them as interchangeable units. Auto Scaling, immutable machine images, blue/green deployments, and chaos testing all descend from that single property. Most EC2 mistakes — in design, in operations, and in interviews — trace back to treating an instance as something precious.
EC2 is also the substrate under a large part of AWS. EKS worker nodes, EMR cluster nodes, and (unless you use Fargate) ECS container hosts are all EC2 instances — sometimes in your account where you can see them, sometimes in an AWS-managed account where you can't. RDS runs on the same hardware fleet, fully hidden. Its vocabulary, its failure modes, and its capacity errors recur throughout the catalogue, which is why EC2 is worth learning properly even if you never launch one directly.
Key facts at a glance
| Category | Compute |
| Scope | An instance lives in one Availability Zone, in one region. AMIs and snapshots are region-scoped; EBS volumes are zone-scoped |
| Billed by | The second while running (60-second minimum on Linux), plus storage, data transfer, and public IPv4 addresses — the extras are frequently larger than the compute line |
| Availability posture | A single instance is not highly available. Availability comes from the pattern: multiple instances, multiple AZs, behind a load balancer, in an Auto Scaling group |
| Durability posture | EBS replicates within one AZ — durable, but not backed up. Instance store is ephemeral and will be lost |
| Almost always paired with | VPC, EBS, IAM, Elastic Load Balancing, Auto Scaling, CloudWatch, Systems Manager |
| Main alternatives | Lambda (event-driven), Fargate (containers, no hosts), Lightsail (simplified VPS), Batch (job queues) |
| The recurring trap | Treating an instance as a pet — hand-configured, undocumented, irreplaceable |
When to reach for it
- You need a specific OS, kernel, or driver stack — legacy Windows, a custom kernel, GPU drivers.
- The workload is long-running and steadily busy. Past the point where a function would be warm anyway, committed EC2 capacity is dramatically cheaper.
- You need hardware you can name: GPUs for training or inference, high memory for an in-memory database, local NVMe for scratch space, bare metal for nested virtualisation or a licence that demands it.
- You're lifting and shifting something that assumes a real filesystem, a fixed IP, or a resident daemon.
- Licensing is tied to cores or sockets and you need control over physical placement.
When not to
- As a substitute for a managed service. Self-managing PostgreSQL, Redis, or Kafka on EC2 means owning backups, failover, patching, and version upgrades. Occasionally correct — but be able to name the specific feature the managed service doesn't give you.
- For bursty, low-duty-cycle work. An instance running around the clock to handle a request every few minutes is a bill for idle time. That's Lambda's territory.
- When the real requirement is "make it someone else's problem." Every instance is an OS you patch, an access surface you secure, and alarms you write. None of that appears on the bill; all of it appears in your on-call rotation.
- For static content. Serving files from a web server on EC2 when S3 and CloudFront exist is paying a computer to do a filesystem's job, with worse durability and no edge caching.
Contents
| # | Sub-topic | What it covers |
|---|---|---|
| 1 | What & Why | The problem EC2 solves, where it sits vs. Lambda / ECS / Fargate / Lightsail, and the honest anti-patterns |
| 2 | Core Concepts | Instances, AMIs, instance types and families, EBS vs. instance store, key pairs, security groups, ENIs, instance profiles, purchase options |
| 3 | Architecture | Control plane vs. data plane, the Nitro system, a traced launch, network-attached storage, scaling ceilings, and named failure modes |
| 4 | Getting Started | Launch one instance and connect to it — Console, CLI, and a minimal Terraform snippet, plus teardown |
| 5 | Deployment | Launch template + Auto Scaling group + load balancer: Terraform, Ansible, CloudFormation/CDK, CI/CD with OIDC, environments, rollback, drift |
| 6 | Integrations | VPC, EBS, ELB, Auto Scaling, IAM, CloudWatch, Systems Manager, S3, Secrets Manager, RDS, EventBridge — and what runs on EC2 |
| 7 | Production | Security, the real cost model, quotas, what to alarm on, reliability posture, and a readiness checklist |
| 8 | Interview Questions | Fifteen questions across three tiers, with answer keys |
| 9 | Glossary & Cheatsheet | Sixty terms, grouped commands, symptom-to-metric and error-to-fix lookups |
New to EC2? Start with What & Why.
Reading paths
- Never touched EC2: 1 → 2 → 4. You'll finish with a running instance and the vocabulary to describe it.
- Interview preparation: 2 → 3 → 7 → 8. Concepts, then mechanics, then operations, then the questions.
- Need to ship something this week: 4 → 5 → 7. Hello-world, then the Terraform that survives review.
- Chasing a cost problem: 7, then the purchase-options section of 2.
- Debugging a live issue: 9's symptom-to-metric table, then 3's failure modes.
On numbers. Instance types, quotas, and prices change constantly. Anywhere this topic states a volatile figure it is either labelled "as of writing" or flagged
⚠️ verify against current AWS docs. Treat those as prompts to check, not facts to memorise.