Choosing the Right EC2 Instance Type: Families, Naming & Right-Sizing

You need to run something on a server in AWS, and the console offers you a dropdown with over 800 EC2 instance types — t3.micro, m7g.2xlarge, c7i.4xlarge, r7iz.8xlarge, i4i.metal, p5.48xlarge. Nobody explains what the letters and numbers mean, so most people pick t2.micro because it’s free, or m5.large because a blog said so, and then either fight CPU throttling for months or burn money on a box that idles at 8% all day. Both mistakes are avoidable once you can read the name and match a workload to a family.

An EC2 instance type is just a fixed recipe of virtual hardware: a number of vCPUs, an amount of memory, a processor (Intel, AMD, or AWS’s own Graviton ARM chips), a network bandwidth ceiling, an EBS bandwidth ceiling, and sometimes local NVMe disks or GPUs. The name encodes most of that in a handful of characters. m7g.2xlarge reads as family m (general purpose) · generation 7 · attribute g (Graviton) · size 2xlarge (8 vCPU / 32 GiB). Learn that grammar and the 800-item dropdown collapses into a short decision: what shape is my workload, which family matches that shape, and how big does it need to be?

This guide teaches the whole grammar. You will decode the name character by character, walk every family with real specs and use-cases, choose between Graviton, Intel and AMD on price and performance, understand the Nitro system that underpins modern instances, and then right-size with Compute Optimizer and CloudWatch so you stop paying for capacity you never use. There’s a copy-pasteable lab that uses aws ec2 describe-instance-types to pick a type, launches it, reads the right-sizing signals, changes the type, and tears everything down — in both the CLI and Terraform. Purchasing models (On-Demand, Spot, Savings Plans, Reserved) are a separate axis from which type — they’re covered in their own article; here we focus entirely on picking the right hardware shape.

What problem this solves

Picking an instance type wrong costs you in two directions at once, and both are silent for weeks.

Over-provisioning is the common one. You size for a peak you imagined, ship an m5.4xlarge (16 vCPU / 64 GiB) for a service that runs at 6% CPU and 20% memory, and it costs the same whether it serves a million requests or zero — roughly $490/month in us-east-1 for a box doing the work of a large. Multiply by a fleet and by every environment (dev, staging, prod) and over-provisioning is usually the single biggest line on an EC2 bill. Nobody notices because the app works; it just costs 6x what it should.

Under-provisioning is nastier because it looks like an application bug. A T burstable instance runs out of CPU credits and gets throttled to a 10-20% baseline, so your API latency triples at 3pm every day and you spend a week blaming the code. A memory-optimized job lands on a compute-optimized box and the kernel OOM-kills it. An EBS-bandwidth-bound database saturates the instance’s storage ceiling — not the volume’s — and no amount of CPU or IOPS on the volume helps. A Graviton binary won’t start on the ARM box because it was compiled for x86. Each of these is a wrong-type problem masquerading as something else, and each has a specific fingerprint you’ll learn to spot.

Everyone who runs EC2 hits this: developers launching a first instance, architects standardising a fleet, SREs chasing a latency regression, and finance asking why compute doubled. Getting the type right the first time — and re-checking it with data every quarter — is the difference between a predictable bill and a mystery. It’s also squarely on the exams: CLF-C02 expects you to know the families and burstable behaviour, and SAA-C03 expects you to right-size and to reason about Graviton, Nitro, and storage-optimized trade-offs.

Learning objectives

By the end of this article you can:

• Decode any instance name — split r7iz.8xlarge into family, generation, attributes and size, and know the vCPU/memory it implies.
• Name the size ladder from nano to metal and apply the “each step doubles” rule to predict specs and price.
• Match a workload to a family — T, M, C, R/X/z, I/D/Im/Is, P/G/Inf/Trn/DL, and HPC — from its CPU:memory ratio and its special needs.
• Explain burstable T instances — CPU credits, per-size baselines, Standard vs Unlimited mode, and the billing risk of Unlimited.
• Choose a processor — Graviton (ARM64) vs Intel vs AMD — on price/performance, and avoid the porting trap.
• Read the specs that scale with size — vCPU, memory, network bandwidth, EBS bandwidth, and which numbers are burst vs sustained.
• Right-size with data — interpret Compute Optimizer findings and the CloudWatch signals (CPU, memory, network, EBS, credit balance) that drive them.
• Change an instance’s type safely — the stop / modify / start flow, and the compatibility rules that bite (architecture, virtualization, AZ availability).

Prerequisites & where this fits

