Welcome to Part II, where we leave theory behind and start using AWS for real. We begin with the most fundamental service: EC2, compute. And within EC2, the first thing you need to master is instances: what they are, what types exist, and which one to choose.

EC2 stands for Elastic Compute Cloud. It’s AWS’s service for renting virtual servers. Each of these servers is called an instance.

Remember Chapter 1: EC2 is the classic example of IaaS (Infrastructure as a Service). AWS gives you a virtual computer; you install and manage the operating system and your software on top.

Analogy: An EC2 instance is like renting a computer by the hour in a remote data center, but without touching any physical hardware. You choose how much power you want, turn it on in 2 minutes, and start using it via SSH (Linux) or Remote Desktop (Windows).

A very powerful physical server can be “sliced” into many independent virtual servers through virtualization. Each slice (each instance) thinks it’s a complete computer, but shares the physical hardware with other instances, isolated from each other.

This is what enables the resource pooling from Chapter 1: AWS has huge physical servers and rents you just the portion you need.

Here’s the part that confuses beginners. AWS offers hundreds of instance types with names like t3.micro, m5.large, c6g.xlarge… They seem like gibberish, but they follow a clear logic.

Each instance is defined by two things:

1. Family: what it’s optimized for (CPU, memory, etc.).
2. Size: how much power it has.

Let’s take m5.large as an example:

• m → family (general purpose).
• 5 → generation (higher number, more modern and efficient hardware).
• large → size (amount of CPU and memory).

Each family is designed for a type of workload. These are the ones you’ll use most:

Tip to remember: think of the letters as English initials. Compute, RAM (memory), GPU… It’s not perfect, but it helps.

Instances in the t family (like t3.micro) are special and very popular for getting started:

• They are cheap and eligible for the AWS free tier (ideal for learning).
• They work with a CPU credits system: they perform at a low constant rate, but can “burst” with more power when needed occasionally.
• Perfect for small websites, blogs, or test environments with irregular traffic.

Warning: they’re not good for workloads that need high, constant CPU, because they run out of credits. For that, better use a c or m family.

Don’t get overwhelmed by the hundreds of types. Follow this reasoning:

1. What does my application need more, CPU or memory?
   • Balanced or not sure → m (or t if it’s small).
   • Lots of CPU → c.
   • Lots of RAM → r.
   • GPU for AI/graphics → g or p.
2. How much power? Start small (large or even micro) and scale up if needed. It’s trivial to change size later.
3. Always use the most recent generation available: it usually gives more performance for the same price.

Golden rule: Start small and measure. It’s much easier (and cheaper) to scale up an instance than to overpay “just in case.” We’ll see how to detect overprovisioning in Chapter 25 (cost optimization).

Real example: A team launches a new website with a t3.micro (almost free). As traffic grows, they see the CPU gets saturated and migrate to an m5.large. When they discover their image processing needs lots of CPU, they move that specific part to a c6.xlarge. Each piece uses the family that fits it best.

• EC2 rents virtual servers called instances (it’s pure IaaS).
• The name of an instance (m5.large) encodes family + generation + size.
• Families are optimized for different jobs: t/m (general), c (CPU), r (memory), i (storage), g/p (GPU).
• The t family is cheap and ideal for learning (free tier), but not for constant CPU.
• Start small, measure, and scale. Changing size later is easy.

In the next subchapter, we’ll look at three pieces that always accompany an instance: AMIs (the disk template), key pairs (how you log in securely), and Security Groups (the firewall).