VPC & Cloud Networking Fundamentals
Your own private, isolated network inside AWS — subnets, route tables, internet/NAT gateways, and how they combine to control what can reach what.
Want a visual for this topic?
Generate a diagram tailored to VPC & Cloud Networking Fundamentals — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain what a VPC is and why every AWS account isolates resources inside one
- •Design a public/private subnet layout for a typical 3-tier application
- •Explain the role of route tables, Internet Gateways, and NAT Gateways
- •Explain VPC Peering and when Transit Gateway is needed instead
What is it?
A VPC (Virtual Private Cloud) is your own logically isolated slice of the AWS network — a private IP address range you define, inside which you create subnets, route tables, and gateways, and launch resources like EC2 instances and RDS databases. Nothing inside your VPC is reachable from another customer's VPC or the internet unless you explicitly configure a path for it.
Why it exists
Multiple AWS customers share the same physical data centers and network hardware. Without strong isolation, one customer's traffic could see or interfere with another's. The VPC exists to give every customer the experience of having their own private data center network — full control over IP ranges, routing, and connectivity — while AWS handles the physical isolation underneath using software-defined networking.
Problem it solves
It solves the multi-tenancy isolation problem (your resources are invisible to other AWS customers by default), the network segmentation problem (you decide which subnets can reach the internet and which can't), and the hybrid connectivity problem (a VPC can be connected to your on-premises data center, giving you one consistent network across both).
Intuition
Think of a VPC as leasing an entire floor of an office building that you get to wire up yourself: you decide where the walls (subnets) go, which rooms have a door to the street (public subnets with internet access) and which don't (private subnets), and you install your own security desk (route tables and security groups) controlling who can walk from one room to another.
Analogy
A gated community with its own private street layout: the community has one address range (the VPC's CIDR block), individual streets are subnets, and a single guarded gate (Internet Gateway) is the only way in or out to the public road — every house's mail (traffic) is routed according to street signs (route tables) that only the community itself controls.
Technical explanation
Each subnet lives entirely within one Availability Zone and is assigned a CIDR block that's a subset of the VPC's overall range. A route table (one default per VPC, plus any custom ones you associate with specific subnets) is a list of rules mapping destination CIDR ranges to a target — 'local' for traffic within the VPC (added automatically), an Internet Gateway ID for a public subnet's 0.0.0.0/0 route, or a NAT Gateway ID for a private subnet that still needs outbound-only internet access. Security Groups (stateful, instance-level) and Network ACLs (stateless, subnet-level) provide two layers of traffic filtering on top of this routing layer.
Architecture
A standard production VPC spans at least 2-3 Availability Zones for redundancy, with one public and one private subnet pair per AZ: public subnets host load balancers and NAT Gateways; private subnets host application servers and databases, with no direct route to the internet. VPC Peering connects two VPCs directly for point-to-point traffic (e.g. a shared-services VPC talking to an application VPC), while Transit Gateway acts as a central hub connecting many VPCs and on-premises networks without needing a full mesh of individual peering connections.
Workflow
- Choose a VPC CIDR block sized for your expected growth (e.g. 10.0.0.0/16 gives 65,536 IPs) — this cannot be easily changed later without adding secondary ranges. 2) Create subnets across multiple AZs, splitting into public and private tiers. 3) Attach an Internet Gateway to the VPC and add a 0.0.0.0/0 route to it in the public subnets' route table. 4) Launch a NAT Gateway in a public subnet, and route the private subnets' 0.0.0.0/0 traffic through it. 5) Launch resources into the appropriate subnet based on whether they need direct internet exposure.
Example
A SaaS company's production VPC (10.0.0.0/16) spans 3 AZs. Each AZ has a public subnet (hosting one AZ's slice of an Application Load Balancer and a NAT Gateway) and a private subnet (hosting EC2 application instances and an RDS Multi-AZ database). The ALB is the only thing directly reachable from the internet; application instances reach out to third-party APIs through the NAT Gateway but can never be reached from the internet directly; the database has no route to the internet at all, only reachable from the application tier's security group.
Real-world usage
AWS's own quick-start reference architectures and virtually every AWS Solutions Architect certification scenario use this exact public/private multi-AZ VPC pattern as the baseline; companies handling regulated data (finance, healthcare) additionally use VPC endpoints (covered under hybrid connectivity) to keep traffic to AWS services like S3 off the public internet entirely, even though it originates from a private subnet.
Trade-offs
Public subnets are simpler (resources have direct internet routes) but expose more attack surface; private subnets with a NAT Gateway are more secure but add cost and a routing hop for outbound traffic. VPC Peering is simple and cheap for a handful of VPCs needing direct connectivity, but doesn't scale well past a few connections due to no transitive routing; Transit Gateway scales cleanly to dozens of VPCs and on-premises connections through one hub, at higher baseline cost and complexity than peering.
Visual explanation
Picture a large rectangle labeled with a CIDR block like 10.0.0.0/16 — this is the VPC. Inside it, smaller rectangles labeled 10.0.1.0/24, 10.0.2.0/24, etc. are subnets, each pinned to one Availability Zone. An Internet Gateway sits attached to the VPC as a whole; a route table per subnet decides whether traffic bound for the internet (0.0.0.0/0) goes to that gateway (making it 'public') or has no such route at all (making it 'private').
Advantages
- —
Full control over IP addressing, subnetting, and routing — mirrors the flexibility of an on-premises network
- —
Strong default isolation from every other AWS customer, with explicit opt-in required for any connectivity
- —
Layered security (route tables, NACLs, security groups) lets you enforce network segmentation at multiple levels
- —
VPC Peering and Transit Gateway let you connect multiple VPCs and on-premises networks as your architecture grows
Disadvantages
- —
Subnet CIDR sizing mistakes are painful to fix later — an undersized subnet can run out of IP addresses as you scale
- —
NAT Gateways have an hourly cost plus per-GB data processing charges, which surprises teams who assume 'private subnet' is free
- —
VPC Peering doesn't support transitive routing (A peered to B peered to C doesn't let A reach C), which becomes a real architectural constraint at more than a few VPCs — Transit Gateway solves this but adds its own cost and complexity
- —
Getting routing wrong (missing route, wrong target) causes traffic to silently fail rather than error clearly, making initial setup debugging non-obvious
Common mistakes
- —
Choosing a VPC CIDR block that's too small (e.g. /24 instead of /16) and running out of IP address space once the application scales or adds more subnets
- —
Putting a database directly in a public subnet 'to make it easier to connect to' during development and never moving it before production
- —
Forgetting that NAT Gateways cost money per hour AND per GB processed, leading to surprise bills on high-outbound-traffic private subnets
- —
Assuming VPC Peering supports transitive routing and being confused when VPC A can't reach VPC C through B
- —
Overlapping CIDR blocks across VPCs that later need to be peered or connected via Transit Gateway — this makes routing between them impossible without re-addressing
In the AWS Console
- 1
AWS Console → VPC → Your VPCs → Create VPC
Choose 'VPC and more' to have AWS auto-generate public/private subnets across multiple AZs, an Internet Gateway, and route tables in one step, or 'VPC only' to build each piece manually.
'VPC and more' is the fastest way to get a correct multi-AZ baseline layout without manually wiring every route table.
- 2
VPC → Subnets
Review the generated public and private subnets, confirming each has a distinct CIDR block and is pinned to a different Availability Zone.
A subnet cannot span multiple AZs — if you need multi-AZ coverage, you need one subnet per AZ, not one subnet trying to cover all of them.
- 3
VPC → Route Tables → select the private route table → Routes tab
Confirm there's a 0.0.0.0/0 route pointing to a NAT Gateway (not an Internet Gateway) for private subnets that need outbound internet access.
A private subnet with NO 0.0.0.0/0 route at all has zero internet access, inbound or outbound — verify this is intentional before assuming something else is broken.
- 4
VPC → Peering connections → Create peering connection
Select the requester VPC and the accepter VPC (same or different account/Region), then accept the request from the accepter side and add routes in both VPCs' route tables pointing to each other's CIDR via the peering connection.
Peering alone doesn't create connectivity — you must also add the routes on both sides, a step that's easy to forget.
🎤 Interview questions
What's the difference between a public and a private subnet, technically? (Listen for: it's determined by the route table — a public subnet has a route to an Internet Gateway; a private subnet does not, though it may route outbound-only traffic through a NAT Gateway.)
Why can't VPC A reach VPC C through VPC B using only VPC Peering? (Listen for: VPC Peering doesn't support transitive routing; each peering connection is point-to-point; Transit Gateway is needed for hub-and-spoke connectivity across many VPCs.)
How would you design a VPC for a 3-tier web application requiring high availability? (Listen for: multi-AZ, public subnets for load balancer/NAT Gateway, private subnets for app and database tiers, security groups scoped tier-to-tier.)
What happens if you don't add a NAT Gateway to a private subnet that needs to download OS updates? (Listen for: outbound internet requests fail — there's no route out; the fix is a NAT Gateway (or NAT instance) in a public subnet with a route from the private subnet's table.)
Why is choosing the right VPC CIDR block size important upfront? (Listen for: resizing later is disruptive — an undersized range runs out of IPs as subnets and resources grow; oversizing has no real downside beyond documentation clarity.)
📂 Subtopics
Subnets and Route Tables in Depth
How a route table's target field is the single source of truth for whether a subnet is public or private.
~14 min
VPC Peering vs Transit Gateway
Two ways to connect multiple VPCs — direct point-to-point versus a central routing hub.
~10 min
Elastic IPs & Network ACLs
A static public IP you control, and a stateless, subnet-wide firewall layered underneath Security Groups.
~15 min