AWS uses a structured naming convention that encodes the hardware profile of every instance type. Once you learn to read it, you can make informed choices without memorizing a catalog.
Example: m5.2xlarge
m— the family (what the hardware is optimized for)5— the generation (higher = newer hardware, better price/performance)2xlarge— the size (how many vCPUs and how much RAM)
The Family Letter: What Is It Optimized For?
| Family | Name | CPU:RAM Ratio | Best For |
|---|---|---|---|
M |
General Purpose | Balanced (~4 GB RAM per vCPU) | Web servers, app servers, small databases |
C |
Compute Optimized | High CPU, less RAM (~2 GB per vCPU) | Batch processing, video encoding, HPC |
R |
Memory Optimized | High RAM, less CPU (~8+ GB per vCPU) | In-memory databases (Redis, Memcached), Spark |
I |
Storage Optimized | NVMe SSDs attached to host | NoSQL databases (Cassandra, MongoDB), data warehousing |
G / P |
Accelerated Computing | GPU-heavy | Machine learning training/inference, video rendering |
T |
Burstable | Low baseline CPU | Dev/test, low-traffic sites, microservices |
The Special Case: T Instances (Burstable Performance)
T instances are the cheapest general-purpose instances, but they work on a fundamentally different model than every other family. Understanding this model is critical to avoiding production incidents.
How CPU Credits work:
- Every
Tinstance has a baseline CPU percentage (e.g., at3.mediumhas a 20% baseline). - When your CPU usage is below the baseline, you earn credits at a fixed rate (e.g., 24 credits/hour for a
t3.medium). - When you need more CPU, you spend credits to burst above the baseline, up to 100%.
- Credits accumulate up to a maximum cap (typically 24 hours' worth).
The failure mode: If your application runs at sustained high CPU (e.g., a deployment that triggers a compilation job), you drain your credit balance. Once credits hit zero, the CPU is hard-throttled to the baseline — often 20% of a single vCPU. Applications become unresponsive. This is a real production incident pattern that catches engineers off guard.
The fix: Enable Unlimited Mode on T instances. In Unlimited Mode, the instance can burst indefinitely, but you pay a small surcharge per vCPU-hour for any burst above your earned credits. For most workloads, this surcharge is negligible and eliminates the throttling risk.
Rule of thumb: Use T instances for dev/test, low-traffic services, and workloads with genuinely spiky patterns. For any sustained production load, use M, C, or R depending on the bottleneck.