← All guides

Learn

EC2 instance types decoded — how to read the name and pick the right one

What m7g.xlarge actually tells you, what each instance family is for, when burstable T instances save money and when they quietly throttle you, and the pricing models worth knowing before you launch anything.

Updated 2026-08-02

There are hundreds of EC2 instance types and the names look like noise. They are not — the name is a structured description, and once you can read it the catalogue collapses into a handful of decisions.

Reading the name

m7g.xlarge
│││  └── size
││└───── attributes (g = AWS Graviton / ARM)
│└────── generation (7th)
└─────── family (m = general purpose)

So m7g.xlarge is a 7th-generation, general-purpose, Graviton-based instance in the xlarge size. And c6i.2xlarge is a 6th-generation compute-optimised instance on Intel, twice the size of xlarge.

Common attribute letters:

Newer generations are usually cheaper per unit of work. An m7 typically outperforms an m6 at similar or lower cost. Staying on old generations out of habit is a quiet, permanent overspend.

The families

The rough memory-per-vCPU ratios: c gives about 2 GB, m about 4 GB, r about 8 GB. If you know your workload's shape, that ratio alone narrows the choice to one family.

Sizes double, and so does price

Sizes run nano, micro, small, medium, large, xlarge, 2xlarge, 4xlarge, and upward. Each step roughly doubles vCPU, memory, network bandwidth — and price.

The pricing is almost perfectly linear, which has a useful consequence: two large instances cost about the same as one xlarge, but survive one of them failing. Scaling horizontally is usually the better buy for anything stateless, and you only pay the vertical premium when a workload genuinely cannot be split.

Burstable instances, and the trap

t family instances are the cheapest way to run something small, and the most common source of "why is it suddenly slow."

They provide a baseline fraction of a vCPU — sometimes as low as 10% — and accrue CPU credits while running below it. Exceed the baseline and you spend credits to burst. Run out of credits and you are hard-limited to the baseline, permanently, until you idle enough to earn more.

This is excellent for genuinely spiky, mostly-idle workloads: a dev box, an internal tool, a personal site. It is a poor fit for anything with sustained load, where you burn through credits in the first hour and then run at 10% of a core wondering what happened.

Two flags worth knowing:

• Unlimited mode (default on newer t types) lets you keep bursting past zero credits — for a surcharge. Convenient, and a way to be surprised by a bill.
• If a t instance sits near 100% CPU constantly, you have outgrown the family. Move to m and the problem disappears.

Pricing models

The usual mistake is buying commitments too early. Run on-demand until you know your steady-state, then commit to the floor — not the peak. A one-year Savings Plan sized to a workload you later delete is money you cannot get back.

Spot is dramatically cheaper and genuinely usable for anything that can be interrupted and retried. It is not usable for a database.

Picking one, in order

1. Family from workload shape. Memory-heavy → r. CPU-heavy → c. Neither, or unsure → m. Mostly idle → t.
2. Newest generation available in your region. Almost always cheaper per unit of work.
3. Graviton if your stack supports it. ARM instances typically run 20–40% cheaper for equivalent performance. Most interpreted languages and mainstream containers work unmodified; native binaries and some older dependencies do not.
4. Start one size below your guess. Scaling up is a stop, change, start. Scaling down after months of overpaying is a thing nobody gets around to.
5. Measure, then commit. On-demand until the shape is known, then a Savings Plan on the baseline.

Why cost attribution matters more than the choice

Choosing well at launch is worth less than knowing what things cost afterwards. An m7g.xlarge running continuously is roughly $100 a month — visible only as a line in an invoice that arrives weeks later, aggregated with everything else.

Korve prices each resource on the canvas from real AWS rates and live uptime, so an instance's cost sits on the node rather than in a monthly bill. The number that changes behaviour is the one you see while deciding, not the one you reconcile at the end of the month.