You should have an AWS account, the AWS CLI v2 configured (aws configure), and permission to launch and describe EC2. Basic comfort with a VPC (a default VPC is fine), a security group, and an SSH key pair is assumed — if you’ve never launched an instance, start with Launch Your First EC2 Instance and SSH In and come back. You don’t need to know Terraform to read the CLI path, but the IaC snippets use the hashicorp/aws provider.

Where this sits: choosing a type is step one of running any server workload. It comes after you’ve decided EC2 is the right service at all — if you’re still weighing EC2 against Lambda, ECS and EKS, read AWS Compute: EC2, Lambda, ECS and EKS — Which One to Choose? first. It comes before you bootstrap the box with startup scripts (EC2 User Data and cloud-init Bootstrapping), put it behind an Auto Scaling group and load balancer, or commit to a purchasing model. Type selection and purchasing model are independent axes: you pick the shape here (this article) and the commitment — On-Demand, Spot, Savings Plans, Reserved — separately. A c7g.xlarge is the same hardware whether you pay On-Demand or under a Savings Plan.

Core concepts

Before the families, pin down the vocabulary. Every instance type is defined by these dimensions, and the whole art of choosing is matching them to your workload.

Two ideas do most of the work. First, the CPU:memory ratio picks the family. Measure how much RAM your workload actually uses per vCPU of CPU it burns, and the family falls out: 2 GiB/vCPU → C (compute), 4 → M (general), 8 → R (memory), 16-32+ → X (extreme memory). Second, the size picks the amount, and sizes double. From large upward, each named step doubles vCPU and memory (and lifts the network/EBS ceilings), so xlarge is 2× large, 2xlarge is 4× large, and price scales roughly linearly with it. Everything else — attributes, processor, Nitro — is refinement on top of those two decisions.

Decode the instance name

Every EC2 name has the same grammar: <family><generation><attributes>.<size>. Read it left to right.

Take m7g.2xlarge:

A denser example, r7iz.8xlarge: family r (memory-optimized) · gen 7 · attributes iz (i = Intel, z = high frequency / high clock) · size 8xlarge (32 vCPU / 256 GiB). And c6gd.4xlarge: family c (compute) · gen 6 · attributes gd (g = Graviton, d = local NVMe instance store) · size 4xlarge.

The attribute letters

The lowercase letters between the generation and the dot are additional capabilities. Order matters only for readability; each letter is independent. Memorise this table — it’s the part people never learn:

So c6in = compute · gen 6 · Intel · network-optimized; x2iedn = extreme-memory · gen 2 · Intel · extra-memory · NVMe · network-optimized. When a family has multiple processor variants in the same generation — m7i, m7a, m7g — they’re the same shape (same vCPU:memory) on three different chips, and you choose on price/performance and architecture.

A subtle one: on some older families the absence of a processor letter meant Intel by default (m5 = Intel, m5a = AMD, m5n = Intel+network). Newer families spell it out (m7i/m7a/m7g). When you see a bare m6i.large next to m6a.large, they’re deliberately distinguished; a lone m5.large is Intel.

The size ladder

After the dot comes the size. Sizes form a ladder, and from large up, each step roughly doubles vCPU and memory (and raises the network and EBS ceilings). The small end (nano–medium) is mostly T-family territory.

The doubling rule is not just about specs — price roughly doubles too, so 2xlarge costs about 4× large. That makes the ladder your cost dial: right-sizing is usually “move down one step,” which cuts the bill ~50% for that box. .metal is special: you get the raw physical server with no hypervisor, for workloads that need hardware features, their own hypervisor (nested virtualization), or licences tied to physical cores.

The instance families, end to end

There are five broad categories — general purpose, compute-optimized, memory-optimized, storage-optimized, accelerated — plus burstable (a special general-purpose sub-type) and HPC. Here’s the whole map first, then each family in depth.

The family cheat-sheet

T — burstable performance

T instances are the cheapest way to run something that’s busy in bursts and idle the rest of the time — small websites, dev boxes, low-traffic microservices, bastion hosts, cron runners. Instead of paying for a full vCPU you rent a baseline slice of one and earn CPU credits while you’re under baseline; when you burst above it you spend credits. One CPU credit = one vCPU running at 100% for one minute.

Each size has a fixed baseline (as a % of a vCPU) and earns credits at a fixed rate. Run below baseline and your balance grows (capped at 24 hours’ worth); run above and it drains.

t4g (Graviton) uses the same baseline/credit table at a lower price, which makes it the default choice for new burstable workloads that can run ARM64. t2 is the older generation with lower baselines and no earned-credit carry-over on stop — avoid it for new work.

Standard vs Unlimited mode — and the billing risk

What happens when credits hit zero depends on the mode:

