AWS EC2: the workhorse you should understand before anything else
AWS EC2: the workhorse you should understand before anything else
Series: AWS Field Guide · Part 2 of 6 — Compute This series: 01 — Overview · 02 — EC2 · 03 — Lambda · 04 — ECS & Fargate · 05 — EKS · 06 — Wrap-up
The scenario
You need to run a long-lived background worker. It needs 16GB of RAM, a specific version of a library, and it has to stay up indefinitely. Lambda times out after 15 minutes. ECS adds container overhead your team isn't ready for yet. You just need a server.
That's EC2. And it's been the backbone of AWS since 2006 for exactly this reason.
TL;DR: EC2 gives you a virtual machine in the cloud — pick your OS, size, and region, and you have a server running in under two minutes. You control everything; you're also responsible for everything. Understanding EC2 is foundational — every other AWS compute service is an abstraction built on top of it.
The problem it solves
Before cloud computing, getting a server meant ordering hardware, waiting weeks for delivery, racking it in a data centre, and hoping you got the sizing right. Sizing wrong in either direction was painful — too small and you were throttled; too large and you'd paid for metal that sat idle.
EC2 replaced that with virtual machines you can provision in seconds, scale up or down at will, and return the moment you're done with them. The economic model shifted from capital expenditure (buying servers) to operational expenditure (renting compute by the second).
Core concepts
Instances
An EC2 instance is a virtual machine. When you launch one, you choose:
Instance type — the hardware profile (CPU, RAM, storage, network capacity)
AMI (Amazon Machine Image) — the OS and pre-installed software snapshot it boots from
Region and Availability Zone — where in the world it runs
Storage — the attached EBS volume(s) it uses as a hard drive
Each instance runs in isolation from others, on shared physical hardware managed entirely by AWS.
Instance families
EC2 instance types follow a naming convention: m7g.xlarge breaks down as:
m— the family (general purpose)7— the generation (newer = better price/performance)g— the processor variant (g= AWS Graviton,a= AMD, blank = Intel)xlarge— the size
The main families and their purpose:
| Family | Examples | Best for |
|---|---|---|
| General purpose | t3, m7g |
Web servers, APIs, dev environments |
| Compute optimised | c7g, c6i |
CPU-heavy workloads, batch processing |
| Memory optimised | r7g, x2idn |
Databases, in-memory caches, analytics |
| Storage optimised | i4i, d3 |
High I/O databases, data warehousing |
| Accelerated | p4, g5 |
ML training, GPU rendering |
Start with t3 or m7g for most workloads. Only move to a specialised family when you have a measured reason to.
AMIs
An AMI is a snapshot of a configured system — OS, installed packages, configuration files. When you launch an instance, AWS boots it from the AMI you select.
AWS provides official AMIs (Amazon Linux 2023, Ubuntu, Windows Server), the Marketplace has third-party options (pre-configured databases, security appliances), and you can create your own. Custom AMIs are the right move once your instance configuration stabilises — they make scaling and disaster recovery dramatically faster.
Security groups
Security groups are EC2's firewall. They control inbound and outbound traffic at the instance level. Unlike traditional firewalls, they're stateful — if you allow an inbound connection, the response is automatically allowed out.
The golden rule: start with the minimum required ports. Opening port 0–65535 to 0.0.0.0/0 because "I'll tighten it later" is how breaches happen.
Key pairs
SSH access to EC2 instances is managed via key pairs — a public key stored by AWS, a private key you hold. Lose the private key and you lose SSH access. Store it somewhere safe immediately after download.
Minimal working example
Launch an EC2 instance via the AWS CLI and connect to it:
# Launch an Amazon Linux 2023 instance (t3.micro — free tier eligible)
aws ec2 run-instances \
--image-id ami-0c55b159cbfafe1f0 \
--instance-type t3.micro \
--key-name my-key-pair \
--security-group-ids sg-0a1b2c3d4e5f \
--subnet-id subnet-0a1b2c3d \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=my-first-ec2}]'
# Get the public IP once it's running
aws ec2 describe-instances \
--filters "Name=tag:Name,Values=my-first-ec2" \
--query "Reservations[*].Instances[*].PublicIpAddress" \
--output text
# SSH in
ssh -i ~/.ssh/my-key-pair.pem ec2-user@<public-ip>
Pricing model
EC2 pricing has three main modes — choosing the right one for each workload is one of the highest-leverage cost decisions you'll make on AWS.
On-Demand
Pay for compute by the second, no commitment. The most expensive per-hour rate, but zero risk. Use this for development, testing, and workloads with unpredictable usage patterns.
Example: a t3.medium (2 vCPU, 4GB RAM) in us-east-1 costs ~\(0.0416/hour, or roughly \)30/month if running 24/7.
Reserved Instances
Commit to a 1- or 3-year term in exchange for up to 72% off On-Demand pricing. Payment options range from all upfront (cheapest) to no upfront (more flexible). Use for stable, predictable workloads that run continuously.
Example: that same t3.medium on a 1-year reserved term (all upfront) drops to ~\(0.026/hour — saving around \)90/year on a single instance.
Spot Instances
Bid on unused EC2 capacity at up to 90% off On-Demand. The catch: AWS can reclaim Spot Instances with two minutes' notice when capacity is needed elsewhere. Use for fault-tolerant, interruption-safe workloads — batch processing, CI/CD runners, stateless workers.
Example: the same t3.medium Spot price fluctuates but typically runs around $0.013/hour — less than a third of On-Demand.
Savings Plans
A newer alternative to Reserved Instances — commit to a dollar-per-hour spend across EC2, Lambda, and Fargate combined, and get similar discounts with more flexibility. Compute Savings Plans apply across instance families, regions, and sizes, making them more flexible than Reserved Instances. Generally the better default for teams who want cost savings without locking into specific instance types.
When to use EC2 (and when not to)
Use EC2 when:
✅ You need full control over the OS, kernel, or runtime
✅ The workload runs indefinitely (long-lived processes, always-on servers)
✅ You need specialised hardware (GPUs, high-memory, bare metal)
✅ You're running legacy applications that can't be containerised easily
✅ You need persistent local storage with high I/O (instance store volumes)
✅ Your team is more comfortable with servers than containers or serverless
Don't use EC2 when:
❌ The workload is short-lived and event-driven — Lambda is cheaper and simpler
❌ You're running containers and want managed orchestration — ECS + Fargate removes the OS management burden
❌ You want zero infrastructure management — serverless or PaaS options are a better fit
❌ Your workload is spiky and unpredictable — Lambda or Fargate scale to zero; EC2 doesn't
❌ You're building something small and simple — the operational overhead isn't worth it below a certain scale
Common gotchas
1. Forgetting to stop instances you're not using. A stopped EC2 instance doesn't charge for compute — but it still charges for attached EBS storage. An unused instance left running overnight in a workshop has derailed more than a few AWS budgets.
2. The On-Demand trap for steady workloads. Teams often launch On-Demand instances, forget to revisit pricing, and run them that way for years. If a workload has been running 24/7 for six months, it should be on a Reserved Instance or Savings Plan. The savings are too large to leave on the table.
3. Assuming all instance types are available in all regions. Newer instance types (especially GPU instances) are often only available in a subset of regions. Plan your region selection before committing to a specific instance family.
4. EBS volume deletion on termination. By default, the root EBS volume attached to an EC2 instance is deleted when the instance is terminated. If you terminate instead of stopping by mistake, the data is gone. Change the default or snapshot regularly.
5. Elastic IP address charges. Elastic IPs (static public IPs) are free when attached to a running instance. The moment the instance stops or the IP is unattached, AWS charges for it. Unattached Elastic IPs silently accumulate on bills.
Compared to the alternatives
EC2 vs Lambda
Lambda is cheaper and easier for short, stateless tasks. EC2 wins the moment you need a long-running process, OS-level access, or anything that doesn't fit an event-driven model. They're not competitors — most architectures use both.
EC2 vs ECS + Fargate
If your workload is containerised, Fargate removes the OS management burden entirely. EC2 is still the right choice when you need specific hardware, host-level networking, or fine-grained control over the underlying machine. For new containerised workloads with no special requirements, Fargate wins on simplicity.
EC2 vs DigitalOcean Droplets / Linode
For simple use cases (a small web app, a dev server), managed VPS providers like DigitalOcean are often simpler to use and cheaper at small scale. EC2 pays off when you need deep AWS integration — IAM roles, VPC networking, tight coupling with S3, RDS, and the rest of the AWS ecosystem.
Key takeaways
EC2 is a virtual machine you fully control — OS, runtime, networking, storage. That control comes with operational responsibility.
Instance families exist for different workload profiles. Start general purpose (
t3,m7g); move to specialised only when you have data to justify it.Pricing mode matters enormously: On-Demand for flexibility, Reserved/Savings Plans for steady workloads, Spot for fault-tolerant batch work.
The most common EC2 mistakes are cost-related: leaving instances running, staying on On-Demand too long, and ignoring unattached Elastic IPs.
EC2 is foundational. Even if you never manage an EC2 instance directly, understanding it makes ECS, EKS, and the rest of AWS compute legible.
Up next
Part 3 → AWS Lambda: the serverless sweet spot (and where it falls apart)
We go deep on Lambda — the event-driven model, invocation types, concurrency, cold starts, and the hidden costs that bite teams who default to serverless for everything.
Previously
Part 1 → AWS Compute: picking the right engine for your workload
Part of the AWS Field Guide series. Tags: #aws #ec2 #cloud #compute #aws-field-guide
