EC2 instance families, decoded

An EC2 instance type such as m7g.xlarge looks arbitrary the first time you see it. It is not. Every character is doing a job, and once you can decode the pattern you can look at any instance name and know roughly what it is for, what generation it belongs to, and what kind of processor is underneath.

This matters commercially as well as technically. The gap between a well-chosen instance and a poorly-chosen one of the same price is routinely a factor of two in useful work.

Reading the name

Take m7g.xlarge apart:

• m is the family. It says what the instance is optimised for.
• 7 is the generation. Higher is newer, and newer is usually both faster and cheaper per unit of work.
• g is an attribute. Here it means Graviton, an Arm processor. Other letters carry other meanings: a for AMD, i for Intel, n for enhanced networking, d for local NVMe storage.
• xlarge is the size within the family.

So m7g.xlarge is a seventh-generation general-purpose instance on Arm, one step above large.

The families that matter

t — burstable. These have a baseline CPU allocation and earn credits when idle, which they spend when busy. Perfect for workloads that are quiet most of the time and occasionally need a burst: a low-traffic web server, a development box, a small internal tool. Dangerous for anything with sustained load, because once the credits run out performance drops to the baseline, which is a fraction of a full core.

m — general purpose. A balanced ratio of vCPU to memory, conventionally 1:4. This is the correct default when you do not yet know your workload’s shape. Most application servers live here.

c — compute optimised. More CPU per unit of memory, conventionally 1:2. Batch processing, video encoding, simulation, busy API servers that are CPU-bound rather than waiting on a database.

r — memory optimised. More memory per vCPU, conventionally 1:8. In-memory caches, large database working sets, analytics that hold a lot of data resident.

x and z push memory further still, for workloads where the entire dataset must sit in RAM.

i and d — storage optimised. These attach fast local NVMe drives directly to the host. Enormously faster than network-attached storage, with one critical caveat: local storage does not survive the instance stopping. It is for data you can rebuild, such as a cache, a search index or a scratch working set.

g, p and inf — accelerated. GPUs and purpose-built inference chips. Expensive per hour, and worth it only when the accelerator is actually saturated.

Sizes are linear, and that is useful

Within a family the sizes roughly double: large, xlarge, 2xlarge, 4xlarge, and upward. Price scales with them, close to linearly. This has a practical consequence that people often miss: two instances of size N usually cost about the same as one instance of size 2N.

That makes the choice between scaling up and scaling out mostly an architectural question rather than a cost question. If your workload can run on two machines, two smaller machines give you redundancy for approximately the same money. If it cannot, a single larger machine is not a penalty.

Arm is usually the right default now

Graviton instances, marked by the g attribute, run on Arm rather than x86. For most modern workloads, they offer better performance per pound than the equivalent x86 instance in the same generation.

The catch is compatibility. Anything interpreted or JIT-compiled, which covers most Python, Node, Java, Go, Ruby and PHP applications, generally runs on Arm without changes. Anything with compiled native dependencies needs those dependencies to be available for Arm, which is now common but not universal. Container images need to be built for the right architecture, or built multi-arch.

The test is cheap: try it. If your application starts and your test suite passes, you are done.

Choosing without agonising

A workable procedure, in order:

1. Start with m at a small size unless you already know the workload is CPU-bound or memory-bound.
2. Run it under realistic load and watch CPU utilisation and memory utilisation together.
3. If CPU sits high and memory sits low, move to c. If memory is the constraint, move to r. If both are comfortable, size down.
4. Only then consider burstable. t instances are excellent for genuinely intermittent work and a trap for steady work.
5. Check the newest generation available in your region. Older generations are rarely cheaper for the performance they deliver.

The most common real-world mistake is not picking the wrong family. It is picking a size based on a guess at peak load and never revisiting it. Instances chosen in a hurry during a launch tend to still be running, unchanged and half-idle, a year later.

The paying model is a separate decision

Instance type and payment model are orthogonal, and it is worth keeping them separate in your head. You choose the shape based on the workload. You choose on-demand, savings plans or spot based on how predictable and how interruptible the workload is. Conflating the two leads to committing to a shape you have not validated.

Get the shape right first, running on-demand. Commit only once the shape has been stable for a while.

For the vendor’s own reference on the services involved here, see the AWS documentation.

Questions people ask