Unlimited mode’s surplus rate (Linux) is about $0.05 per vCPU-hour for T3/T3a and $0.04 for T4g. That’s the trap: a T3 default is Unlimited, so if a runaway process pins the CPU at 100% for a week, you don’t get throttled — you get a surplus bill that can quietly exceed the cost of a right-sized M instance. A t3.large pinned at 100% in Unlimited can bill more per month than an m7g.large that would have done the job better. The fix is a CloudWatch alarm on CPUSurplusCreditBalance (and CPUCreditBalance approaching zero), and choosing Standard mode when you want a hard cost ceiling and can tolerate throttling.

If CPUCreditUsage is chronically above the earned rate, T is simply the wrong family — you have a steady load, not a bursty one, and you should move to M or C.

M — general purpose

M is the balanced default — 4 GiB of RAM per vCPU — and where you should start when you genuinely don’t know the shape. It fits web/app servers, mid-size relational databases, backends, caching fleets, and most microservices that run at a steady, moderate load. m7i (Intel), m7a (AMD) and m7g (Graviton) are the same shape on three chips.

C — compute-optimized

C gives you 2 GiB per vCPU — more CPU, less memory — for genuinely CPU-bound work: video/audio encoding, build and CI farms, batch processing, game servers, ad-serving, scientific modelling, and tight high-throughput web tiers. If your CloudWatch shows high CPU and low memory, this is where an M box should move.

R, X and z — memory-optimized

Memory-optimized families give you the RAM. R is 8 GiB per vCPU for in-memory caches (Redis/Memcached), real-time analytics, mid-large relational and NoSQL databases, and search. X pushes to 16–32+ GiB per vCPU for large in-memory databases, SAP, and big Spark/analytics. High-memory (u7i/u-*) goes to multiple terabytes for SAP HANA scale-up. z1d / r7iz trade some memory ratio for a sustained ~4.0 GHz clock, which matters for per-core-licensed software (EDA, some databases) and latency-sensitive engines.

I, D, Im, Is — storage-optimized

Storage-optimized families attach local disks physically on the host for very high, very cheap I/O — but that storage is instance store: ephemeral, lost on stop/resize/host failure. Use it for data you can rebuild (caches, scratch, shard replicas, search indexes), never as your only copy.

The number to check on these is IOPS and throughput of the local NVMe, not EBS — that’s the whole point of the family. And the number to remember is that the data disappears on a stop.

P, G, Inf, Trn, DL — accelerated computing

Accelerated families add GPUs or purpose-built ML chips. They are the most expensive instances by a wide margin and — critically for beginners — new accounts start with a 0 On-Demand vCPU quota for them, so your first launch fails until you request an increase.

The lesson for the accelerated tier: right-size the accelerator to the model, not just the vCPU. A model that fits one L4 shouldn’t be on eight H100s. Use G/Inf for inference and reserve P/Trn for real training scale, and expect to manage capacity actively (quotas, Spot, Capacity Blocks) because these are supply-constrained.

HPC — tightly-coupled clusters

Hpc families (hpc6a, hpc7a on AMD; hpc7g on Graviton) are built for MPI workloads where hundreds of nodes must talk with low latency — CFD, weather, molecular dynamics, genomics. They pair high core counts with EFA (Elastic Fabric Adapter) for sub-microsecond inter-node networking, and they’re priced and configured (often no extra EBS-heavy design) for scale-out clusters, not single boxes.

Graviton vs Intel vs AMD — the processor choice

Within most families you can pick the same shape on three chips. This is one of the highest-leverage cost decisions on AWS.

Graviton is the default recommendation for anything you compile yourself or run on a mainstream runtime (Java, Python, Node.js, Go, .NET, most containers) — it’s typically the cheapest and the best price/performance, and every Graviton instance is Nitro-based. AMD is the easy x86 win: same instruction set as Intel, usually ~10% cheaper, drop-in for anything that runs on Intel. Intel earns its premium only when you need AVX-512, a vendor that certifies only on Intel, or the sustained-high-clock z variants.

The Graviton porting caveat

The catch is architecture. A Graviton instance runs ARM64; an x86 binary or container image simply won’t execute — you’ll get exec format error or a container that crashes on start. Before moving to Graviton:

Confirm you’re actually on ARM with uname -m → aarch64. If any dependency is x86-only, either stay on i/a, or run a mixed fleet (ARM where it works, x86 where it doesn’t) behind the same load balancer using multi-arch images.

The Nitro system

Modern instances (C5/M5/R5 and everything newer, and all Graviton) run on the Nitro system — AWS’s re-architecture of the hypervisor. Instead of a heavy software hypervisor stealing CPU for networking and storage, Nitro offloads those jobs to dedicated hardware cards, leaving almost all of the host’s compute for your instance.

