EC2 Instance Types & Families

When you launch an EC2 instance (Elastic Compute Cloud, AWS’s rentable virtual servers) you have to pick an instance type like m6i.large. That short string tells AWS exactly how much CPU, memory, networking, and what kind of processor you want. There are hundreds of types, but they all follow one simple naming scheme and group into a handful of families, each tuned for a different shape of workload. Once you can read the name, choosing the right one stops being guesswork and the bill stops being a surprise.

How to read an instance type name

Take m6i.large apart left to right:

Part	Value	Meaning
Family	m	The workload category — general purpose here
Generation	6	The hardware generation; higher is newer, faster, often cheaper per unit
Attributes	i	Extra qualifiers — i = Intel, a = AMD, g = Graviton (Arm), d = local disk, n = extra network
Size	large	How big a slice you get: nano, micro, small, medium, large, xlarge, 2xlarge … up to 48xlarge

So m6i.large is a 6th-generation, general-purpose, Intel instance at the large size (2 vCPUs, 8 GiB RAM). A c7g.2xlarge is a 7th-gen compute-optimized Graviton (Arm) instance, twice the size of an xlarge.

Tip: Each step up in size roughly doubles vCPUs, memory, and price. large to xlarge doubles; xlarge to 2xlarge doubles again. A vCPU is a virtual CPU — usually one thread of a physical processor core.

The main families

The first letter is the most important choice. It sets the ratio of CPU to memory.

Family	Optimized for	vCPU:Memory ratio	Typical use
T (t3, t4g)	Burstable, low cost	1:2 to 1:4	Dev boxes, small websites, bursty/idle workloads
M (m6i, m7g)	General purpose / balanced	1:4	Web/app servers, microservices, default choice
C (c6i, c7g)	Compute	1:2	CPU-heavy work: batch, encoding, game servers, scientific compute
R (r6i, r7g)	Memory	1:8	In-memory caches, large databases, real-time analytics
G / P (g5, p5)	GPU accelerated	Varies	Machine learning, video rendering, graphics
I (i4i, im4gn)	Storage / fast local disk	1:8 with NVMe SSD	High-IOPS databases, big data, search engines

When to use which

• Start with M. If you don’t know, a general-purpose m type is the safe default — balanced CPU and memory.
• Move to C when you watch CPU pinned near 100% but memory sits half-empty. You’re paying for RAM you don’t use.
• Move to R when the opposite happens — memory is the bottleneck (databases, caches like Redis).
• Use G or P only for GPU work; they are expensive (often several dollars per hour) and wasteful for plain web traffic.
• Use I when your app needs very fast local disk and can tolerate that disk being wiped on stop (see Instance Store).

The T family: burstable, with a catch

T-family instances (t3, t3a, t4g) are the cheapest and most popular for small workloads, but they work differently from every other family, and this trips people up.

A T instance has a baseline CPU performance (a fraction of a full vCPU). When it runs below baseline, it earns CPU credits. When it needs to run above baseline — a traffic spike, a build job — it spends those credits to burst up to full speed. Each credit buys one minute of one vCPU at 100%.

This is perfect for bursty, mostly-idle workloads: a dev server, a low-traffic blog, a cron job that runs once an hour. You burst when needed, idle the rest of the time, and pay very little.

The danger is a steady, CPU-bound workload. It burns credits faster than it earns them, the balance hits zero, and the instance silently throttles down to baseline — sometimes just 10-20% of a vCPU. Your app doesn’t crash; it just gets mysteriously, permanently slow. There’s no error in the logs, only a CPU graph flatlining at baseline.

Warning: A T-family instance under constant load will quietly slow to its baseline once credits run out. If your CPU graph plateaus at a flat percentage and stays there, you’ve exhausted credits. For steady CPU work, switch to an m, c, or r type — not a bigger t.

Watching credits and the unlimited option

Monitor the CPUCreditBalance metric in CloudWatch (AWS’s monitoring service). A balance trending toward zero on a busy instance is the red flag.

T instances also have an unlimited mode (the default for t3/t4g). When credits run out it keeps bursting and charges a small per-vCPU-hour surcharge instead of throttling. Convenient, but if the load is sustained those surcharges can quietly exceed the cost of just running an m type — so for anything constantly busy, move families rather than relying on unlimited.

aws ec2 describe-instance-credit-specifications --instance-ids i-0a1b2c3d4e5f

Output:

{
    "InstanceCreditSpecifications": [
        {
            "InstanceId": "i-0a1b2c3d4e5f",
            "CpuCredits": "unlimited"
        }
    ]
}

To switch a steady workload to standard mode (throttle instead of pay surcharges) so a cost spike can’t sneak up on you:

aws ec2 modify-instance-credit-specification \
  --instance-credit-specification InstanceId=i-0a1b2c3d4e5f,CpuCredits=standard

Choosing and changing the type

In the AWS Console

1. Sign in to the AWS Management Console and open the EC2 console.
2. In the Launch instance wizard, find the Instance type dropdown and pick e.g. m6i.large. Each option lists its vCPUs and memory.
3. To change an existing instance’s type, select it, choose Instance state -> Stop instance, wait for stopped, then Actions -> Instance settings -> Change instance type, pick the new type, and start it again.

With the AWS CLI

To resize, the instance must be stopped first (you cannot change the type while it’s running):

aws ec2 stop-instances --instance-ids i-0a1b2c3d4e5f
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f --instance-type c6i.xlarge
aws ec2 start-instances --instance-ids i-0a1b2c3d4e5f

Output:

{
    "StoppingInstances": [
        {
            "InstanceId": "i-0a1b2c3d4e5f",
            "CurrentState": { "Name": "stopping" },
            "PreviousState": { "Name": "running" }
        }
    ]
}

In a launch template defined with Terraform, the type is a single field:

resource "aws_launch_template" "app" {
  name_prefix   = "app-"
  image_id      = "ami-0abcdef1234567890"
  instance_type = "m6i.large"
}

Cost note: Newer generations are usually a better deal. A c7g.large (Graviton/Arm) is typically 15-20% cheaper per hour than a c6i.large (Intel) and often faster — moving from old to new generation can cut cost while improving performance. The catch with Graviton is that your software must support Arm64.

Best practices

• Start with an m (general purpose) type, then move to c or r only after CloudWatch shows CPU or memory is the real bottleneck.
• Right-size regularly: pick the smallest type that keeps utilization in a healthy range (roughly 40-70%) rather than over-provisioning “to be safe.”
• Reserve T-family for bursty or idle workloads; never run a steady, CPU-bound app on a t type expecting full speed.
• Watch CPUCreditBalance on every T instance, and set standard mode if surprise unlimited surcharges concern you.
• Prefer the newest generation and consider Graviton (g suffix) for cheaper, faster compute when your stack supports Arm64.
• Stop an instance before changing its type — resizing requires the stopped state.

Related Topics

• Choosing the right instance type
• Graviton instances
• EC2 pricing
• EC2 monitoring
• Launch templates