AWS Networking Concepts: VPC, Subnets, and Physical World Mapping
VPC vs Subnet — what each layer is for
VPC — the network boundary
A VPC is a private, isolated virtual network inside AWS, scoped to a single region with a CIDR block (e.g. 10.100.0.0/16).
What problems it solves:
- Isolation between tenants/environments — two VPCs cannot talk by default, even in the same account
- Routing control at the network edge — internet gateways, NAT gateways, VPC peering, PrivateLink, VPN/Direct Connect are all configured here
- IP address space — the VPC CIDR is the pool of IPs available to everything inside it
At Stripe, a cluster (e.g. pdx.stripe.io) typically maps 1:1 to a VPC.
Subnet — the placement and policy unit
A subnet is a slice of a VPC’s CIDR, pinned to a single Availability Zone (e.g. 10.100.4.0/22 in us-west-2a). Every EC2 instance lives in exactly one subnet.
What problems it solves:
- AZ placement — subnet selection = AZ selection for the instance
- Route table assignment — each subnet gets one route table, controlling where its traffic flows
- NACLs — stateless firewall rules applied at the subnet boundary, before security groups
- VPC endpoint policies — can restrict which subnets can reach which S3 buckets
- Organizational grouping —
mongo,private,mspsubnets give operators a handle for “apply this policy to all instances of this tier”
One-line split
VPC = who can talk to whom at the network boundary. Subnet = where within the VPC an instance lands, and what fine-grained traffic rules apply to it.
Key insight: subnets within a VPC are on a flat L3 fabric
Unlike physical networking, subnets within the same VPC do not need a router between them. All subnets in a VPC can reach each other directly via the implicit local route:
10.100.0.0/16 → local
“local” means AWS’s underlying SDN fabric handles delivery between any two instances in the VPC, regardless of subnet or AZ. You don’t configure or manage this.
The route table only governs traffic leaving the VPC:
- To the internet → IGW or NAT gateway
- To another VPC → peering or Transit Gateway
- To AWS services (S3, DynamoDB) → VPC endpoint
- To on-prem → VPN/Direct Connect
For intra-VPC traffic (subnet A → subnet B), the route table is irrelevant. NACLs and security groups are the only controls.
Subnets are policy zones, not routing segments. The subnet boundary is still a real enforcement point for NACLs — a packet crossing from subnet A to subnet B passes through two NACL checks (egress on A, ingress on B) — but there is no routing hop.
Building analogy
- Same VPC = same building. You can walk between any rooms freely.
- Subnet boundary = a doorway with a security guard (NACL). Checks you going out of one room and into the next.
- Security group = a bouncer at each person’s desk — checks every individual connection.
- Route table = only matters when you want to leave the building.
Physical world mapping
| AWS VPC concept | Physical equivalent |
|---|---|
| VPC | An L3 switch with all subnets as directly-connected interfaces |
| Subnet | A VLAN / L3 interface (SVI) on that switch |
| Implicit local routing | Directly-connected routes — no config needed |
| Route table (IGW/NAT) | Default gateway / static routes pointing upstream |
| NACL | ACL applied inbound+outbound on the L3 switch interface |
| Security group | Host-based stateful firewall (iptables) on each machine |
| VPC endpoint policy | Transparent proxy with policy enforcement |
The fundamental difference: in AWS, all inter-subnet forwarding is handled by the SDN fabric invisibly. In a physical network, that “L3 switch” is a real device you own, configure, and can break.
L2 Switch vs L3 Switch vs Router
L2 Switch
- Operates at Layer 2 only — knows MAC addresses, not IP
- Forwards frames by looking up destination MAC in its MAC table
- All connected devices are in the same broadcast domain (same subnet)
- Cannot forward traffic between two different subnets
- Fast, cheap, simple
Router
- Operates at Layer 3 — knows IP addresses
- Each interface is in a different subnet — sits between subnets
- Can do NAT, run routing protocols (BGP, OSPF), terminate VPNs
- Traditionally slower (software-based routing decisions)
- Low port density — designed for connecting networks, not hosts
L3 Switch
- A switch that can also route — hardware-accelerated L3 forwarding in the ASIC
- Has SVIs (Switched Virtual Interfaces) — one virtual L3 interface per VLAN/subnet
- Routes between subnets at wire speed, like an L2 switch does within a subnet
- High port density — designed for intra-datacenter use
- Supports ACLs on interfaces (like a router)
| L2 Switch | Router | L3 Switch | |
|---|---|---|---|
| Forwards by | MAC address | IP address | Both |
| Between subnets | No | Yes | Yes |
| Speed | Wire speed | Slower (historically) | Wire speed |
| Port density | High | Low | High |
| Typical use | Hosts within a subnet | Network edges, WAN, internet | Subnets within a datacenter |
What routers can do that L3 switches typically cannot
- WAN interfaces — serial, DSL, 4G/LTE, fiber handoffs to ISPs; L3 switches only have ethernet
- Internet-scale BGP — full internet routing table (700k+ routes); L3 switch TCAM is fast but small (16k–64k routes)
- VPN termination at scale — IPsec, MPLS, GRE; L3 switches can do some but it’s not their strength
- Complex NAT — L3 switches can do basic NAT but it’s often limited or software-only
One-line mental model
A router is optimized for connecting different networks together (WAN, internet, VPN). An L3 switch is optimized for fast routing between many subnets within the same datacenter.
The boundary is blurring — high-end L3 switches (Cisco Nexus, Arista) now support BGP at scale — but the distinction holds for typical use cases.