What Nitro enables is the practical payoff: ENA and ENA Express high-bandwidth networking (up to 100–200 Gbps on the right sizes), EFA for HPC, EBS volumes presented as NVMe devices, bare-metal (.metal) instances, faster instance provisioning, and consistent performance because I/O no longer competes with your workload for CPU. When you’re comparing an old m4 to an m7g, Nitro is a big part of why the newer box is faster and cheaper.

How specs scale across sizes

The name tells you vCPU and memory, but network and EBS bandwidth also scale with size — and on small sizes they’re burst numbers, not sustained. This trips people constantly. Here’s a real family (m7i) laid out:

Network baseline vs burst

The word “Up to” is the whole story. Sizes at or below roughly 8xlarge–16xlarge in most families get a baseline bandwidth and can burst to the “Up to” figure for a limited window (governed by network I/O credits, similar in spirit to CPU credits). Larger sizes get the figure as a sustained guarantee.

So a c6in.large (network-optimized, “Up to 25 Gbps”) is great for bursty chatter but will throttle to its baseline under a continuous firehose; if you need 25 Gbps sustained, you need a bigger size or a family/size where that number isn’t prefixed “Up to”. The same logic applies to EBS bandwidth: a small size’s “Up to 10 Gbps” to EBS is a burst — a database doing continuous large I/O can be EBS-bandwidth-bound at the instance, and the fix is a bigger instance (or an n/b variant), not a faster volume.

Right-sizing with Compute Optimizer and CloudWatch

Choosing well the first time is half the job; the other half is checking with data and correcting. AWS gives you two tools: CloudWatch (the raw metrics) and Compute Optimizer (recommendations built on them).

The signals

CloudWatch exposes these per-instance metrics. Note the big gap: CPU, network and EBS are free by default, but memory and disk-space are NOT — the hypervisor can’t see inside your OS, so you must install the CloudWatch agent to get mem_used_percent. Sizing on CPU alone is the #1 cause of an OOM after a “right-size.”

Compute Optimizer findings

Compute Optimizer analyses ~14 days of these metrics (93 days with enhanced infrastructure metrics) and classifies each instance, then recommends up to three alternative types with projected utilisation and price.

The finding also carries a reason — CPUOverprovisioned, MemoryUnderprovisioned, EBSThroughputOverprovisioned, NetworkBandwidthUnderprovisioned — which tells you which dimension drove it, and therefore whether the fix is a smaller size or a different family. A box flagged CPUOverprovisioned and MemoryUnderprovisioned shouldn’t just shrink — it should move from C or M toward R.

The cost of over-provisioning

Because price tracks the ladder, right-sizing down one step is a ~50% saving on that box. A quick sense of the stakes (approx us-east-1, On-Demand Linux, ~730 hrs/month; ₹ at ~₹85/$):

Moving from an over-sized m7i.4xlarge to a right-sized, Graviton m7g.xlarge is roughly an 80% cut on that instance — same conceptual workload, matched hardware. That’s why right-sizing is the highest-ROI cost lever after just turning idle things off. Purchasing models (Savings Plans, Spot) stack on top of this and are covered separately — but you always right-size first, because committing to the wrong size just locks in the waste.

Architecture at a glance

The diagram frames selection as a left-to-right funnel: you profile the real workload, decide whether it’s small-and-spiky (a burstable T) or steady, pick the family by CPU:memory ratio (M general, C compute, R/X memory) or a specialised need (I/D local NVMe, or a P/G/Inf/Trn accelerator), and finally land on one concrete type and size that you then right-size with data. Each numbered badge marks the decision that most often goes wrong on that hop — the CPU:mem ratio you must actually measure (1), the T-credit billing trap (2), compute-vs-general confusion (3), the ephemeral-storage surprise (4), accelerator cost and quotas (5), and the decode-then-right-size step at the end (6).

Read it as the exact sequence you’ll follow in the lab below: measure first, branch on shape, choose a type, verify with Compute Optimizer.

Real-world scenario

Streamly, a fictional 40-person video startup in Bengaluru, ran everything on a fleet of m5.2xlarge (8 vCPU / 32 GiB) instances — 30 of them, chosen once during a rushed launch because “general purpose is safe.” The monthly EC2 bill had crept to $11,400 (~₹9.7 lakh), and finance asked the platform team to explain it before renewing a Savings Plan.

The team turned on Compute Optimizer and installed the CloudWatch agent for memory across the fleet, then waited 14 days. The findings were blunt. The web/API tier (12 boxes) was CPUUnderprovisioned and MemoryOverprovisioned — pinned at 85% CPU while using 18% of RAM. That’s a compute-bound workload wearing a general-purpose costume. They moved it to c7g.2xlarge (Graviton, 8 vCPU / 16 GiB): more headroom on the dimension that was tight, half the memory they weren’t using, and the ARM price. Their Java and Node services already had ARM64 builds, so the port was a base-AMI swap and a CI pipeline change.

