EC2 Instance Types Explained: Families, Sizes, and How to Choose the Right One

EC2 instance types in one simple explanation

When you launch an EC2 instance, you are renting a virtual machine. The instance type is the specification sheet for that machine: it controls how fast the CPU is, how much RAM you get, what storage is attached, and how much network bandwidth is available.

AWS groups instance types into families based on what they are optimised for, and within each family there are sizes that let you scale up or down while keeping the same resource ratio.

Simple rule of thumb:

• You are running a web server or API: start with T or M family.
• Your app spends most of its time in computation (encoding, compiling, math): try C family.
• Your app loads a large dataset into memory (Redis, in-memory DB, Spark): try R family.
• You need fast local disk I/O (NoSQL, OLTP): try I family.
• You are training or running ML models: try G or P family.
• You are unsure: start with t3.medium or m7i.large, monitor for a week, and resize.

How to read an EC2 instance type name

Every EC2 instance type follows the same naming pattern:

[family][generation][processor/options].[size]

Three examples decoded:

• t4g.medium: T family (burstable), 4th generation, Graviton (ARM), medium size
• m7i.xlarge: M family (general purpose), 7th generation, Intel, xlarge size
• c6g.2xlarge: C family (compute optimised), 6th generation, Graviton, 2xlarge size

Processor/options suffixes

Sizes

Each step up in size roughly doubles both vCPUs and RAM. The table below uses m7i as an example. Actual numbers vary slightly by family and generation.

Some families also offer bare metal sizes (.metal), which give you direct access to the physical host with no hypervisor. This is mainly used for workloads that need hardware virtualisation themselves, or that require specific licensing tied to physical cores.

Instance families at a glance

How to choose the right EC2 instance type

Use this table to map your workload to a starting family. After launch, watch the metrics listed and resize within a week if needed.

Worked example 1: small Django or Node.js app

You are deploying a Django API with a PostgreSQL database. Estimated traffic: a few hundred requests per minute at peak. Start with a t4g.medium (2 vCPU, 4 GB RAM, Graviton) at around $0.027/hour. Install the CloudWatch agent and watch CPU credits and memory for a week. If credits stay healthy and memory stays below 3 GB, you are fine. If CPU credits deplete under normal load, move to m7g.medium for consistent performance.

Worked example 2: Redis cache

You are running Redis as a session cache. Your dataset is 10 GB. An M-family instance with 8 GB RAM will constantly page and cause latency spikes. Start with r7i.large (2 vCPU, 16 GB RAM). It gives Redis room to operate with a safe memory buffer. Watch memory utilisation. If you grow to a 12 GB dataset, move to r7i.xlarge (4 vCPU, 32 GB RAM). If you are running Redis in production long-term, also consider Amazon ElastiCache, which handles upgrades and failover for you.

Worked example 3: CI/CD build runners

Build jobs are CPU-intensive but run for 5 to 15 minutes and are safe to retry. Use c7g.xlarge (4 vCPU, 8 GB RAM) or c6i.xlarge spot instances. Enable Auto Scaling Groups to spin up runners when the queue grows and terminate them when it drains. At spot pricing this can cut your CI costs by 60 to 80% compared to always-on on-demand instances.

Graviton vs Intel vs AMD

AWS Graviton is the company’s own ARM64 processor. It appears as the g suffix in instance names: t4g, m7g, c7g, r6g. Here is how to think about the choice:

EBS vs instance store

This distinction matters when choosing between instance families. Think of it like the difference between a hard drive and a whiteboard:

• EBS is the hard drive. Durable, persistent, and survives the instance being stopped or replaced. It is the right place for your actual data.
• Instance store is the whiteboard. Fast and convenient to write on, but wiped clean the moment the instance stops. Never your only copy of anything important.

When instance store is useful: temp directories, shuffle space for sort-heavy queries, write-ahead log staging, or any data you can reconstruct. Its speed advantage is real for these cases.

When instance store is dangerous: any data you cannot afford to lose. A stopped instance, a host failure, or a spot interruption wipes it permanently. Always replicate data from instance store to EBS or S3 if it matters.

When to use this page

A few situations where this page is most relevant:

• You are launching your first EC2 instance and do not know what to pick. Use the decision table above, start with T or M family, and monitor.
• You are seeing performance problems: slow responses, OOM errors, CPU throttling. Check CloudWatch metrics and compare against the family characteristics.
• You are resizing after monitoring and need to understand whether to move up a size or switch families entirely. If CPU is the bottleneck, size up within the same family or move to C. If memory is the bottleneck, move to R.
• You are comparing EC2 against Lambda or containers and want to understand what EC2 is uniquely good at. See the section below.
• You are reviewing an existing setup for cost optimisation. Overprovisioned instances are common. Check Rightsizing EC2 Instances for a structured approach.

If you are genuinely unsure and need to pick something right now: start with t4g.medium if your workload is light and variable, or m7i.large if it is steady. Both are solid, current-generation defaults. You can always change it later. Stopping and restarting takes about two minutes.

EC2 vs other AWS compute options

EC2 is not always the right tool. Here is a quick orientation:

EC2 gives you the most control and the widest range of configurations. That is its strength and its complexity. If your workload fits a managed service like Lambda or App Runner, those services are often simpler to operate. See Choosing Between EC2, Lambda, and Containers for a more detailed breakdown.