Amazon Web Services
Core Compute — EC2 & Auto Scaling
Rent virtual servers on demand and scale them horizontally behind a load balancer.
EC2 gives you virtual machines. The interview is rarely about launching one — it is about the fleet around it.
Renting cars from an agency instead of buying a fleet. You pick the model you need, take more during busy season and return them when quiet — and if one breaks down the agency swaps it for a working one automatically.
Key Concepts
1
Instance families are named for what they are tuned for.
M, T general purpose web and app servers (T bursts, cheaply)
C compute optimised encoding, simulation, CPU-bound work
R, X memory optimised caches, in-memory databases
I storage optimised high local NVMe IOPS
G, P accelerated GPUs: inference, training2
An instance boots from an AMI — a disk image — into a subnet in one Availability Zone.
3
One instance is never the answer. An Auto Scaling Group keeps a fleet at a target size across two or
three AZs, replaces anything that fails its health check, and adds or removes capacity from a metric:
4
target tracking keep average CPU at 50%
step scaling +2 instances when CPU > 70% for 5 minutes
scheduled scale up before a known daily peak5
Target tracking is the one to name. You state the outcome you want and the group works out the capacity,
rather than you hand-tuning thresholds.
6
Multi-AZ is what makes it fault tolerant. Instances in one AZ only means a single data centre takes the
service down, however many instances are running.
7
Pricing is a lever, not a detail.
On-Demand no commitment, highest rate -- spiky or unknown
Savings Plans commit $/hour for 1-3 years, up to ~72% off
Spot spare capacity, up to 90% off, reclaimed with
two minutes' notice
Graviton ARM, often 20-40% better price for performance8
The usual shape: baseline on a Savings Plan, burst on On-Demand, batch and CI on Spot.
9
What stays your responsibility. Patching, the OS, and the AMI pipeline — unlike Lambda or Fargate, where
there is no operating system to maintain. That trade is the reason to choose EC2 deliberately rather than by
default.
10
What the interviewer is probing.1. "Your Auto Scaling Group is in one AZ. What is the risk and the fix?" Probing: whether
multi-AZ is instinct. Stalls: "It scales, so it is fine." Moves up: a single AZ failure takes
the whole service down however many instances run; spread the group across two or three.
11
2. "When would you use Spot instances, and when would you not?" Probing: the interruption
model. Stalls: "Always, they are cheaper." Moves up: interruptible batch and CI, because
reclamation comes with two minutes' notice; never for stateful work or anything that must finish.
12
3. "What is target tracking and why prefer it to step scaling?" Probing: the scaling policy.
Stalls: "They are the same." Moves up: you state the outcome — keep CPU at 50% — and the group
computes capacity, rather than hand-tuning thresholds and step sizes.
13
4. "What do you still own with EC2 that you do not with Fargate or Lambda?" Probing: whether
the choice is deliberate. Stalls: "Nothing much." Moves up: the operating system, patching and
the AMI pipeline — which is the reason to choose EC2 rather than default to it.