EC2 instance families: how to read m7i, c7g, r6a and the rest

An EC2 instance type is a spec sheet compressed into six or seven characters. m7i.2xlarge tells you the workload profile, the hardware generation, the processor vendor and the size, in that order. Once the pattern clicks, the EC2 instance families stop blurring together and browsing the instance list stops being an exercise in scrolling.

Reading the name

Take r6a.4xlarge apart:

• r is the family. Memory optimised.
• 6 is the generation. Higher is newer, and newer is usually cheaper per unit of work.
• a is the processor. AMD, in this case.
• 4xlarge is the size within that family.

Additional letters can appear after the processor character. d means local NVMe storage is attached. n means enhanced network bandwidth. e means extra memory. z means a higher clock speed part. So m7idn.large is a general purpose, seventh generation, Intel instance with local disks and extra network throughput.

The EC2 instance families that matter

• T. Burstable. You get a baseline share of a core and earn credits while idle, which you spend when busy. Excellent for low traffic web servers and development boxes; unpredictable for anything with a sustained load.
• M. General purpose, roughly 4 GB of memory per vCPU. The sensible default when you do not yet know the shape of the workload.
• C. Compute optimised, around 2 GB per vCPU. Batch processing, encoding, simulations, busy application servers.
• R. Memory optimised, around 8 GB per vCPU. Databases, caches, in memory analytics.
• X and U. Extreme memory. SAP HANA and similar. Expensive, and you will know if you need them.
• I and D. Storage optimised, with large local NVMe or spinning disk. High IOPS databases and data warehouses that stage locally.
• G, P, Inf and Trn. Accelerated computing. Graphics, model training, model inference. Each sits in its own quota bucket, which is worth remembering before you plan a fleet.

Graviton, Intel or AMD

AWS offers three processor lines across most modern families, and the choice is more consequential for the bill than for the code.

Graviton is ARM based and generally the best price per unit of performance in the catalogue. Anything running in a container built for linux/arm64, most interpreted languages, Java, Go and the managed AWS runtimes all work without modification. The friction appears with binary dependencies compiled for x86, older commercial software and some machine learning wheels.

Intel variants tend to have the highest single thread clocks in the z designated types and the widest software compatibility. AMD variants usually land a few percent cheaper than the Intel equivalent with very similar behaviour.

A pragmatic approach: default to Graviton, benchmark against the Intel equivalent for anything performance sensitive, and keep x86 for the handful of workloads that resist.

Sizing without guessing

Sizes scale predictably. A large is 2 vCPUs, xlarge is 4, 2xlarge is 8, and so on up. Memory scales with the family ratio. Two practical notes:

• Network and EBS bandwidth scale with size too. Small instances get burst allowances rather than sustained throughput, so a job that looks CPU bound may actually be waiting on disk.
• Two smaller instances often beat one larger one. You get redundancy, and the failure of a single node stops being an outage.

Start by measuring rather than estimating. Run the workload on something obviously oversized for a day, look at CloudWatch, then size down. Guessing upward is expensive and guessing downward causes incidents.

Purchase options change the price, not the shape

Any instance type can be bought four ways: on demand, savings plans, reserved instances or spot. The instance behaves identically in each case; only the billing and the interruption risk change. Spot capacity in particular is a different quota and a different risk profile, since AWS can reclaim the instance with two minutes of notice.

We cover the trade offs across providers in cloud pricing models compared.

A short decision path

1. Is the workload spiky and small? Start with a T family instance.
2. Is it a general application server? M family, current generation, Graviton if the stack allows.
3. Is it CPU bound? C family, and check whether the bottleneck is really single threaded.
4. Is it memory bound? R family, and consider whether a managed cache would be cheaper than a bigger box.
5. Does it need a GPU? G for inference and graphics, P for training, and check the quota before you plan anything.

If storage rather than compute is the cost driver, the S3 storage classes guide is the more useful read. If you are still choosing a platform, AWS vs Google Cloud compares how the two structure their machine types.