The transcoding workers (10 boxes) were the opposite of what everyone assumed — not memory-heavy, but EBS-bandwidth-bound: EBSByteBalance% on the m5.2xlarge drained to zero mid-job because the instance’s EBS ceiling (not the volume) capped throughput. They moved these to c7gn.4xlarge (network/EBS-optimized compute) and jobs got ~30% faster with no volume change. The Redis cache tier (5 boxes) was genuinely memory-shaped — 82% RAM, 20% CPU — so it moved up the memory ratio to r7g.xlarge (Graviton, 8 GiB/vCPU), correctly this time. The three admin/back-office boxes averaged 4% CPU with brief spikes; those became t4g.large in Standard mode with a CPUCreditBalance alarm, since a hard cost cap mattered more than never throttling.

Net result before any purchasing commitment: the fleet dropped from 30 m5.2xlarge to a right-shaped mix, and On-Demand spend fell from $11,400 to about $4,900/month — a 57% cut purely from matching hardware to workload and moving suitable tiers to Graviton. Then they bought a Compute Savings Plan on the new, smaller baseline, taking it under $3,400. The lesson the team wrote in their runbook: “General purpose is not a default; it’s a shape. Measure the shape first.”

Advantages and disadvantages

Choosing types deliberately (vs defaulting to one general-purpose SKU everywhere) is a trade-off:

The through-line: the only real cost of doing this well is the discipline to measure before you choose and to re-check periodically. For a single hobby box, defaulting to t3.micro/t4g.micro is fine. For anything with a bill attached, the measure-then-match loop pays for itself in the first month.

Hands-on lab

You’ll use describe-instance-types to pick a type from requirements, launch it, read the right-sizing signals, change its type, and tear it all down. Free-tier-friendly (t3.micro/t4g.micro are eligible; everything else here is metadata queries that cost nothing). Set your region first.

export AWS_REGION=us-east-1
export AWS_DEFAULT_REGION=us-east-1

⚠️ Cost note: a running t3.micro/t4g.micro is free-tier-eligible for the first 12 months (750 hrs/month). The describe-* calls are free. If you launch anything larger than micro, you pay by the second while it runs — the teardown at the end stops the meter.

Step 1 — Decode a name before you trust it

Confirm what a type actually is, straight from the API:

aws ec2 describe-instance-types --instance-types m7g.2xlarge \
  --query "InstanceTypes[0].{vCPU:VCpuInfo.DefaultVCpus, MemMiB:MemoryInfo.SizeInMiB, Arch:ProcessorInfo.SupportedArchitectures, Net:NetworkInfo.NetworkPerformance, Burstable:BurstablePerformanceSupported}" \
  --output table

Expected output:

--------------------------------------------------------
|                 DescribeInstanceTypes                |
+-----------+----------+---------+----------+-----------+
|   Arch    | Burstable|  MemMiB |   Net    |   vCPU    |
+-----------+----------+---------+----------+-----------+
|  arm64    |  False   |  32768  | Up to 15 Gbps | 8    |
+-----------+----------+---------+----------+-----------+

That confirms the decode: m7g is arm64 (Graviton), 2xlarge is 8 vCPU / 32768 MiB (32 GiB), not burstable, “Up to 15 Gbps” (burst) network.

Step 2 — Let the API pick a type from requirements

Say the workload needs 4 vCPU, 16 GiB, ARM64, current generation, and it must NOT be burstable (steady load). Filter for exactly that:

aws ec2 describe-instance-types \
  --filters "Name=processor-info.supported-architecture,Values=arm64" \
            "Name=vcpu-info.default-vcpus,Values=4" \
            "Name=memory-info.size-in-mib,Values=16384" \
            "Name=current-generation,Values=true" \
            "Name=burstable-performance-supported,Values=false" \
  --query "sort_by(InstanceTypes, &InstanceType)[].InstanceType" \
  --output text

Expected (an M-family, 4:1 ratio, ARM64 result set):

m6g.xlarge      m6gd.xlarge     m7g.xlarge      m7gd.xlarge

m7g.xlarge is the pick: newest generation, no local disk you don’t need. The useful describe-instance-types filters:

Step 3 — Check the type is offered in your AZ

A type can exist in a region but not every AZ. Confirm before you launch:

aws ec2 describe-instance-type-offerings \
  --location-type availability-zone \
  --filters "Name=instance-type,Values=m7g.xlarge" \
  --query "InstanceTypeOfferings[].Location" --output text

Expected: the AZs that offer it, e.g. us-east-1a us-east-1b us-east-1d us-east-1f. If your subnet’s AZ isn’t listed, launching there returns “not supported in your requested Availability Zone.”

