1. What and Why
Goal: the mental model and the decision, before any syntax. By the end you should be able to tell a colleague why you'd reach for EC2 instead of Lambda or Fargate — and, more usefully, when you shouldn't reach for it at all.
One-sentence definition
Amazon EC2 (Elastic Compute Cloud) is a regional AWS service that rents you virtual machines by the second — you choose the CPU/memory shape, the disk image, and the network to place it in, and AWS gives you a running server with an IP address and full root access.
The word doing the work in that sentence is rents. EC2 is not a platform that runs your code for you; it hands you a machine and steps back. What happens on that machine — the OS patches, the runtime, the process supervisor, the log rotation — is yours. That is simultaneously EC2's greatest strength and the reason half the other compute services in this article exist.
The problem before it existed
The analogy: before EC2, getting a server was like buying a house. After EC2, it's like booking a hotel room — you take it for as long as you need it, you don't own the plumbing, and if you need twenty rooms next Tuesday you just book twenty rooms.
Concretely, standing up a new application in 2005 looked like this:
- Forecast demand 18 months out. You bought hardware for your peak traffic, which meant you paid for the Black Friday fleet all year and it sat idle at 8% utilisation in February.
- Procure and rack it. Purchase order, lead time measured in weeks, someone physically driving to a colocation facility to install the box, cable it, and configure the switch.
- Capital expenditure, not operating expenditure. The money left the business up front, before a single customer had used the thing. If the product failed, the servers were still yours.
- Failure was a person's problem. A dead disk or a failed PSU meant a hands-and-eyes ticket and a drive across town.
EC2 collapsed all of that into an API call. The three shifts that actually mattered:
| Before | After EC2 |
|---|---|
| Weeks of lead time | Seconds — RunInstances returns and the machine boots |
| Pay for peak, all year | Pay per second, only while it runs |
| Capacity is a fixed ceiling you bought | Capacity is elastic — scale out when traffic arrives, scale in when it leaves |
| Hardware failure = truck roll | Hardware failure = terminate the instance and launch another |
That last row is the cultural change, and it's the one interviewers probe. EC2 made servers disposable. Once a machine is something you can replace in 60 seconds, you stop lovingly repairing them (the "pets" model) and start treating them as interchangeable, rebuildable units (the "cattle" model). Every modern practice — immutable AMIs, auto-scaling groups, blue/green deploys, chaos testing — descends from that one property.
Where it sits
Category: Compute. EC2 is the foundational service in it — and more than that, it's the substrate under much of the rest 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 underlying hardware fleet, fully hidden. Learning EC2's vocabulary pays dividends across the entire catalogue.
The confusables
The interesting question is never "what is EC2" — it's "why not one of these instead?" The honest framing is a spectrum of how much of the stack you're responsible for:
More control, more responsibility ←──────────────────────────────→ Less control, less ops
EC2 ECS on EC2 ECS/EKS on Fargate Lambda
(VM) (containers, (containers, (functions,
your hosts) no hosts) no servers)| Use this, not EC2, when… | Service | Why |
|---|---|---|
| Your workload is event-driven, short-lived, and spiky — a few hundred ms per request, idle much of the day | Lambda | You pay only for execution time, scaling is automatic and instant, and there is no OS to patch. Paying for an always-on EC2 instance to serve occasional events is pure waste. |
| You've containerised the app and don't want to manage the machine underneath it | Fargate (via ECS or EKS) | Fargate gives you the container abstraction with no host to patch, scale, or secure. You give up host-level tuning and pay a premium per vCPU-hour, but you delete an entire operational surface. |
| You need a simple VPS with predictable flat monthly pricing — a WordPress site, a small dev box | Lightsail | Lightsail is EC2 underneath, wrapped in a simplified console with bundled storage/transfer and a fixed monthly price. Less power, far less to think about. |
| The job is a batch of independent compute tasks with no long-lived service | AWS Batch | It provisions, queues, and tears down the compute for you (on EC2 or Fargate), which is exactly the orchestration you'd otherwise write yourself. |
| It's a git push and you want a URL | App Runner / Elastic Beanstalk | Both provision the underlying compute for you. Beanstalk still exposes the EC2 instances; App Runner doesn't. |
And the inverse — reach for EC2 when:
- You need a specific OS, kernel version, or kernel module — legacy Windows, a custom-compiled kernel, a GPU driver stack, an FPGA.
- The workload is long-running and steadily busy. Above roughly the point where a Lambda would be
warm all the time anyway, a reserved or Savings-Plan-covered instance is dramatically cheaper.
⚠️ verify against current AWS docs— the crossover point moves with pricing. - You need hardware characteristics you can name: GPUs for training or inference, high-memory instances for an in-memory database, local NVMe for a scratch disk, bare-metal for a nested hypervisor or a licence that requires it.
- You're lifting and shifting an existing application that assumes a real filesystem, a fixed IP, long-lived local state, or a daemon that has to be running.
- A licensing model is tied to cores or sockets and you need to control placement (dedicated hosts).
When NOT to use it
This is the section that separates real understanding from a marketing summary. EC2 is the default answer that is often the wrong answer.
1. As a substitute for a managed service. Running your own PostgreSQL, Redis, Kafka, or Elasticsearch on EC2 is legal and occasionally correct — but you've just signed up for backups, failover, patching, version upgrades, and 3 a.m. pages. RDS, ElastiCache, MSK, and OpenSearch cost more per hour and enormously less per year in engineer-hours. Only self-manage when you need a version, extension, or configuration knob the managed service genuinely doesn't expose — and be able to name it.
2. For bursty, low-duty-cycle workloads. An instance running 24/7 to handle a request every few minutes is a bill you're paying for idle. That's Lambda's home turf.
3. As a pet. If your instance has a hostname people know, a hand-configured state nobody documented, and a reputation for being fragile, EC2 has failed you — but the failure is architectural, not the service's. If it can't be rebuilt from an AMI plus code, it's a liability. Instances get retired by AWS, hardware degrades, and AZs have bad days.
4. When the real requirement is "make it someone else's problem." Every EC2 instance you own is an OS you patch, an SSH surface you secure, a set of CloudWatch alarms you write, and an entry in your CVE-response process. That cost is invisible on the bill and very visible in your on-call rotation.
5. For static content. Serving static files from a web server on EC2 when S3 + CloudFront exists is paying for a computer to do a filesystem's job — with worse durability and no edge caching.
The mental model to carry forward
Three ideas do most of the work in the rest of this topic:
- An instance is a rental, and it's disposable. Design so that terminating any single instance is a non-event. Everything in Deployment and the Auto Scaling material in Integrations assumes this.
- Compute and storage are separate. The machine is one thing; the EBS volume attached to it over the network is another. They fail independently, they're billed separately, and one can outlive the other. This trips people up constantly — see the instance-store vs. EBS distinction in Core Concepts and the stop-vs-terminate discussion in Architecture.
- The instance type is a shape, not a tier.
m,c,r,g,iaren't good/better/best — they're different CPU-to-memory-to-IO ratios. Picking the family is a workload-profiling decision, and it's where most EC2 overspend originates.
Check yourself
You've got this section if you can answer these without scrolling up:
- Why did "servers are disposable" change how software is deployed, and what practice does it enable?
- Give one workload where Lambda beats EC2 on cost, and one where EC2 beats Lambda.
- Name two things you become responsible for the moment you launch an instance that you don't own with Fargate.
- What's the strongest argument against running your own database on EC2? What's a legitimate counter-argument?
Next: Core Concepts defines every noun you'll meet in the launch wizard, so nothing in the console is a mystery.