EC2 Instance Types

EC2 instance types are grouped into families, and each family into generations and sizes. The name tells you most of what you need; the numbers behind it change often enough that they belong in the API rather than on this page.

Reading the name

An instance type name decomposes as family + generation + attributes, a dot, then the size — for example m7g.xlarge:

• m — the family: general purpose
• 7 — the generation
• g — an attribute; here, an AWS Graviton processor
• xlarge — the size within that type

Common attribute letters:

Letter	Meaning
g	AWS Graviton (ARM64) processor
a	AMD EPYC processor
i	Intel processor
d	Local NVMe instance store
n	Additional network and EBS bandwidth
z	Higher clock frequency
b	Higher EBS bandwidth
flex	Sustained-usage-priced variant with a lower baseline

Sizes step up through nano, micro, small, medium, large, xlarge, 2xlarge and so on to metal. Within a family, vCPU and memory scale roughly proportionally with size, so m7g.2xlarge has twice the vCPUs and twice the memory of m7g.xlarge.

Family categories

General purpose (M, T). A balanced ratio of compute to memory, usually 4 GiB per vCPU. M-family instances suit web servers, application servers and small databases. T-family instances are burstable: they provide a low baseline with the ability to burst above it, governed by CPU credits. T instances are the cheapest way to run something that is idle most of the time and the most expensive way to run something that is not.

Compute optimised (C). Roughly 2 GiB per vCPU, on the highest-performing processors in the fleet. Batch processing, media transcoding, ad serving, game servers, scientific modelling, inference.

Memory optimised (R, X, U, z). R-family instances offer around 8 GiB per vCPU; X and U families go much further, into the terabytes, for in-memory databases and large SAP HANA deployments. The z family trades core count for clock speed, which suits per-core-licensed software.

Storage optimised (I, D, Im/Is). Large local NVMe capacity and very high random IOPS, for NoSQL databases, search clusters, data warehouses and anything that would otherwise saturate EBS.

Accelerated computing (P, G, Inf, Trn, F, VT). GPUs (P for training, G for graphics and inference), AWS Inferentia and Trainium for machine learning, FPGAs for custom hardware acceleration, and video transcoding accelerators.

High performance computing (Hpc). Purpose-built for tightly coupled HPC, paired with a cluster placement group and an Elastic Fabric Adapter.

Graviton first

AWS Graviton processors are AWS’s own ARM64 designs, and they are the default worth starting from rather than an exotic option. Every mainstream category has a Graviton line — t4g, m8g, c8g, r8g, i8g and so on — and they generally offer better price-performance than the equivalent x86 instance in the same generation. The claim that the C family gives the best price to compute performance in EC2 stopped being true once Graviton arrived.

The cost of moving is recompilation and testing. If your workload is a container built from source, a JVM, Python, Node.js, Go or .NET, the port is usually a build-target change. If it depends on x86-only binaries, licensed x86 software, or an ISV that has not shipped an ARM64 build, stay on Intel or AMD.

Previous generation

AWS keeps a published list of previous generation instances — among them M1, M2, M3, M4, C1, C3, C4, R3, R4, T1, I2, G2 and A1 — with the recommended replacement for each. They still run, but they cost more per unit of work than current families and receive no new features. If a running fleet is on one of them, moving up a generation is usually a cost reduction rather than a cost.

Choosing a size

Do not copy a specification table out of a document; specifications change and tables rot. AWS publishes current vCPU, memory, storage, network and EBS figures on the instance types pages, and the same data is queryable:

aws ec2 describe-instance-types \
  --filters "Name=instance-type,Values=m8g.*" \
  --query "InstanceTypes[].{type:InstanceType,vcpu:VCpuInfo.DefaultVCpus,memGiB:MemoryInfo.SizeInMiB,net:NetworkInfo.NetworkPerformance}" \
  --output table

What does age well is the method:

1. Start from the constraint that binds. Most workloads are bound by one of memory, CPU or I/O. Pick the family whose ratio matches that constraint, then size to it; buying a bigger general purpose instance to get more of one resource wastes the other two.
2. Match the workload pattern. Steady load wants a fixed family and a commitment discount. Bursty low-average load wants T instances. Interruptible work wants Spot.
3. Measure before you commit. AWS Compute Optimizer produces right-sizing recommendations from CloudWatch history and will usually find instances that are two sizes too large.
4. Check what is actually available. Not every instance type exists in every Region or Availability Zone, and the newest generations arrive in the largest Regions first.

Related capabilities

• Enhanced networking is enabled by default on current-generation types through the Elastic Network Adapter, and extended by the Elastic Fabric Adapter for HPC.
• Placement groups — cluster, partition and spread — control how instances are distributed across the underlying hardware. See EC2.
• Instance store versus EBS — instance store is ephemeral and very fast; EBS persists across stop and start. Many instance types are EBS-only, and types with a d in the name have local NVMe.
• EBS optimisation is on by default for current-generation types, giving EBS traffic dedicated bandwidth away from the general network path.