Step 4 — Launch a free-tier instance (CLI)

We’ll launch a t3.micro to keep it free, using the latest Amazon Linux 2023 AMI resolved from SSM.

AMI=$(aws ssm get-parameters \
  --names /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --query "Parameters[0].Value" --output text)

SG=$(aws ec2 create-security-group \
  --group-name ec2-sizing-lab --description "sizing lab" \
  --query GroupId --output text)

IID=$(aws ec2 run-instances \
  --image-id "$AMI" --instance-type t3.micro \
  --security-group-ids "$SG" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=sizing-lab}]' \
  --query "Instances[0].InstanceId" --output text)

echo "Launched $IID on the $AMI AMI"
aws ec2 wait instance-running --instance-ids "$IID"

Expected: Launched i-0abc123... on the ami-0abc... AMI, then the wait returns silently when it’s running.

Step 5 — Read the right-sizing signals

Pull recent CPU from CloudWatch (memory would need the agent — that’s the point of the OOM warning later):

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value="$IID" \
  --start-time "$(date -u -v-1H +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 300 --statistics Average Maximum --output table

A brand-new idle box reads near 0–2% average — the textbook over-provisioned signal if this were a real, steady workload. To see Compute Optimizer’s verdict (after you’ve opted in and given it ~14 days on a real instance):

aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns "arn:aws:ec2:${AWS_REGION}:$(aws sts get-caller-identity --query Account --output text):instance/${IID}" \
  --query "instanceRecommendations[0].{Finding:finding, Current:currentInstanceType, Rec:recommendationOptions[0].instanceType}" \
  --output table

On a fresh instance you’ll get a finding of None (not enough data yet); on a mature one you’d see Over-provisioned with a smaller Rec.

Step 6 — Change the instance type (stop / modify / start)

You can’t change type on a running instance — stop it, modify, start it. (Behind an Auto Scaling group you’d instead change the launch template and roll the fleet, with no downtime.)

aws ec2 stop-instances --instance-ids "$IID"
aws ec2 wait instance-stopped --instance-ids "$IID"

aws ec2 modify-instance-attribute \
  --instance-id "$IID" --instance-type "{\"Value\": \"t3.small\"}"

aws ec2 start-instances --instance-ids "$IID"
aws ec2 wait instance-running --instance-ids "$IID"

aws ec2 describe-instances --instance-ids "$IID" \
  --query "Reservations[0].Instances[0].InstanceType" --output text

Expected final line: t3.small. Note we stayed on x86 (t3 → t3); switching to Graviton (t4g) would also require an ARM64 AMI, so you can’t just modify the type on an x86 AMI and expect it to boot.

Step 7 — The same launch in Terraform

For the IaC path, the type is one attribute — which is exactly why standardising it matters. var.instance_type makes right-sizing a one-line change and terraform apply.

terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}
provider "aws" { region = "us-east-1" }

variable "instance_type" {
  type    = string
  default = "t3.micro" # right-size here; one line, one apply
}

data "aws_ssm_parameter" "al2023" {
  name = "/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64"
}

resource "aws_instance" "sizing_lab" {
  ami           = data.aws_ssm_parameter.al2023.value
  instance_type = var.instance_type
  tags          = { Name = "sizing-lab-tf" }
}

output "chosen_type" { value = aws_instance.sizing_lab.instance_type }

terraform init && terraform apply -auto-approve
# to right-size later, no code edit needed:
terraform apply -auto-approve -var="instance_type=t3.small"

Changing instance_type on an existing aws_instance triggers a stop → modify → start in place (Terraform handles it) — the same flow as the CLI, not a destroy/recreate, as long as the AMI architecture still matches.

Step 8 — Teardown

Stop the meter and remove everything.

# CLI path:
aws ec2 terminate-instances --instance-ids "$IID"
aws ec2 wait instance-terminated --instance-ids "$IID"
aws ec2 delete-security-group --group-id "$SG"

# Terraform path:
terraform destroy -auto-approve

Verify nothing is left running: aws ec2 describe-instances --filters "Name=tag:Name,Values=sizing-lab,sizing-lab-tf" --query "Reservations[].Instances[].State.Name" --output text should show terminated (or nothing).

Common mistakes & troubleshooting

The playbook. Each row is a real failure with the exact way to confirm it and the fix.

Error/status reference

The three that hurt most

