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, training
2
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 peak
5
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 performance
8
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.