How it works
The explanation, with examples you can run.
What you own
| EC2 | ECS or EKS on EC2 | ECS or EKS on Fargate | Lambda | |
|---|---|---|---|---|
| OS patching | You | You (the nodes) | AWS | AWS |
| Scaling hosts | Auto Scaling group | Auto Scaling group or Karpenter | None | None |
| Unit you pay for | Instance-hours | Instance-hours | vCPU and memory per second | Requests and GB-seconds |
| Longest run | Unlimited | Unlimited | Unlimited | 15 minutes per invocation |
| Control | Everything (kernel, GPUs, disks) | Most | Less (no daemons on the host, fewer instance choices) | Least |
EC2 done properly
An instance is a launch template (image, instance type, security groups, IAM instance profile, user data) brought to life by an Auto Scaling group that spans several zones. The group replaces instances that fail health checks, scales on metrics, and rolls out a new template gradually with instance refresh. Keep no important state on the instance itself, so replacing it is routine rather than an incident. Instance metadata (IMDS) should be set to require IMDSv2 tokens, which blocks a class of server-side request forgery attacks that stole role credentials from IMDSv1.
Pricing models matter as much as instance types: on-demand for flexibility, Savings Plans or reserved capacity for a steady baseline, and Spot for interruptible work at a deep discount, with a two-minute warning before AWS reclaims the capacity.
Containers: ECS or EKS
- ECS is simpler and AWS-specific: task definitions, services, and deep integration with load balancers, IAM task roles and CloudWatch. There is no control plane to pay for or upgrade.
- EKS is Kubernetes. You get the portable API, its ecosystem (Helm, operators, Karpenter) and its complexity; AWS runs the control plane for an hourly fee, and you upgrade Kubernetes versions on its schedule.
Both run on EC2 nodes or on Fargate. Fargate removes node management and gives each task its own kernel boundary, at a higher price per vCPU and with some limits (no privileged containers or host daemons). A common mix is Fargate for most services and EC2 node groups for GPU, very large or cost-sensitive steady workloads.
Failure modes to plan for
- One zone, one instance: put capacity in at least two zones and size so that losing one still leaves enough.
- Capacity shortages: a specific instance type can run out in a zone. Allow several types (instance type flexibility) in groups and node pools.
- Image drift: instances that were patched by hand differ from the template; bake images instead and replace instances.
Check yourself
3 questions. Get them all right to finish this topic.
0 of 3 right so far. Get all three to finish this topic.