A VPC is your fenced plot, but inside you need to organize it into zones. These zones are called subnets, and the most important decision is which will be public (accessible from the internet) and which will be private (hidden and protected). This is the heart of secure network design in AWS.

A subnet is a division of the VPC with its own address range (a slice of the VPC's CIDR). Each subnet lives in a specific availability zone (AZ).

Analogy: If the VPC is your fenced plot, the subnets are the different streets or zones within it. One zone faces the main entrance (public); another is inside, with no direct access from outside (private).

For example, if your VPC is 10.0.0.0/16, you could divide it like this:

Each /24 gives about 250 addresses. Notice there are subnets in two different AZs: that's for high availability, as we saw in Chapter 3.

Here's the central concept. The difference is not in the subnet itself, but in whether or not it has a route to the internet:

Practical definition: a subnet is public if it has a route to an Internet Gateway (the door to the internet, subchapter 6.3). If it doesn't, it's private. That route is what makes it public or not. We'll see this in detail in subchapter 6.4 (route tables).

This is the design decision that defines the security of your architecture:

Resources that need to be accessible from the internet:

• Web servers that users visit.
• Load balancers (Chapter 13) that receive traffic.
• NAT Gateways (subchapter 6.3).

Sensitive resources that should not be exposed:

• Databases (never expose a database to the internet!).
• Application servers with internal business logic.
• Internal systems, queues, background processes.

Real example — typical web architecture:

Internet
   │
   ▼
[Public subnet]  ← Load balancer + web server
   │ (communicates internally)
   ▼
[Private subnet]  ← Application server + Database

Users only reach the public subnet. The database, in the private subnet, is invisible from the internet: only the application server (inside the VPC) can talk to it. Even if an attacker compromised something, the database still has no entry point from outside.

Put in public subnets only what STRICTLY needs access from the internet. Everything else, in private subnets.

This applies the principle of defense in depth: the fewer things you expose, the smaller the attack surface. A database in a private subnet is much more secure than one accessible from the internet, even if both have a password.

Remember subchapter 3.2: for high availability, create subnets in at least two AZs. That way, if one AZ fails, your application keeps running from the other.

That's why the usual "minimum decent" design has four subnets: one public and one private in each of two AZs.

A good question that always comes up: if the database or a server is in a private subnet (with no internet access), how do they download software updates, for example?

The answer is the NAT Gateway, which allows private resources to go out to the internet (to download things) without allowing the internet to come in to them. It's a one-way street outward. We'll see this in detail in the next subchapter.

• A subnet is a division of the VPC, located in one AZ, with its own IP range.
• Public = has a route to the internet (for what needs to be accessible). Private = no direct route to the internet (for sensitive things).
• Golden rule: expose only what's strictly necessary in public subnets; put databases and internal systems in private subnets.
• Spread subnets across multiple AZs for high availability (typical design: public + private in 2 AZs).
• Private resources can go out to the internet securely via a NAT Gateway (next subchapter).

In the next subchapter we'll see the two "doors" of your network: the Internet Gateway (public in/out) and the NAT Gateway (secure outbound for private resources).