T-credit throttling (rows 1–2) is the classic beginner trap because it’s invisible in code and CPU-percent looks fine (it’s just capped). Always chart CPUCreditBalance; if it trends to zero under real load, you have a steady workload on a bursty family — the answer is M or C, not “buy more credits.” Memory-blind right-sizing (row 4) happens because CloudWatch shows no memory by default, so Compute Optimizer returns None or reasons only about CPU; install the agent before you resize down, or you’ll shrink into an OOM. EBS-bandwidth-bound (row 5) fools people into buying faster volumes (io2, more IOPS) that change nothing, because the ceiling is the instance’s EBS bandwidth — chart EBSByteBalance%/EBSIOBalance%, and if they drain, size the instance up or pick an n/b variant.

Best practices

• Measure before you choose. Get 14 days of CloudWatch (with the agent for memory) and read the CPU:memory ratio; let the shape pick the family, not habit.
• Default to the newest generation. A 7-gen box is usually faster and cheaper than the 5-gen it replaces — there’s rarely a reason to launch old silicon.
• Default to Graviton where you can. For anything you compile or run on a mainstream runtime, g is the best price/performance; fall back to a (AMD) for cheap x86, and i (Intel) only for a real reason (AVX-512, ISV cert, z clock).
• Right-size before you commit. Never buy a Savings Plan or Reserved Instance on an over-sized baseline — shrink first, then commit to the smaller number.
• Alarm on burstable credits. For every T instance, alarm on CPUCreditBalance nearing zero and CPUSurplusCreditBalance rising — or use Standard mode for a hard cost cap.
• Never store your only copy on instance store. d/I/D/Im/Is local NVMe is ephemeral; persist anything you can’t rebuild to EBS or S3.
• Standardise types behind Auto Scaling. Put the type in a launch template/Terraform variable so right-sizing is a one-line change rolled with no downtime.
• Use attribute-based instance selection (in ASGs/Spot) to specify requirements (vCPU/mem/arch) and let AWS pick from many matching types — more capacity, better Spot pricing.
• Check AZ/region availability early. Confirm the type is offered where your subnet lives (describe-instance-type-offerings) before you hard-code it.
• Re-check quarterly. Workloads drift; a box that was right last quarter may be over-provisioned now. Compute Optimizer is free — schedule a look.
• Match memory-tight to R, CPU-tight to C. A box flagged both CPUOverprovisioned and MemoryUnderprovisioned should change family, not just size.

Security notes

Instance-type choice is mostly a cost/performance decision, but a few security threads run through it:

Least-privilege the ability to launch expensive families: an IAM policy with a Condition on ec2:InstanceType can stop a developer from accidentally launching a p5.48xlarge.

Cost & sizing

What actually drives an EC2 instance’s bill:

Rough On-Demand Linux us-east-1 anchors (approximate — always check the pricing page; ₹ at ~₹85/$):

Free tier: 750 hours/month of t3.micro (or t2.micro, or t4g.micro where offered) for the first 12 months — enough to run one small instance 24×7 free. Beyond that, the cheapest real production shapes are the Graviton t4g/m7g/c7g/r7g line. Right-sizing is the biggest lever, then Graviton, then turning off idle non-prod, then (separately) Savings Plans/Spot on the corrected baseline.

Interview & exam questions

Q1. Decode r7iz.4xlarge. (CLF-C02 / SAA-C03) Memory-optimized (r), 7th generation, Intel (i) with high-frequency clock (z), size 4xlarge = 16 vCPU / ~128 GiB at a sustained ~4.0 GHz. You’d pick it for memory-heavy, per-core-licensed, or latency-sensitive work.

Q2. A t3.large API is fast most of the day but crawls every afternoon. Why, and how do you confirm it? It’s exhausting CPU credits and (in Standard mode) being throttled to its 30%/vCPU baseline. Confirm with CloudWatch CPUCreditBalance trending to zero while CPUUtilization pins at baseline. If load is steady, move to M/C; T is for bursty, not sustained.

Q3. What’s the billing risk of Unlimited mode? When credits run out, an Unlimited-mode T instance keeps bursting and bills surplus credits (~$0.05/vCPU-hr for T3 Linux). A pinned CPU can silently exceed a right-sized M instance’s cost. Mitigate with a CPUSurplusCreditBalance alarm or Standard mode.

Q4. When would you choose C over M? When the workload is CPU-bound — high CPU, low memory (a ~2:1 GiB/vCPU shape). Encoding, build farms, game servers, tight web tiers. Compute Optimizer flagging CPUUnderprovisioned + MemoryOverprovisioned on an M box is the signal.

Q5. Graviton is cheaper — why not use it everywhere? Graviton is ARM64; x86-only binaries/containers won’t run (exec format error). You need arm64 AMIs and multi-arch images, and some ISV agents lack ARM builds. Use it wherever your stack has ARM64 support (most mainstream runtimes do).

