Loading...


Updated 13 Aug 2026 • 4 mins read

AWS offers thousands of EC2 instance types across five families, general purpose, compute, memory, storage, and accelerated. This cost reference explains the naming convention, what each family is for, how Graviton cuts cost 10 to 40 percent, and how to pick the cheapest instance that fits the workload.
There are more than seven hundred EC2 instance types, and the difference between the right one and a reasonable-looking wrong one is often the single biggest line on a compute bill. Pick a memory-optimized instance for a CPU-bound job and you pay for RAM you never touch; run x86 where Graviton would do and you leave 20 to 40 percent on the table. The good news is that behind the intimidating catalog sits a simple, decodable logic, and once you can read an instance name, the whole menu makes sense. It fits into the wider picture in our cloud pricing models guide.
This is a cost reference for EC2 instance types in 2026: how to read the naming convention, what each family is built for and priced around, how Graviton changes the math, and how to choose the cheapest instance that actually fits the job.
The short version EC2 instance types are grouped into five families: general purpose (M, T), compute optimized (C), memory optimized (R, X, z), storage optimized (I, D, H), and accelerated computing (P, G, Inf, Trn). The instance name encodes everything, family, generation, processor, and size, so m7g.xlarge reads as a 7th-gen general-purpose Graviton instance at extra-large size. Matching the family to the workload's bottleneck, and choosing Graviton where possible, are the two biggest cost levers.
Every instance name follows the same pattern, and decoding it tells you what you are paying for. Take m7g.xlarge. The first letter, m, is the family (general purpose). The number, 7, is the generation; higher is newer and usually better price-performance. The trailing letters are attributes: g means AWS Graviton (ARM), i means Intel, a means AMD, and modifiers like d (local NVMe storage) or n (enhanced networking) can follow. After the dot, xlarge is the size, which scales vCPU and memory together up a ladder (large, xlarge, 2xlarge, and so on), with price scaling roughly linearly. Read that way, c7gn.2xlarge is a 7th-generation compute-optimized Graviton instance with enhanced networking at the 2xlarge size, and its cost profile is obvious at a glance.
Each family targets a different bottleneck, and paying for the wrong one is the most common EC2 overspend.
| Family | Examples | Optimized for | Typical workloads |
|---|---|---|---|
| General purpose | M7, M7g, T4g | Balanced CPU, memory, and network | Web servers, application servers, small databases |
| Compute optimized | C7, C7g | High CPU per dollar | Batch, HPC, gaming, ML inference, high-traffic APIs |
| Memory optimized | R7, R7g, X2, z1d | High RAM per vCPU | In-memory databases, caches, real-time analytics |
| Storage optimized | I4i, D3, H1 | High local disk I/O | NoSQL, data warehouses, distributed file systems |
| Accelerated computing | P5, G6, Inf2, Trn2 | GPUs and AI accelerators | ML training and inference, graphics, HPC |
The single easiest EC2 saving is choosing AWS Graviton, the ARM-based processors marked by a g in the instance name (M7g, C7g, R7g). Graviton instances typically cost 10 to 40 percent less than comparable x86 instances while matching or beating their performance on most modern workloads, and the savings compound with commitments and Spot. The main consideration is architecture compatibility: most interpreted languages and mainstream container images run on ARM unchanged, while anything with compiled native dependencies needs a quick rebuild and test. For the vast majority of standard workloads, moving to Graviton is the highest-return, lowest-effort cost change available on EC2, and our AWS compute optimization guide shows how to find the candidates. To lock those rates in, pair it with the right commitment approach from our discount manager guide.
Then cover the cost with the right purchase model and let tooling flag drift, the ongoing discipline in our cloud cost optimization strategies, AWS cost optimization with FinOps, and best FinOps tools guides.
The EC2 catalog looks like a wall of cryptic codes, but it is really a menu organized around one question: what is your workload short on? Answer that, match it to the family built for that constraint, take the Graviton variant, and size it to what you actually use, and you have made the four decisions that set most of the bill. Everything else, the naming, the generations, the sizes, is just detail hanging off those four choices. An instance is only expensive when it is the wrong shape for the job. Get the shape right, and EC2 is as cost-efficient as compute gets.
Five: general purpose (M, T) for balanced workloads, compute optimized (C) for CPU-heavy work, memory optimized (R, X, z) for RAM-heavy work, storage optimized (I, D, H) for high local disk I/O, and accelerated computing (P, G, Inf, Trn) for GPU and AI workloads.
The name encodes family, generation, processor, and size. In m7g.xlarge, m is the family (general purpose), 7 the generation, g the processor (Graviton), and xlarge the size. Suffixes like d (local storage) and n (enhanced networking) add attributes.
It indicates an AWS Graviton (ARM-based) processor, as in M7g or C7g. Graviton instances typically cost 10 to 40 percent less than comparable x86 instances at similar or better performance, making them the easiest built-in EC2 saving.
Graviton instances are usually 10 to 40 percent cheaper than comparable Intel or AMD x86 instances for equivalent or better performance, and the savings stack with Reserved Instances, Savings Plans, and Spot.