VPC, Subnets, Routing, and IP Planning
What This Chapter Is About
Teach AWS networking as intentional connectivity, isolation, routing, and address planning rather than as a flat list of VPC features.
Keep one durable idea in view:
Good AWS network design starts by deciding boundaries and traffic paths before deciding which resources live in each subnet.
Sections
How the Chapter Develops
The chapter develops in this order:
Start with the VPC as a boundary for connectivity, address space, and ownership.
Explain how subnets and route tables create actual traffic paths inside that boundary.
Show how internet gateways and NAT gateways decide which paths are public, private, or outbound only.
Extend the design into IP planning, overlapping ranges, and when one VPC should become several.
Apply the model to a three-tier application with public entry, private services, and controlled egress.
Together, these sections show that AWS networking is about path design and boundary placement, not memorizing isolated features.
What You Will Be Able to Do
By the end of this chapter, the reader should be able to:
Explain what problem a VPC solves in AWS architecture.
Describe how subnets and route tables shape connectivity and isolation.
Distinguish public, private, and isolated subnet patterns in practical terms.
Plan IP ranges with growth, overlap risk, and future connectivity in mind.
Walk through a VPC design for a multi-tier workload and explain the trade-offs.
Key Ideas
A VPC is an address and routing boundary, not just a container for resources.
Subnet placement matters only when the routing intent is clear.
Public or private is a path outcome, not only a subnet label.
NAT gateways solve outbound internet access, not general private connectivity.
Early IP planning prevents painful overlap and migration constraints later.