Q6. Your database’s disk throughput is stuck below the volume’s rated MBps. What’s likely wrong? The instance’s EBS bandwidth ceiling (not the volume) is the bottleneck — the box is EBS-bandwidth-bound. Confirm with EBSByteBalance%/EBSIOBalance% draining to zero. Fix by sizing the instance up or using an n/b variant; a faster volume won’t help.

Q7. What does the Nitro system give you? (SAA-C03) Hardware offload of networking/storage to Nitro Cards, a thin KVM-based hypervisor, and a security chip — yielding near-bare-metal performance, ENA/EFA high-bandwidth networking, EBS-as-NVMe, and bare-metal instances. All modern and all Graviton instances are Nitro-based.

Q8. How do Compute Optimizer findings map to actions? Under-provisioned → size up or change family toward the tight dimension; Over-provisioned → size down / cheaper family or Graviton; Optimized → leave (maybe try Graviton); None → not enough data (14 days) or no memory agent. The reason code tells you which dimension drove it.

Q9. Why can right-sizing on CPU alone cause an outage? CloudWatch shows no memory without the agent, so you might shrink a memory-tight box and get OOM-killed. Always install the CloudWatch agent for mem_used_percent before resizing down, and reason about memory, not just CPU.

Q10. What’s the difference between “Up to 12.5 Gbps” and “12.5 Gbps”? “Up to” is a burst ceiling on smaller sizes with a lower sustained baseline (network I/O credits); the bare number is sustained. A continuous transfer on an “Up to” size settles below the headline — size up or use an n variant for sustained throughput.

Q11. How do you change an instance’s type, and what constrains it? Stop → modify-instance-attribute --instance-type → start. Constraints: the AMI must match the target’s architecture (can’t x86→Graviton) and virtualization (Nitro/HVM, ENA/NVMe support); the type must be offered in the AZ; instance-store data is lost on stop.

Q12. New account, first GPU launch fails with a vCPU limit. Why? Accelerated families (P/G) have an On-Demand vCPU quota of 0 on new accounts. Request an increase in Service Quotas (“Running On-Demand G/P instances”), or use Spot / Capacity Blocks for GPU capacity.

Quick check

1. Split c6gd.4xlarge into family, generation, attributes, and size — and say what each attribute means.
2. Your t3.medium shows CPUCreditBalance at zero every afternoon and latency triples. What’s happening and what’s the fix?
3. A workload runs at 90% CPU and 22% memory on an m7i.2xlarge. Which family should it move to, and why?
4. Why is “the data disappeared after I stopped the instance” a type-selection bug, and which families cause it?
5. You want the cheapest way to run a steady Java service that has an ARM64 build. Which processor attribute, and what must you verify first?

Answers

1. Family c (compute-optimized) · generation 6 · attributes gd = g (Graviton/ARM64) + d (local NVMe instance store) · size 4xlarge (16 vCPU / 32 GiB). It’s an ARM compute box with fast ephemeral local disk.
2. The T instance has exhausted its CPU credits and, in Standard mode, is being throttled to its 20%/vCPU baseline. The load is steady, not bursty, so the fix is to move to M or C, not to buy more credits or flip to Unlimited (which would just bill surplus).
3. C (compute-optimized) — the shape is CPU-bound (~2:1 GiB/vCPU), so it’s paying for idle memory on M (4:1). Move to the same-size c7g/c7i.2xlarge (or up one C size for headroom); Compute Optimizer would flag CPUUnderprovisioned + MemoryOverprovisioned.
4. Because you chose a family whose storage is instance store (ephemeral): the d attribute and the I/D/Im/Is storage families put NVMe physically on the host, and that data is lost on stop/resize/host failure. It’s a type decision, not an app bug. Persist anything you can’t rebuild to EBS/S3.
5. Use g (Graviton) — e.g. m7g/c7g. First verify your AMI is arm64 and your runtime/containers have ARM64 builds (multi-arch images); confirm on the box with uname -m = aarch64. Fall back to a (AMD) if any dependency is x86-only.

Glossary

Next steps

• Launch Your First EC2 Instance and SSH In — the end-to-end first launch: key pair, security group, connect, and the console-vs-CLI paths for the type you just learned to pick.
• EC2 User Data and cloud-init Bootstrapping — once you’ve chosen the type, bootstrap the OS on boot so instances come up configured.
• AWS Compute: EC2, Lambda, ECS and EKS — Which One to Choose? — the step before this one: confirm EC2 is even the right service versus serverless and containers.
• Purchasing models (On-Demand, Spot, Savings Plans, Reserved) — the independent second axis: once the shape is right, commit to the cheapest way to pay for it.
• Auto Scaling groups & attribute-based instance selection — put the chosen type in a launch template and let AWS pick from many matching types for capacity and Spot savings.