Workload	Family	Notes
Balanced web/app servers, dev	General purpose: M (steady), T (bursty)	T is cheapest for spiky/idle workloads
CPU-bound: batch, transcoding, HPC, game servers, ML inference	Compute optimized: C	Highest vCPU:memory ratio among the general/compute/memory (M/C/R) families
In-memory DBs, caches, big-data analytics	Memory optimized: R (X = extreme)	High memory:vCPU
High random IOPS: NoSQL, OLTP, disk-based caches	Storage optimized: I	Local NVMe SSD; see instance-store caveat below
Dense sequential throughput: data warehouses, HDFS, log processing	Storage optimized: D	Local HDD; see instance-store caveat below
Training / graphics	Accelerated: P, G (GPU)	P for training, G for graphics/inference
ML inference / training on AWS silicon	Inf (Inferentia), Trn (Trainium)	Lower cost per inference/training
Tightly coupled HPC	Hpc	Best price-performance at scale

Within a family, size (.large, .xlarge, …) scales vCPU and memory together. Prefer current generation over previous. New families and generations ship regularly, so confirm the current roster with aws ec2 describe-instance-types --filters Name=current-generation,Values=true or the EC2 instance-types documentation rather than treating this table as exhaustive.

Graviton (Arm64) vs x86

AWS Graviton instances — the g suffix denotes Graviton/Arm64 (e.g. m7g, c7g, t4g; additional generations ship over time, so discover current ones with aws ec2 describe-instance-types --filters Name=processor-info.supported-architecture,Values=arm64 Name=current-generation,Values=true) — run the Arm64 architecture and generally deliver better price-performance than comparable x86 instances, with each generation improving on the last. Check the current Graviton generation and its published price-performance figures in the AWS documentation before sizing.

Decision: Use Graviton when your language/runtime and all dependencies support Arm64 (Go, Java, Python, Node, .NET, most containers do). Stay on x86 (Intel/AMD) for software with x86-only binaries or drivers.

Gotcha: Graviton requires an Arm64/aarch64 AMI and Arm64-compiled binaries. An x86 AMI won’t launch on a *g type (the type appears disabled at launch). You can’t change architecture in place — rebuild.

Burstable T instances and CPU credits

T instances provide a baseline CPU percentage and earn CPU credits while below baseline, spending them to burst above it (1 credit = 1 vCPU running at 100% for 1 minute).

Mode	Behavior when credits run out	Default on
`standard`	Throttled down to baseline	T2
`unlimited`	Keeps bursting; bills surplus credits if 24h-avg CPU > baseline	T3, T3a, T4g (also T2 opt-in)

Defaults can differ on newer burstable generations — confirm a given type with aws ec2 describe-instance-types --instance-types <type> (and the credit-specification default) rather than assuming from this table.

Cost trap: T3/T3a/T4g default to unlimited, so a sustained-high-CPU workload silently accrues surplus charges (watch CPUSurplusCreditsCharged). For steady high CPU, move to a fixed-performance family (M/C/R) or set standard.
Set mode at launch or with aws ec2 modify-instance-credit-specification --instance-credit-specification InstanceId=<id>,CpuCredits=standard.
Credit persistence on stop: T2 Standard loses all accrued credits (balance reset to zero, fresh launch credits on restart); T3, T3a, and T4g keep their CPU credit balance for 7 days after stop, after which the credits are lost. Restart within 7 days and no credits are lost.
T3 on a Dedicated Host is standard-only.

Instance store vs EBS

Instance store = physically attached ephemeral disk (families with the d suffix and I/D families).

Instance store data is lost on stop, hibernate, terminate, instance-type change, and underlying host failure; it survives only a reboot. It’s also attach-at-launch-only. Use it for scratch/cache/replicated data. For anything durable, use EBS (persists independently), EFS, or S3. Encrypt EBS volumes by default.

Common Errors

Error	Cause	Fix
Instance type disabled/greyed out at launch	AMI architecture ≠ instance architecture (x86 AMI on Graviton)	Use an Arm64 AMI for `*g` types; rebuild app for Arm64
Unexpected CPU surplus charges on T3/T4g	Unlimited mode + sustained CPU above baseline	Switch to `standard`, or right-size to M/C/R
Scratch data gone after resize/stop	Instance store wiped on stop/type-change	Store durable data on EBS/EFS/S3
Sudden throttling to baseline (standard T2)	CPU credit balance depleted	Enable unlimited (mind cost) or use fixed-performance family

Security Considerations

Graviton (Arm64) needs Arm64 builds — before migrating, confirm all security-critical software (TLS libraries, IDS/endpoint agents, compliance tooling) ships Arm64 binaries, not just your app.
Instance store is ephemeral — never place cryptographic keys, certificates, or secrets on it; they’re lost on stop/terminate and can’t be reliably wiped. Keep secrets in Secrets Manager / SSM Parameter Store and durable data on encrypted EBS.
Choose EBS-capable, encryptable types for production — enable EBS encryption by default and detailed monitoring on the chosen family.

provisioning.md to bake the choice into a launch template
auto-scaling.md for mixed instance types and Spot

references/instance-selection.md

Raw file

aws/agent-toolkit-for-aws