EC2 and choosing an instance type

Pick the family by the bottleneck, the size afterwards

Instance families exist because workloads run out of different things. General purpose is balanced and is the sensible default. Compute optimized gives a high ratio of vCPU to memory for processor-bound work. Memory optimized gives the most memory per instance, for large in-memory datasets, caches and big relational databases. Storage optimized exists for very high local disk throughput and IOPS. Accelerated computing adds GPUs or purpose-built chips for massively parallel maths.

The exam asks this by describing a resource profile and offering four families, so read the stem for what runs out first. A 400 GB dataset loaded entirely into memory hits the memory ceiling however many vCPUs an option promises; a job that saturates processors while touching almost no data is the mirror image. Getting the FAMILY right matters more than getting the size right, because the size is a decision you can revisit and the family is the one that makes an instance the wrong shape.

The disk that disappears

An instance store is physically attached to the host your instance happens to be running on. That is what makes it the fastest storage available and what makes it ephemeral: stopping or terminating the instance releases the host, and the data goes with it. A REBOOT keeps the same host and therefore keeps the data, which is precisely why this failure mode can hide for months — everything survives every restart until the first stop.

Amazon EBS is network-attached instead. The volume exists independently of the instance, follows it through a stop and start, can be detached and attached elsewhere in the same Availability Zone, and can be snapshotted. The rule that follows is short: instance store for anything you could lose without caring, EBS for anything else. Encryption is not part of this story at all — it decides who can read the data, never whether the data persists.

Baking an image beats running a script

An Amazon Machine Image captures the operating system, its configuration and the software installed on it, so an instance launched from it starts in a known state in the time it takes to boot. That is the answer whenever a stem complains both that provisioning is slow and that no two servers end up quite alike, because it fixes both halves at once: the forty-minute script is spent once, at bake time, rather than at every launch where a slow package mirror can make one server subtly different again.

User data is the neighbour that looks like the same thing and is not. It automates the work but still performs it on every launch, so it belongs to the short, environment-specific tail rather than the bulk. An EBS snapshot is a different object again: it copies a volume's data, and an AMI references snapshots but also carries the metadata AWS needs in order to LAUNCH something. "Attach the snapshot to each new instance" is the option written to catch a candidate who has merged the two.

Rightsizing is a decision you get to change

Two properties of EC2 make sizing an ongoing activity rather than a bet placed on day one. Burstable general purpose instances — the T family — accumulate credits while they are idle and spend them during short bursts, which prices an idle-with-spikes workload such as a small internal wiki honestly instead of charging for a peak that lasts ten minutes a day. And an EBS-backed instance can be moved to a different instance type by stopping it and starting it again, so an instance chosen badly is corrected rather than lived with.

Price scales with size, roughly in proportion, which is why oversizing is the most common avoidable EC2 cost there is. Amazon CloudWatch metrics show what an instance actually used and AWS Compute Optimizer turns that history into a recommendation. The belief the exam probes is the opposite one — that the type is fixed for the life of the instance and must therefore be chosen for the worst case now — and it is wrong.