How to Choose the Right Instance Type

Picking an EC2 (Elastic Compute Cloud, AWS’s virtual server service) instance type feels like guessing because AWS offers hundreds of options. The good news: you do not need to guess. There is a repeatable process — profile your workload, pick a family, start small, measure, then adjust. This page walks through that method and shows the single biggest cost win most teams miss: right-sizing down.

The mental model: families and sizes

Every EC2 instance type is written as a family + generation + size, like m7g.large. Break it down:

Family letter(s) — the broad purpose. m = general purpose (balanced), c = compute optimized (CPU heavy), r = memory optimized (RAM heavy), t = burstable (cheap, occasional bursts).
Generation number — 7 means 7th generation. Higher is newer, faster, and usually cheaper per unit of work.
Processor suffix — g = Graviton (AWS’s own ARM chip), i = Intel, a = AMD. No letter often means Intel.
Size — nano, micro, small, medium, large, xlarge, 2xlarge, and up. Each step roughly doubles CPU (the processor, or vCPUs) and memory (RAM).

The vCPU-to-memory ratio is the key. A c family gives you 2 GB of RAM per vCPU; an r family gives you 8 GB per vCPU. Your job is to match that ratio to your workload.

Step 1 — Profile the workload

Before touching the console, decide what your app is hungry for. Most workloads are either CPU bound or memory bound.

Workload signal	Likely bottleneck	Start with family
Video encoding, batch math, build servers, game servers	CPU	`c` (compute optimized)
In-memory caches, databases, big data, analytics	Memory	`r` (memory optimized)
Web apps, microservices, dev boxes (mixed/unsure)	Balanced	`m` (general purpose)
Low-traffic sites, small APIs, occasional spikes	Mostly idle	`t` (burstable)

When to use burstable (t) and when NOT to: Use t4g/t3 for things that sit idle most of the day and spike occasionally — a low-traffic blog, a staging server, a cron job runner. Do NOT use burstable for steady high CPU work: t instances earn “CPU credits” while idle and spend them when busy, so a constantly busy t instance runs out of credits and throttles (or quietly bills you extra under “unlimited mode”).

Step 2 — Start small and measure

Do not size for peak traffic on day one. Pick the smallest instance in your chosen family that can boot your app, then watch real numbers. AWS gives you the metrics for free in CloudWatch (the AWS monitoring service).

Watch three metrics for a few days under real load:

CPUUtilization — if it sits below ~40%, you are paying for CPU you do not use.
Memory used — not collected by default; install the CloudWatch agent to see RAM.
NetworkIn / NetworkOut — matters for high-traffic or data-transfer-heavy apps.

Pull CPU utilization for an instance from the CLI:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0a1b2c3d4e5f \
  --start-time 2026-06-08T00:00:00Z \
  --end-time 2026-06-15T00:00:00Z \
  --period 3600 \
  --statistics Average Maximum

Output:

{
    "Label": "CPUUtilization",
    "Datapoints": [
        { "Timestamp": "2026-06-14T09:00:00Z", "Average": 12.4, "Maximum": 31.8, "Unit": "Percent" },
        { "Timestamp": "2026-06-14T10:00:00Z", "Average": 14.1, "Maximum": 28.5, "Unit": "Percent" }
    ]
}

An average around 12% means this box is far too big. That is the over-provisioning trap — and the chance to save money.

Step 3 — Let Compute Optimizer do the math

AWS Compute Optimizer is a free service that reads your CloudWatch history and recommends a better, usually smaller, instance type. It is the fastest way to right-size without staring at graphs yourself.

Console steps:

Open the Compute Optimizer console.
Choose Get started, then Opt in (it needs permission to read your metrics).
Wait up to 24 hours for it to analyze, then open EC2 instances under Recommendations.
Each instance is tagged Under-provisioned, Optimized, or Over-provisioned, with up to three suggested types and the estimated monthly saving.

CLI equivalent:

aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:us-east-1:111122223333:instance/i-0a1b2c3d4e5f

Output:

{
    "instanceRecommendations": [
        {
            "instanceArn": "arn:aws:ec2:us-east-1:111122223333:instance/i-0a1b2c3d4e5f",
            "currentInstanceType": "m6i.2xlarge",
            "finding": "OVER_PROVISIONED",
            "recommendationOptions": [
                { "instanceType": "m7g.large", "rank": 1, "savingsOpportunity": { "estimatedMonthlySavings": { "value": 218.40 } } }
            ]
        }
    ]
}

Step 4 — Resize the instance

You can change the type of an existing instance, but you must stop it first (this works only for EBS-backed instances, which is the default).

Console steps:

In the EC2 console, select the instance and choose Instance state -> Stop instance.
With it stopped, choose Actions -> Instance settings -> Change instance type.
Pick the new type (for example m7g.large) and choose Apply.
Choose Instance state -> Start instance.

CLI equivalent:

aws ec2 stop-instances --instance-ids i-0a1b2c3d4e5f
aws ec2 modify-instance-attribute \
  --instance-id i-0a1b2c3d4e5f \
  --instance-type "{\"Value\": \"m7g.large\"}"
aws ec2 start-instances --instance-ids i-0a1b2c3d4e5f

Switching from Intel/AMD to a Graviton (ARM) type like m7g changes the CPU architecture. Your AMI (Amazon Machine Image, the disk template) and all installed software must be built for ARM. Test in staging first — a mismatched binary simply will not run.

The Graviton cost win

Graviton instances (the g suffix) use AWS’s own ARM-based chips. For most modern, recompiled software they deliver the same performance for roughly 20% less money than the equivalent Intel/AMD type. If your stack is Java, Python, Node.js, Go, .NET 8+, or runs in containers, ARM support is usually a one-line build change.

Type	vCPU	Memory	Approx. on-demand /month (us-east-1)
`m6i.large` (Intel)	2	8 GB	~$70
`m7g.large` (Graviton)	2	8 GB	~$59

That is real money at scale: 50 such instances save over $6,000 a year for the same work.

Best Practices

Profile CPU-vs-memory before choosing a family — never default to whatever the wizard suggests.
Start one size smaller than you think you need; scaling up is a two-minute restart, while overpaying is silent and permanent.
Turn on Compute Optimizer account-wide and review its recommendations monthly — right-sizing down is the biggest single EC2 cost win for most teams.
Prefer the newest generation (m7g over m5); newer chips are faster and cheaper.
Default to Graviton for new workloads and switch existing ones once tested on ARM.
Use burstable (t) only for idle-most-of-the-day workloads; use fixed-performance families for anything steadily busy.
Tag instances by environment and owner so you can spot and kill forgotten oversized boxes.