Skip to content

AWS Updated 2026-09-25

Choosing an EC2 instance type in 2026: the families decoded (m, c, r, t, g)

Learn how to choose an EC2 instance type by reading the m, c, r, t and g family letters and the suffixes that follow them. You will leave with a simple decision path that starts small and keeps you from paying for capacity you never use.

This guide helps developers and small teams choose an Amazon EC2 (Elastic Compute Cloud, the AWS virtual server service) instance type without guessing. AWS offers hundreds of types with names like m8g.large or r7i.2xlarge, and the wrong pick means paying for idle capacity or running short when load grows. The short answer is to start with the current general-purpose m family on Graviton, AWS’s own ARM-based processor (m8g at the time of writing, with m7g widely available). Measure for a while, then move to c for CPU-heavy work or r for memory-heavy work only when the numbers show the balance is off. By the end, you will be able to decode any instance name and know when the burstable t family or the GPU-equipped g family is worth it.

What you are deciding

An instance type name like m7g.large reads as: family m, generation 7, g for Graviton (AWS’s ARM processors), size large. You are choosing three things at once — the resource ratio, the processor, and the scale — and they are separable decisions.

The families:

  • m — general purpose. About 4 GiB of memory per vCPU. The correct default for web apps, APIs, app servers, and anything unprofiled. When in doubt, m.
  • c — compute optimized. About 2 GiB per vCPU, tuned for CPU-heavy work: encoding, build farms, game servers, high-throughput app tiers that are CPU-bound with modest working sets.
  • r — memory optimized. About 8 GiB per vCPU: databases, in-memory caches, analytics, JVMs with big heaps. (x and z families push further for extreme cases like SAP HANA.)
  • t — burstable general purpose. Same ratio as m but a fraction of a CPU with credit-based bursting — cheap for dev boxes and low-traffic services, wrong for sustained load. The failure mode is its own article: t3/t4g CPU credits and the surprise slowdowns.
  • g — GPU. g-family (g5, g6) for graphics and ML inference; p-family for heavy training. Only relevant when the workload literally runs on a GPU.

Beyond these live specialists you should know exist but rarely start with: i (storage optimized, local NVMe for I/O-heavy databases), d-suffixed variants (local disk), hpc, mac, and the x/z memory extremes.

The suffixes after the generation number: g = Graviton/ARM (best price-performance, requires ARM-compatible builds), a = AMD (slightly cheaper x86), i = Intel, d = local NVMe disk attached, n = enhanced networking bandwidth. They combine: c7gn is compute-optimized, Graviton, network-enhanced.

Generations: higher is newer and almost always better price-performance in the same Region. As of 2026, 7th generation is the broad default and 8th-generation Graviton (m8g, c8g, r8g) is rolling out across Regions; not every type exists in every Region or AZ, so check availability where you actually deploy. The complete catalogue is in the EC2 documentation and prices compare cleanly in the AWS pricing calculator.

What to check first

  • Your actual CPU-to-memory ratio today. Two weeks of metrics from existing servers beats any theory: high CPU with idle memory says c; swollen RSS with idle CPU says r.
  • Whether your stack runs on ARM. Most Linux workloads (Node, Python, Go, Java, nginx, Postgres clients) run natively on Graviton now; a stray x86-only binary or container base image is the usual blocker.
  • Sustained versus spiky load. Sustained above ~20-30% average CPU disqualifies the t family.
  • Region and AZ availability for the exact type — newest generations land unevenly.
  • Licensing constraints. Some commercial software is licensed per-core or x86-only, which can force i/a suffixes regardless of preference.

How to verify

List what a Region actually offers for a family:

aws ec2 describe-instance-types \
  --filters "Name=instance-type,Values=m8g.*,m7g.*" \
  --query 'InstanceTypes[].[InstanceType,VCpuInfo.DefaultVCpus,MemoryInfo.SizeInMiB]' \
  --output table

Check which types an AZ can launch right now:

aws ec2 describe-instance-type-offerings \
  --location-type availability-zone \
  --filters "Name=instance-type,Values=m8g.large" \
  --query 'InstanceTypeOfferings[].Location'

For evidence about your current fleet, EC2 > Instances > Monitoring gives CPU; memory needs the CloudWatch agent. AWS Compute Optimizer reads both and issues over/under-provisioning verdicts — the workflow is covered in Compute Optimizer rightsizing.

The approach

  1. Default to current-generation m on Graviton for anything new and unprofiled: m8g where available, m7g otherwise. Fall back to m7i/m7a only when x86 is genuinely required.
  2. Size for the p95, not the peak-of-peaks. Pick the size that covers normal daily load and let an Auto Scaling group absorb spikes with more instances rather than one giant one — horizontal beats vertical for stateless tiers.
  3. Measure for two weeks, then re-ratio. CPU consistently above 70% with memory under 40%: move to c. Memory above 70% with CPU idling: move to r. Both idle: downsize or move to t.
  4. Use t deliberately, not accidentally — dev, staging, cron, internal tools, genuinely low-traffic sites. Anything with an SLA and steady traffic earns a fixed-performance family.
  5. Test Graviton with one canary instance behind the same load balancer before migrating a fleet; a multi-arch container build makes the swap reversible in minutes.
  6. Only after the type is stable, buy the discount. Savings Plans and Reserved Instances lock in the family decision, so commit after the measurement, not before — the tradeoffs live in RIs vs Savings Plans vs Spot.

When this is the wrong move

If your workload fits Lambda, Fargate, or a managed service, the best instance type is none — do not inherit a fleet to manage because instance-picking felt like the natural first step. Skip the specialist families until a measurement demands them: buying i4-family NVMe boxes for a database that does 200 IOPS, or r-family for a JVM whose heap was simply never tuned, is spending on a diagnosis nobody made. And do not chase each new generation the week it launches across a whole fleet; migrate opportunistically as instances get replaced.

Common mistakes

  • Sizing from fear: picking 4xlarge “to be safe” and running at 6% utilization for two years. Overprovisioning is the largest silent EC2 cost in most accounts.
  • Treating the t family as “the cheap m” and putting steady production load on it — the credit throttle or surplus charges arrive within weeks.
  • Ignoring Graviton for compatibility reasons last verified in 2021. The ecosystem moved; most mainstream stacks are ARM-clean now.
  • Letting a Reserved Instance bought for the old type dictate the architecture years later. The discount tail should not wag the workload dog.

Keeping it under control

  • Enable Compute Optimizer account-wide; review its findings quarterly and act on the top five.
  • Put instance-type choices in launch templates and IaC so changes are reviewed diffs, not console drift.
  • Re-run the ratio check after major app changes — a caching layer or a runtime upgrade can flip a c workload into an m one.
  • Track price-performance per service, not per instance: requests served per dollar is the metric that settles family debates.

The decoder is simple: family letter for the ratio, generation for the price-performance, suffix for the processor, size for the scale — and measurements, not instinct, move you between them. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.