EC2 Instance Types: How to Pick the Right One
Confused by t3.micro, m5.large, and c5.xlarge? Here's a clear, beginner-friendly guide to AWS EC2 instance types and how to pick the right one for your app.
Series: AWS Beginners Guide (4 articles)
- 2EC2 Instance Types: How to Pick the Right One This article
The first time I opened the EC2 instance type dropdown, I genuinely laughed. There were hundreds of options (
t2.micro, m5.large, c5.xlarge, r5.2xlarge, g4dn.xlarge), and absolutely no explanation of what any of it meant unless you already knew.If you've felt that same mild panic staring at the list, this article is for you. By the end, you'll be able to look at any EC2 instance type and know roughly what it's built for, just by reading the name.
Why Instance Types Exist in the First Place
An EC2 instance is a virtual server, and like any computer, it needs a specific amount of CPU, memory, storage, and network capacity. The problem is that different applications need wildly different combinations of those resources.
A small personal blog needs almost nothing. A video transcoding service needs serious CPU power. A Redis cache needs tons of memory but barely any CPU. A machine learning training job needs a GPU. One single "default" server size would be wasteful for some of these and completely inadequate for others.
So AWS doesn't give you one instance. It gives you dozens of pre-configured combinations of CPU, memory, storage, and networking, grouped into families, each tuned for a different kind of workload. Picking the right one isn't about picking the "best" instance, it's about matching the hardware to what your application actually needs.
Decoding the Name: What t3.micro Actually Means
Every EC2 instance type name follows the same pattern, and once you can read it, the entire catalog stops being intimidating.
1
2
3
4
5
t 3 . micro
ā ā ā
ā ā āāā Size (how much of that family's resources you get)
ā āāāāāāāāāā Generation (newer = better price-performance, usually)
āāāāāāāāāāāāāā Family (what the instance is optimized for)Take
m5.large:- m = general purpose family
- 5 = 5th generation hardware
- large = the size tier within that family
Or
c5.xlarge:- c = compute-optimized family
- 5 = 5th generation
- xlarge = a bigger size than
large
Once you know what the letter stands for, you can look at almost any instance type AWS offers and immediately guess what it's good for, even before reading the specs.
The Main Instance Families, Explained Simply
AWS groups instance types into families based on what resource they prioritize. Here are the ones you'll actually run into as a developer, in plain language.
| Family Letter | Category | Optimized For | Real Example Use Case |
|---|---|---|---|
| t | Burstable, General Purpose | Balanced CPU/memory at low cost, with the ability to "burst" above baseline briefly | Personal projects, dev/test environments, low-traffic websites |
| m | General Purpose | Balanced CPU, memory, and networking with consistent performance | Web servers, small-to-mid APIs, small databases |
| c | Compute Optimized | High CPU power relative to memory | Video encoding, batch processing, gaming servers, data analysis |
| r | Memory Optimized | Large amounts of RAM relative to CPU | In-memory caches (Redis), large databases, real-time analytics |
| i | Storage Optimized | Fast, high-throughput local disk (NVMe SSD) | Data warehousing, distributed file systems, search indexing |
| g | GPU / Accelerated Computing | Graphics or ML acceleration hardware | Machine learning training/inference, video rendering, game streaming |
You don't need to memorize all of these today. What matters is recognizing the pattern: the letter tells you the priority, not the absolute power. A
c5.large and an r5.large can cost about the same, but one gives you more CPU and the other gives you more RAM, for the exact same price tier.Understanding "Burstable" Instances (the T Family)
The
t family deserves its own explanation because it behaves differently from every other family, and it's the one you'll use most as a beginner.Burstable instances don't give you full CPU power all the time. Instead, they accumulate "CPU credits" while idle, and spend those credits when your app suddenly needs more processing power. Most small apps spend the vast majority of their time doing very little, so this model is both cheaper and perfectly adequate.
Here's the catch beginners often miss: if your app sustains high CPU usage for a long stretch, you can run out of credits. On
t2 instances, this causes your instance to throttle hard. On t3 and newer burstable types, AWS instead allows "unlimited" bursting by default, billing you a small extra fee if you sustain high usage, rather than throttling you outright.Practical takeaway:
t3.micro or t2.micro is the right starting point for almost any learning project, personal website, or small side project. It's also the instance type covered by the AWS Free Tier, which makes it the obvious default while you're learning.How to Actually Choose: A Simple Decision Process
Instead of memorizing every family, ask yourself these four questions in order.
1. Is this just for learning, testing, or a small personal project? Use
t3.micro or t2.micro. Free Tier eligible, more than enough power, and you can always resize later.2. Does my app do a lot of heavy calculation, like video processing, image conversion, data crunching, or running simulations? Look at the c family (compute optimized). You're paying for CPU power, not memory you won't use.
3. Does my app need to hold a lot of data in memory, like a cache layer, an in-memory database, or real-time analytics on large datasets? Look at the r family (memory optimized). Memory is your bottleneck, so that's what you pay for.
4. Is this a standard web app or API with normal, balanced traffic, not especially CPU-heavy and not especially memory-heavy? Look at the m family (general purpose). It's the safe, balanced middle ground for production workloads once you've outgrown a
t3.If none of these clearly apply, or you're genuinely unsure, start with a general-purpose or burstable instance, monitor it with CloudWatch, and resize once you actually see where the bottleneck is. Guessing upfront is far less reliable than measuring real usage.
šø [Screenshot: The EC2 "Instance type" dropdown in the Launch Instance wizard, showing a few different families like t3, m5, and c5 for comparison]
Reading an Instance Size: micro, small, large, xlarge
Within each family, the size suffix tells you how much of that family's resource profile you get. Sizes generally double as you go up:
| Size | Relative Scale |
|---|---|
| nano / micro | Smallest, a fraction of a CPU core, 0.5 to 1 GB RAM |
| small / medium | A bit more headroom, still lightweight |
| large | A full baseline tier, 2 vCPUs, several GB RAM, typical starting point for real workloads |
| xlarge, 2xlarge, 4xlarge... | Each step roughly doubles CPU and memory over the previous size |
So
m5.xlarge isn't a different type of server than m5.large, it's the same balanced profile, just a bigger version of it. This is what makes EC2 genuinely elastic: if your t3.micro starts struggling, you don't rebuild anything, you just stop the instance, change its instance type to something larger, and start it again.šø [Screenshot: The "Change instance type" dialog on the EC2 console, showing a dropdown to resize an existing instance]
A Quick Comparison Table for Common Beginner Scenarios
| Your Project | Recommended Instance Type | Why |
|---|---|---|
| Personal blog or portfolio site | t3.micro | Free Tier eligible, low constant traffic |
| Small Node.js / Express API for a class project | t3.micro or t3.small | Bursty traffic pattern, light workload |
| Side project getting real traffic | t3.medium or m5.large | More consistent performance under load |
| Image/video processing service | c5.large | CPU-heavy, short bursts of intense work |
| Redis cache or in-memory session store | r5.large | Memory is the bottleneck, not CPU |
| Machine learning model training | g4dn.xlarge | GPU acceleration needed |
| Self-hosted database for a growing app | m5.large or r5.large | Depends on whether reads or writes dominate |
Common Mistakes Beginners Make Choosing Instance Types
Over-provisioning out of caution. Picking an
m5.xlarge "just to be safe" for a project that will see ten visitors a day wastes money for no benefit. Start small. Resizing later takes seconds.Not knowing about CPU credit exhaustion. If you're running something unusually CPU-intensive on a
t2.micro and it suddenly feels sluggish, check your CPU credit balance in CloudWatch before assuming something else is wrong.Ignoring the Free Tier limits. The AWS Free Tier specifically covers
t2.micro or t3.micro (depending on your region), 750 hours per month, for your first 12 months. Launching a t3.small instead, thinking it's "basically the same," will quietly start costing you money.Choosing based on price alone, not workload fit. A cheaper instance that's the wrong type for your workload can end up costing more in wasted time, poor performance, or needing to migrate later than paying slightly more for the right fit from the start.
Forgetting that instance type can be changed. A lot of beginners agonize over this decision as if it's permanent. It isn't. Stop the instance, change the type, start it again. It takes under a minute.
šø [Screenshot: The AWS CloudWatch dashboard showing a CPU credit balance graph for a t2/t3 instance]
Where to Go From Here
Once you're comfortable picking an instance type, the natural next steps are learning how to monitor your instance's actual CPU and memory usage with CloudWatch, so your choice is based on real data rather than guesswork, and understanding Auto Scaling, which lets AWS automatically add or remove instances based on demand instead of you manually resizing one server.
For now, the honest beginner advice is simple: start with
t3.micro, build your project, watch how it performs, and resize only once you have a real reason to. Almost nobody needs anything bigger than that on day one, and the few extra dollars saved by not over-provisioning add up fast when you're a student working with a limited budget.Not sure which instance type fits your specific project? Drop a comment with what you're building. Happy to help you think it through.
Series: AWS Beginners Guide (4 articles)
- 2EC2 Instance Types: How to Pick the Right One This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article