AWS Architecture Guide

Subnets, Route Tables, and Traffic Flow

Goal

Now that the VPC boundary is clear, the next step is to explain how workloads actually get placed and how their traffic moves.

AWS says a subnet is a range of IP addresses in a VPC and that each subnet must live in one Availability Zone. AWS also notes that each subnet must be associated with a route table, and the route table controls the routing for that subnet. That pairing is the key mental model for this section.

The Short Version

Architects often talk about public subnets, private subnets, and isolated subnets as if those were built-in personalities. They are not.

The better way to think is:

A subnet gives a workload an address neighborhood, but the route table gives that workload its reachable world.

Subnets decide where resources live and which Availability Zone they belong to. Route tables decide whether traffic stays local, goes to an internet gateway, reaches a NAT path, or later heads toward a transit or hybrid connection.

Subnets Are Placement Boundaries

Subnets divide the VPC address space into smaller ranges. Because each subnet lives in a single Availability Zone, subnet design is also an availability design choice. If you want a workload to survive the loss of one Availability Zone, you normally spread equivalent workload tiers across subnets in multiple zones.

Subnets are useful because they help you group resources with similar path and security expectations:

  • public entry points

  • private application services

  • private data stores

  • shared platform components

That said, a subnet is not the path itself. Two subnets with similar names can behave very differently if their routes differ.

Route Tables Are Path Logic

AWS route tables specify a destination and a target. Every subnet is associated with one route table at a time, whether implicitly through the main route table or explicitly through a custom one.

That means traffic behavior is never fully explained by the subnet label alone. The route table answers the real question:

  • Does this subnet have only local VPC reachability?

  • Can it reach the internet through an internet gateway?

  • Does outbound traffic go through a NAT gateway?

  • Will future traffic go to a peering, transit, or hybrid target?

This is why strong network explanations usually walk the traffic path rather than just showing a colored subnet diagram.

A Three-Tier Example

Use this simple pattern:

VPC
  -> Public subnet -> Internet gateway
  -> Private app subnet -> NAT gateway
  -> Private data subnet -> Local VPC routes only

In that model:

  • the public subnet holds only components that need direct public reachability, such as a load balancer

  • the private application subnet can talk out through NAT for approved outbound needs but does not accept direct inbound internet traffic

  • the private data subnet stays on internal paths only

The shape feels familiar, but notice what made it real: not only subnet names, but route choices.

Why Tier Separation Helps

Separating tiers into different subnets gives you cleaner architecture conversations:

  • You can reason about which tier may be public at all.

  • You can attach different route tables where needed.

  • You can place the same tier in multiple Availability Zones.

  • You can make later inspection or egress design more deliberate.

Without that separation, teams often end up with one flat network where public and private concerns mix together. That may work for a small experiment, but it becomes hard to explain and harder to govern.

Common Mistakes

  • Treating every subnet as if it should share the same route table.

  • Calling a subnet private without checking whether its routes still expose a public path.

  • Forgetting that subnets are also an Availability Zone design decision.

  • Using subnet labels as a substitute for actually tracing traffic flow.

If Someone Asks You

How do subnets and route tables work together in AWS?

A good answer is:

Subnets divide VPC address space and place workloads in specific Availability Zones. Route tables then decide where traffic from those subnets goes. So a subnet defines where resources sit, but the route table defines which destinations they can actually reach.

What You Should Remember

A subnet gives a workload an address neighborhood, but the route table gives that workload its reachable world.

Questions to Check Your Understanding

  1. Why can two subnets in the same VPC behave differently even if they hold similar resources?

  2. What makes a subnet effectively public or private in practice?

  3. Why does subnet design also influence availability planning?