Amazon EC2 gives you dozens of instance types spread across multiple families. The naming looks cryptic at first—t3.medium, m7g.large, r6i.2xlarge—but the pattern is consistent once you know what each letter means.
Quick answer: start with a general-purpose family (t3 or m7g) for most web apps and APIs, move to compute-optimized (c7g) for CPU-heavy work, memory-optimized (r7g) for caches and in-memory analytics, and storage-optimized (i4i) for high-throughput databases. Right-size with CloudWatch metrics before committing to Reserved Instances.
How EC2 instance names are structured
Every EC2 instance name follows this pattern:
{family}{generation}.{size}
| Part | Meaning | Example |
|---|---|---|
| Family letter | Workload category | m = general purpose |
| Number | Generation (higher is newer) | 7 in m7g |
| Optional suffix | Processor or feature | g = AWS Graviton (Arm) |
| Size | Capacity tier | xlarge, 2xlarge |
Sizes scale in a predictable ladder: nano → micro → small → medium → large → xlarge → 2xlarge and beyond. Each step up typically doubles vCPUs and memory (with some exceptions in burstable t instances).
EC2 instance families at a glance
General purpose (T, M)
Best for: web servers, microservices, small databases, dev/test environments.
- T instances (
t3,t4g): Burstable CPU. Cheap for workloads with idle time. Accumulate CPU credits when quiet, spend them during spikes. Avoid for sustained 100% CPU. - M instances (
m6i,m7g): Balanced CPU and memory. The default choice when you are unsure.
Compute optimized (C)
Best for: batch processing, video encoding, gaming servers, scientific modeling, ad serving.
C instances offer the highest vCPU-to-memory ratio. If your app is CPU-bound and memory usage stays flat, C families usually beat M families on price-performance.
Memory optimized (R, X)
Best for: Redis/Memcached, SAP HANA, large in-memory Java heaps, real-time analytics.
- R instances: High memory relative to CPU.
- X instances (
x2idn,x2iedn): Extreme memory for very large datasets.
Storage optimized (I, D)
Best for: NoSQL databases (Cassandra, MongoDB), data warehousing, log processing.
These instances pair fast local NVMe storage with high network throughput. Use them when disk I/O is the bottleneck, not when you only need EBS volumes.
Accelerated computing (P, G, Inf, Trn)
Best for: ML training/inference, graphics rendering, HPC.
GPU and custom accelerator instances are powerful but expensive. Start on smaller g4dn or inf2 sizes and scale after profiling.
Graviton (Arm) vs Intel/AMD (x86)
Instances ending in g (e.g., m7g, c7g) run on AWS Graviton processors. They often deliver 20–40% better price-performance for supported workloads.
Before choosing Graviton:
- Confirm your language runtime and dependencies support Arm64.
- Test in staging—some native libraries ship x86-only binaries.
- Use the same family letter on Graviton (
m7ginstead ofm7i) for an apples-to-apples comparison.
A practical selection workflow
Use this sequence instead of guessing from the instance list:
1. Profile your workload
Collect one to two weeks of metrics:
- CPU utilization (average and p95)
- Memory usage
- Network in/out
- Disk read/write IOPS (if applicable)
CloudWatch agent or your APM tool (Datadog, New Relic) makes this straightforward.
2. Start one size up from "just enough"
Undersized instances create latency spikes that are harder to debug than slightly oversized ones during initial launch. Pick a medium or large in the target family, load test, then downsize.
3. Compare two families in parallel
Run the same container or AMI on m7g.large and c7g.large for an hour. The winner is usually obvious from CPU vs memory graphs.
4. Lock in savings after stability
Once instance type and size stay stable for 30+ days:
- Savings Plans or Reserved Instances for production
- Spot Instances for fault-tolerant batch jobs (never as sole web tier without fallback)
Common sizing mistakes
Choosing T instances for always-busy APIs. Burstable instances throttle when CPU credits run out. Steady traffic belongs on M or C.
Ignoring EBS vs instance store. Most apps use EBS volumes. Storage-optimized instance store is ephemeral—data is lost on stop/terminate unless you replicate it.
Copying on-prem specs 1:1. Virtualization and cloud networking change performance characteristics. A 16-core bare-metal box does not map cleanly to m7i.4xlarge.
Staying on old generations. m5 → m7g upgrades often reduce cost at the same performance tier.
Example scenarios
| Workload | Starting point | Why |
|---|---|---|
| Node.js API (moderate traffic) | t3.medium or m7g.medium | Balanced, cost-effective |
| Video transcoding queue | c7g.2xlarge | Sustained CPU |
| Redis cache (8 GB data) | r7g.large | Memory headroom for overhead |
| PostgreSQL on EBS | m7i.xlarge + gp3 volume | Enough CPU; tune IOPS separately |
FAQ
What is the difference between t3 and t3a?
t3a uses AMD EPYC processors; t3 uses Intel Xeon. Performance is similar—pick whichever is cheaper in your Region.
How do I see all instance types in my Region?
Run: aws ec2 describe-instance-types --region us-east-1 --output table
Should I use Auto Scaling instead of picking one big instance?
Yes for production web tiers. Auto Scaling groups let you mix instance types (e.g., m7g.large + m7i.large) for capacity flexibility.
When does unlimited mode on T instances make sense?
When occasional CPU spikes are acceptable but you want to avoid hard throttling. You pay extra for sustained overage—monitor CPUSurplusCreditsCharged.
Burstable performance in detail (T instances)
T instances use a credit system. Each size earns CPU credits per hour at a baseline utilization (5%, 20%, or 40% depending on size). When your process needs more CPU, it spends credits. Run out of credits and the instance throttles to baseline—often felt as sudden API latency.
Monitor these CloudWatch metrics weekly:
CPUCreditBalance— trending down means sustained load exceeds burstable designCPUCreditUsage— spikes during deploys or batch jobs are normalCPUUtilization— compare average vs maximum; wide gaps suggest burstable fit
If credit balance hits zero during business hours, migrate to m7g or c7g rather than enabling unlimited mode indefinitely.
Networking and placement choices
Instance type affects network bandwidth and EBS throughput caps. A m7g.large tops out around 12.5 Gbps network; m7g.4xlarge reaches 50 Gbps. For data-heavy pipelines, network limits matter as much as CPU.
Placement groups matter for HPC clusters:
- Cluster — lowest latency between nodes (same AZ, limited size)
- Spread — fault isolation across racks
- Partition — large distributed systems (HDFS, Kafka)
Most web apps ignore placement groups; latency-sensitive clusters should not.
Using the EC2 Instance Type selector in the console
AWS ships an interactive Instance Type wizard during launch. Filter by vCPU, memory, and network. Export your shortlist to CSV and share with finance for Reserved Instance planning.
For infrastructure-as-code, define allowed types in Terraform or CloudFormation variables so engineers cannot accidentally launch p4d.24xlarge in dev:
variable "allowed_instance_types" {
default = ["t3.medium", "m7g.large", "c7g.large"]
}
Bottom line
EC2 instance types are not a one-time decision. Name the family after your bottleneck (CPU, memory, disk, GPU), pick a current generation, validate with metrics, and iterate. Most teams converge on a small set of approved types per workload class—which keeps costs predictable and deployments fast.
Comments
Loading comments…