How to Choose an AWS EC2 Instance Type: A Practical 2026 Guide

Here’s the short answer: most workloads should start on a t- or m-family instance and move to c, r, or g only when a real bottleneck shows up. AWS EC2 lists hundreds of instance types, but in practice you touch only a handful of families day to day. Don’t agonize over the perfect type up front. Start small, watch your CloudWatch metrics, and shift toward whatever resource you actually run out of. My default: I launch every new service on t4g (Graviton), watch it for a month, then decide.

Having paid a few years’ worth of these bills personally, I’ll tell you the expensive mistakes almost never come from not knowing the families. They come from picking a type once and forgetting it exists. Below I’ll walk through the family letters, how to pick per workload, and the three levers that actually move the bill: Savings Plans, Spot, and Graviton.

What’s the difference between the families? (t, m, c, r, i, g)

An instance type name like m7g.large reads as family (purpose) + generation + g for Graviton (arm) + size. Learn to read the letter and you’re halfway done.

Family	Character	vCPU:memory	Typical use
t	Burstable general purpose	1:2–1:4	Web servers, APIs, dev/test, small spiky services
m	Balanced general purpose	1:4	Steady-load web apps, mid-size backends
c	Compute-optimized	1:2	Batch compute, game servers, encoding, high-traffic APIs
r	Memory-optimized	1:8	In-memory caches, large databases, Redis/Elasticsearch
x	Extra-large memory	1:16+	SAP HANA, huge in-memory databases
i	Storage (NVMe) optimized	—	IO-heavy databases, log processing
g / p	GPU	—	ML training/inference, video transcoding

The ratio is the whole game. A c-family gives you relatively more CPU; an r-family gives you more memory. Pick the family that leans toward the resource your app exhausts first. If you already picked your cloud provider and want the bigger AWS-vs-GCP-vs-Azure picture, I covered that in the cloud hosting comparison; here I’m staying inside AWS.

Burstable (t) vs. fixed performance (m): what’s the catch?

The t-family trips people up because of that word, burstable. A t-instance runs at a baseline (say 20-40%) of its vCPUs and banks the rest as CPU credits. When traffic spikes, it burns credits to sprint toward 100%.

The trap is when credits run out. Unless you’re on Unlimited mode, it throttles back to baseline, so you get the bizarre situation where CPU reads 40% but the service crawls. The decision rule is simple:

• CPU sawtooths up and down → t-family wins.
• CPU sits above 60% consistently → m-family wins (running t in Unlimited mode all day is more expensive).

Dev environments, internal tools, blogs and landing pages with bursty traffic are textbook t-family. Trying to hold up an always-busy checkout API on a t-instance is the classic mistake.

What should I pick for my workload?

Here’s how I’d map it. Treat this as a starting point, then adjust after two weeks of metrics.

Workload	First pick	Why
New web service / API	t4g	Cheap, burstable, easy to migrate later
Steady-load backend	m7g	Balanced, predictable performance
Batch / encoding / game server	c7g	Compute-heavy, per-core matters
Cache / search / large DB	r7g	Memory headroom, avoids OOM
CI runners / rendering	c (Spot)	Interruption-tolerant, massively parallel
ML inference	g (Spot/schedule)	Needs GPU, wasteful if always on
Log / time-series DB	i	Local NVMe throughput

Always run the newest generation. m7 usually beats m6 at the same price; t4g beats t3. Leaving stale launch templates in place is silent leak number one. If you’re building out a team that needs to understand this stuff, it’s worth checking whether the fundamentals are actually there — I got into that skills question in the coding bootcamp ROI piece.

Does moving to Graviton (arm) actually make it cheaper?

Yes, and it’s the surest single win in EC2 cost optimization right now. Graviton is AWS’s own arm-based processor, marked by the g suffix (t4g, m7g, c7g, r7g). Expect roughly 20% better price-performance than the equivalent x86. Changing one letter in your instance type lowers the bill — a rare free lunch.

The one hurdle is architecture compatibility. Most interpreters and runtimes (Node, Python, Go, Java, Ruby) and official Docker images already ship arm64. Check these three:

• Does your container image build a linux/arm64 multi-arch variant?
• Do your native extensions (C-extension Python packages and the like) ship arm wheels?
• Do your commercial monitoring/security agents support arm?

Pass those and most migrations are uneventful. AI coding tools cut the grind of multi-arch Dockerfiles and migration scripts dramatically; which ones are worth using day to day is in my Cursor vs. Copilot comparison.

How much do you save? (Savings Plans, Spot, On-Demand)

The purchase model matters as much as the type. The same c7g can cost 3-4x more or less depending on how you buy it.

Purchase model	Discount	Flexibility	Risk	Best for
On-Demand	None (baseline)	Highest	None	Short, irregular, testing
Compute Savings Plans	Large (1/3-yr commit)	High (change family/region)	Under-use penalty	Always-on baseline
EC2 Instance Savings Plans	Larger	Lower (family locked)	Less flexible	Fully fixed core
Spot	Up to 70-90%	Low	2-min reclaim	Interruption-tolerant work

The real-world strategy is layering. Commit your always-on baseline to a Savings Plan for the discount, ride variable traffic on On-Demand, and fill the interruption-tolerant slack with Spot. An Auto Scaling group’s Mixed Instances Policy lets you set the On-Demand/Spot split as policy. Start conservative — commit to maybe 70% coverage based on Cost Explorer’s Savings Plans recommendation, then tighten. In US terms, remember this is a fixed operating cost that hits the same line as payroll and SaaS, so it belongs in your monthly finance review, not just the engineering channel.

What are the common mistakes? (a failure case)

Let me bundle the usual landmines into one story.

The case: a startup that got surprised by its bill. A team ran production on four m5.2xlarge On-Demand instances. Traffic only spiked during business hours, but all four ran overnight at 15% average CPU. On top of that, their CI runners were separate always-on On-Demand boxes. Break it down:

1. Over-provisioned — 15% CPU means they could drop two sizes. Compute Optimizer was already recommending m7g.large.
2. No Spot — CI runners can just restart if interrupted, yet they burned On-Demand money on them.
3. Old-gen, x86 by inertia — moving m5 (x86) to m7g (Graviton) alone saved nearly 20%.
4. No commitment — a year-round baseline with no Savings Plan attached.

Fixing those four cut the monthly bill by more than half. No magic — just the fundamentals: latest generation, Graviton, right size, commit the baseline, Spot the variable slack. If your team runs infrastructure remotely, bake this cost review into a recurring rhythm; the operating cadence I described in the remote work jobs guide applies directly.

What to watch every month

Instance type isn’t a set-and-forget decision. Here’s what I review monthly:

• Compute Optimizer recommendations — the over/under-provisioned list.
• Savings Plans coverage and utilization — is any commitment sitting idle?
• Spot interruption rate — if one type gets reclaimed often, widen your candidate types.
• Generation refresh — when a new gen lands, benchmark and consider swapping.
• Region placement — is any latency-insensitive workload stuck in an expensive region?

Cloud infrastructure spend ends up looking a lot like portfolio management. You lock in the baseline with a commitment the way you’d hold a long-term position, and you take the variable exposure flexibly with Spot. That allocation mindset rhymes surprisingly well with the portfolio logic I laid out in the AI stocks investing guide.

Bottom line: start small, watch the metrics, and pull the three levers — Graviton, Savings Plans, Spot — in that order. That single habit changes your EC2 bill more than anything else.

This article is for informational purposes only and does not recommend any specific architecture or purchase model. AWS pricing and instance specs change frequently, so always confirm real costs on the official AWS pricing page and in your own account’s Cost Explorer.