AWS EC2 Instance Types

There are several hundred EC2 instance types. The naming is systematic, so once you can decode it the choice narrows quickly, and two simple rules ("newest generation" and "consider Graviton") capture most of the available savings.

Reading the name

m6i.xlarge has four parts:

So c7g.4xlarge is compute-optimised, seventh generation, Graviton, four times the base extra-large size.

Sizes scale predictably, 2xlarge has twice the vCPU and memory of xlarge, and roughly twice the price. That linearity means there is rarely a cost advantage in picking an awkward size.

The families

Start from the bottleneck. If the workload is waiting on CPU, c. If it is holding a large dataset in memory, r. If neither dominates, m.

Two rules that capture most of the savings

Use the newest generation available. An m7i typically costs less than an m5 and performs better. Upgrading generation is usually a stop and start, and it is close to free money. Check what is available in your region:

aws ec2 describe-instance-type-offerings \
  --location-type availability-zone \
  --filters Name=instance-type,Values=m7i.large \
  --region eu-west-1

Consider Graviton. AWS's ARM processors are roughly 20% cheaper for equivalent performance and often faster. For containers, interpreted languages, and anything with an ARM build, migration is frequently a base image change and a rebuild.

It applies well beyond EC2. RDS, ElastiCache, OpenSearch and Lambda all have Graviton options, and switching an RDS instance class to db.m6g is a maintenance-window change with an immediate permanent saving.

The constraint is genuine but narrow: compiled binaries need an ARM build, and a few commercial agents remain x86-only. Test rather than assume.

Burstable instances and the credit trap

The t family is cheap because it does not give you a full core continuously. Each instance has a baseline percentage of a vCPU and earns CPU credits while running below it, spending them to burst above.

Run out of credits and the instance is throttled hard, sometimes to 20% of a core. The symptom is an application that is inexplicably slow while CloudWatch shows low CPU utilisation, because the utilisation figure is of the throttled allowance.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-0abc123 \
  --start-time 2026-09-14T00:00:00Z --end-time 2026-09-15T00:00:00Z \
  --period 3600 --statistics Minimum

A credit balance trending toward zero means the workload does not fit the family.

Unlimited mode lets it burst past the balance for a surcharge, which is fine until a runaway process produces a surprising bill. For anything with sustained load, an m instance is both cheaper and more predictable than a t instance in unlimited mode.

Use t for genuinely bursty or idle workloads. Do not use it for production services with steady traffic.

Size from data, not guesswork

Over-provisioning is close to universal, because sizing is usually a guess made once and never revisited.

AWS Compute Optimizer analyses real CloudWatch utilisation and recommends a size, including cross-family and Graviton options:

aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[].{Instance:instanceArn,Current:currentInstanceType,Finding:finding,Recommended:recommendationOptions[0].instanceType}' \
  --output table

|  Instance     |  Current    |  Finding        |  Recommended  |
|  i-0abc123    |  m5.2xlarge |  OVER_PROVISIONED|  m6g.large   |

Two caveats worth knowing. Memory utilisation is not visible to CloudWatch without the CloudWatch agent, so recommendations are CPU-weighted unless you have installed it. And it needs at least 14 days of data to be meaningful.

Changing instance type

Not a live operation. The instance must be stopped:

aws ec2 stop-instances --instance-ids i-0abc123
aws ec2 wait instance-stopped --instance-ids i-0abc123
aws ec2 modify-instance-attribute --instance-id i-0abc123 --instance-type m7i.large
aws ec2 start-instances --instance-ids i-0abc123

Two things to expect. Instance store data is lost on stop. And the instance gets a new public IP on restart unless an Elastic IP is attached.

If the workload sits behind a launch template and an Auto Scaling group, which it should, changing the type is a template update and an instance refresh, with no manual stop at all.

Pricing shorthand

Commit to your baseline with a Compute Savings Plan, and run anything fault-tolerant on Spot.

Quick reference

---

Key takeaways

• m6i.xlarge = family, generation, attributes, size. Decoding the name narrows the choice fast.
• Always use the newest generation: usually cheaper and faster than the one before.
• Graviton is ~20% cheaper and applies to RDS, ElastiCache and Lambda as well as EC2.
• t instances throttle when credits run out, which looks like slowness at low reported CPU.
• Unlimited mode removes the throttle and adds a surcharge: for steady load, an m instance is cheaper.
• Use Compute Optimizer, remembering it cannot see memory without the CloudWatch agent.
• Changing instance type requires a stop, which loses instance store data and the public IP.

---

Check your understanding

---

Frequently Asked Questions

How do I read an EC2 instance type name?

m6i.xlarge breaks into family, generation, attributes and size. The letter is the family, t burstable, m balanced, c compute-optimised, r memory-optimised, i storage-optimised, p and g accelerated. The number is the generation, where higher is newer. Trailing letters indicate the processor and features: i Intel, a AMD, g Graviton, d local NVMe storage, n enhanced networking. The suffix is the size, scaling roughly linearly in both resources and price.

Which EC2 instance family should I choose?

Start from the bottleneck. c for CPU-bound work such as build agents and batch processing, r for memory-bound workloads like databases and caches, m when neither dominates, and t only for genuinely bursty or mostly-idle workloads. Then pick the newest generation available and check whether a Graviton variant works for you. Size from Compute Optimizer recommendations rather than estimating, since over-provisioning is close to universal.

Are Graviton instances worth switching to?

Usually yes, around 20% cheaper for equivalent performance, and often faster. For containerised workloads and interpreted languages such as Python, Node and Ruby, the migration is frequently a base image change and a rebuild. Compiled code needs an ARM build, which is normally straightforward but worth testing. The saving extends beyond EC2 to RDS, ElastiCache, OpenSearch and Lambda, so switching a database instance class to db.m6g is a quick permanent win.

When should I use t3 or t4g burstable instances?

For workloads that are genuinely idle most of the time and occasionally busy. Development environments, internal tools, low-traffic services. They are poor for production services under steady load, because once CPU credits are exhausted the instance is throttled to its baseline, producing slowness that is hard to diagnose since reported CPU stays low. Unlimited mode removes the throttle for a surcharge, but at sustained load an m family instance is usually both cheaper and more predictable.

How do I know if my instance is the right size?

Use AWS Compute Optimizer, which analyses real CloudWatch utilisation over at least 14 days and recommends a size, including cross-family and Graviton alternatives. Note that memory usage is invisible to CloudWatch unless the CloudWatch agent is installed, so without it recommendations are weighted toward CPU and may suggest a size too small for a memory-bound workload. Installing the agent as part of your base image makes the recommendations considerably more trustworthy.

Can I change an instance type without downtime?

Not for a standalone instance. It must be stopped, modified and started, which loses any instance store data and assigns a new public IP unless an Elastic IP is attached. If the workload runs behind a launch template and an Auto Scaling group, changing the type is a template update followed by an instance refresh, which replaces instances gradually with no downtime. That is one of several reasons to put even single instances behind an Auto Scaling group.