You already have subnets and internet gateways. But what's missing is what directs the traffic through your network and what filters it at the subnet level. These are the Route Tables and the Network ACLs. They are the components that make "public" and "private" actually mean something.

A Route Table is a set of rules that decide where traffic goes according to its destination. Each subnet is associated with a route table, which tells it: "if the traffic is going to this place, send it this way."

Analogy: A route table is like the traffic signs and GPS of your property. At each intersection, they indicate: "to go to street X, turn here; to get to the highway (internet), go straight to the main gate."

Each rule (route) says: "traffic to this destination goes through this target." Example of a table for a public subnet:

And a table for a private subnet:

See the difference? What makes a subnet public or private is precisely this table:

• If the route to 0.0.0.0/0 (all internet) points to the Internet Gateway → public subnet.
• If it points to the NAT Gateway (or doesn't exist) → private subnet.

This is the "secret" of subnets: a subnet doesn't have a magic "public" or "private" label. It's public or private depending on where its route table sends it. The rule 0.0.0.0/0 → Internet Gateway is what makes it public.

The local route is always present and cannot be deleted: it ensures that all resources within the same VPC can communicate with each other.

Now for filtering. You already know about Security Groups from Chapter 4 (the firewall for each instance). Network ACLs (NACLs) are another firewall, but at the level of the entire subnet, not individual instances.

Analogy: If the Security Group is the doorman of each building (controls who enters each instance), the Network ACL is the access control for the whole neighborhood (controls what traffic enters and leaves the entire subnet).

Traffic arriving at an instance passes through two controls:

1. First the Network ACL of the subnet (the neighborhood control).
2. Then the Security Group of the instance (the building doorman).

This is a classic comparison worth keeping clear:

Let's clarify the two concepts that cause the most confusion:

• Security Group (stateful): if you allow an inbound connection, the outbound response is automatically allowed. It "remembers" the connection. You don't have to create a rule for the response.
• Network ACL (stateless): remembers nothing. If you allow inbound traffic, you must explicitly allow outbound traffic as well for the response to return. Each direction is configured separately.

That's why NACLs are fussier: a common mistake is to allow inbound but forget to allow the outbound response, and then "nothing works" even though the inbound rule looks correct.

• Security Groups only allow whitelisting (you define what is allowed; the rest is blocked). You can't write a "deny" rule.
• Network ACLs also allow explicit deny rules. This is useful, for example, to block a specific IP that's attacking you, something a Security Group can't do.

For most cases:

Use Security Groups as your main network security tool. They are simpler (stateful) and sufficient for almost everything. Leave Network ACLs with their default configuration (which allows everything) unless you need something specific, like blocking a malicious IP at the subnet level.

NACLs are an additional layer of defense in depth, not your first line. Many teams use them little and rely on Security Groups.

• Route Tables decide where traffic goes according to its destination. The route 0.0.0.0/0 to the Internet Gateway is what makes a subnet public; to the NAT (or absent), it makes it private.
• Network ACLs are a firewall at the subnet level: stateless (you configure inbound and outbound separately) and allow deny rules (useful for blocking IPs).
• Security Groups are the firewall at the instance level: stateful and only "allow" type. They are your main tool.
• Use Security Groups as the base; add Network ACLs only for specific needs (defense in depth).

In the last VPC subchapter, we'll see how to connect your VPC with other networks: VPC Peering (joining VPCs) and endpoints (reaching AWS services privately).