Amazon VPC – Designing Networks That Don't Break at 3 AM
A practical, architecture-first tour of how Amazon VPC actually routes, filters, and isolates traffic — and the design decisions that separate a network that scales calmly from one that pages someone every time it grows.
Picture a large office building where every floor is its own sealed room, every door has two separate locks that answer completely differently, and the building manager keeps a written record of literally every person who walks through every doorway. That’s a reasonably close mental model for Amazon VPC — a private, logically isolated section of the AWS cloud where you decide exactly which rooms exist, which doors connect them, and who’s allowed through each one. Most engineers can already launch an EC2 instance into “a VPC” without ever having to reason about how that isolation is actually enforced. This tutorial goes past launching resources and into how VPC routing, security enforcement, and connectivity options actually behave — the kind of detail that matters once you’re designing for multiple accounts, multiple regions, or a security review that asks hard questions.
1Core Concepts Beyond the Basics
Once you know a VPC is “your private network in AWS,” the next layer of understanding is about how addressing and boundaries actually get decided.
A VPC is defined first by its CIDR block — a range of IP addresses you own within that virtual network, expressed in a compact notation like a /16 or /20. Every subnet, every route, and every IP address assigned to a resource has to fit inside that range. Choosing this range is one of the few VPC decisions that’s genuinely hard to undo later, because CIDR ranges that overlap between two VPCs cannot be connected to each other directly — a mistake discovered months into a project, right when a peering connection or Transit Gateway attachment is needed, can force a costly re-addressing exercise.
Choosing a VPC’s CIDR range is like choosing a postal code system for a new town before any houses are built. If two neighboring towns pick postal codes that collide, mail (traffic) between them becomes impossible to route correctly — no amount of clever signage fixes an address that means two different things in two places.
Regions, Availability Zones, and why they matter to network design
A VPC always lives inside a single AWS Region, but it stretches across that region’s Availability Zones. Subnets, on the other hand, are pinned to exactly one Availability Zone each. This single fact — subnets belong to one AZ, VPCs span many — is the seed of almost every high-availability network design pattern used in production, because it forces you to duplicate subnets per AZ if you want workloads to survive a zone failure.
AWS reserves five IP addresses in every subnet for internal use (network address, VPC router, DNS, future use, and broadcast-equivalent). A /28 subnet that looks like it holds 16 addresses actually offers only 11 usable ones — a detail that has surprised more than one capacity plan.
Default VPC versus custom VPC
Every AWS account historically came with a default VPC per region, pre-wired with public subnets and an internet gateway so a new account could launch something immediately. Production environments almost always move to custom VPCs instead, because the default VPC’s “everything is public by default” posture is the opposite of what a real security boundary should look like.
2Architecture and Core Components
A VPC is really an assembly of several independent building blocks — subnets, route tables, gateways, and interfaces — that only become “a network” once wired together correctly.
Subnets
A slice of the VPC’s CIDR range, tied to one Availability Zone, marked as public or private based on what its route table sends toward the internet.
Route Tables
A set of rules deciding where traffic leaving a subnet goes next — to another subnet, a gateway, a peering connection, or nowhere at all.
Internet Gateway (IGW)
A horizontally scaled, highly available VPC component that allows two-way communication between resources with public IPs and the internet.
NAT Gateway
Lets resources in private subnets initiate outbound connections (like downloading a patch) without being directly reachable from the internet.
Elastic Network Interface (ENI)
The actual virtual network card attached to an instance, carrying its private IP, security groups, and MAC address — the true “network identity” of a resource.
Security Groups & NACLs
Two independent filtering layers — one attached to interfaces, one attached to subnets — covered in depth in the Security chapter.
graph TD
IGW[Internet Gateway] --> PubRT[Public Route Table]
PubRT --> PubSubnet[Public Subnet - AZ A]
PubSubnet --> NAT[NAT Gateway]
NAT --> PrivRT[Private Route Table]
PrivRT --> PrivSubnet[Private Subnet - AZ A]
PrivSubnet --> ENI[Elastic Network Interface]
ENI --> Instance[EC2 Instance]
Public subnet is a label, not a property
A subnet is not inherently “public” — AWS doesn’t tag it that way. A subnet is public purely because its route table sends 0.0.0.0/0 traffic to an internet gateway, and its resources hold public IP addresses. Change the route table, and the exact same subnet becomes private. This distinction trips up engineers who go looking for a public/private toggle that doesn’t exist as a checkbox anywhere.
3Internal Working: How Traffic Decisions Actually Get Made
Every packet leaving an instance passes through a strict, ordered sequence of checks before AWS’s network fabric ever moves it anywhere.
The route table lookup: longest prefix match
When a packet leaves a subnet, the VPC router consults that subnet’s route table and finds the most specific matching route — not the first one listed. A route to a narrow CIDR like 10.0.5.0/24 wins over a broader 10.0.0.0/16 route even if the broad route appears first, and a broader route to a peering connection wins over the default 0.0.0.0/0 route to an internet gateway. This “longest prefix match” behavior is exactly how Transit Gateway and peering routes can coexist with a default internet route in the same table without conflict.
Two independent filters, evaluated differently
Traffic passes through a Network ACL at the subnet boundary and a Security Group at the network interface — and these two mechanisms don’t behave the same way at all. Security Groups are stateful: allow an inbound request, and the response is automatically allowed back out, with no matching outbound rule required. Network ACLs are stateless: an allowed inbound packet’s response must be explicitly permitted by an outbound rule as well, or it’s silently dropped.
Because NACLs are stateless, a NACL configured to allow inbound traffic on a port but forgetting the matching outbound ephemeral port range is one of the most common causes of “the security group looks right but it still doesn’t work” tickets.
DNS resolution inside a VPC
When enabled, the VPC’s own DNS resolver (reachable at a fixed address, the VPC’s base address plus two) answers internal hostname queries and forwards external ones. Two separate VPC attributes control this behavior: enableDnsSupport (whether the resolver works at all) and enableDnsHostnames (whether instances actually get DNS hostnames assigned). Both need to be true for private DNS names and many managed-service integrations, like private VPC endpoints, to resolve correctly.
4Data Flow and Packet Lifecycle
Tracing one outbound request from a private-subnet server to an external API shows every checkpoint a packet passes through.
Instance sends the packet
The application on the instance sends a request destined for an external IP address, leaving through its attached ENI.
Security Group check (outbound)
The instance’s security group evaluates the outbound rule set; by default, security groups allow all outbound traffic unless explicitly restricted.
Network ACL check (outbound)
The subnet’s NACL evaluates the packet against its numbered outbound rules, in order, stopping at the first match.
Route table lookup
The subnet’s route table performs a longest-prefix match and forwards the packet toward a NAT gateway, since the destination is external.
NAT translation and exit
The NAT gateway rewrites the source address to its own public IP and forwards the packet through the internet gateway to the destination.
Return traffic retraces the path
Because both the security group and the NAT translation are stateful, the response flows back automatically without needing new inbound rules for the ephemeral response.
Why VPC Flow Logs matter here
VPC Flow Logs capture metadata about accepted and rejected traffic at the ENI, subnet, or VPC level — source, destination, ports, protocol, and whether the packet was accepted or rejected — without capturing packet contents. When a connection mysteriously fails, tracing the flow log entries against this six-step sequence is usually the fastest way to find exactly which checkpoint dropped it.
5Advantages, Disadvantages and Trade-offs
VPC gives you total control over your network topology — and total control comes with total responsibility for getting the topology right.
Advantages
- Complete control over IP addressing, segmentation, and routing.
- Two independent, layered filtering mechanisms (security groups and NACLs) for defense in depth.
- Native, low-latency connectivity options to other VPCs, on-premises networks, and AWS services.
- Flow logs provide detailed, low-overhead network visibility without needing packet capture agents.
- Highly available by design — internet gateways and NAT gateways are managed, redundant AWS services.
Disadvantages / Trade-offs
- CIDR planning mistakes are expensive to fix retroactively, especially across many connected VPCs.
- NAT gateways bill by the hour and by data processed, which adds up quickly for high-throughput outbound traffic.
- Complexity grows fast in multi-account, multi-region topologies without a deliberate connectivity strategy.
- Two separate filtering layers (SG and NACL) can make troubleshooting slower if a team isn’t disciplined about using them consistently.
The trade-off in one sentence
VPC trades the simplicity of a fully managed, opinionated network for the flexibility of designing exactly the topology your security and compliance requirements demand — a trade that pays off enormously at scale, and feels like unnecessary overhead for a single small application.
6Performance and Scalability
Networking scale limits in AWS show up in a few specific, well-documented places — and each has its own scaling strategy.
NAT Gateway throughput
A single NAT gateway supports up to 100 Gbps of burst bandwidth automatically, but the practical scaling concern is usually the number of concurrent connections per unique destination, which is capped per NAT gateway. Workloads with extremely high fan-out to many destinations sometimes need multiple NAT gateways across subnets to spread that connection load.
Elastic Network Interface and IP density limits
Each EC2 instance type has a maximum number of ENIs and IP addresses it can hold, which directly caps how many densely packed containers or pods (in ENI-per-pod networking models) a single instance can support. Choosing instance types for container-heavy workloads often has to account for this ceiling as much as CPU or memory.
Transit Gateway for hub-and-spoke scale
Connecting more than a handful of VPCs through individual peering connections quickly becomes an unmanageable mesh, since peering connections aren’t transitive — VPC A peered to B and B peered to C does not let A reach C. AWS Transit Gateway solves this by acting as a central routing hub that many VPCs and on-premises connections attach to, replacing an exponentially growing mesh with a linear number of attachments.
graph LR
A[VPC A] --- TGW((Transit Gateway))
B[VPC B] --- TGW
C[VPC C] --- TGW
D[On-Premises via VPN/Direct Connect] --- TGW
7High Availability and Reliability
Because subnets are locked to a single Availability Zone, resilience in VPC design is fundamentally a duplication exercise, repeated per zone.
The standard multi-AZ pattern
Production VPC designs create matching public and private subnet pairs in at least two, often three, Availability Zones, each with its own NAT gateway. This avoids a single NAT gateway — and the single AZ it lives in — becoming a hidden single point of failure for every private-subnet workload’s outbound traffic.
A common cost-saving shortcut is running one shared NAT gateway for an entire VPC. It works, but it silently reintroduces a cross-AZ single point of failure and adds inter-AZ data transfer charges — a trade-off worth making deliberately, not by accident.
Internet Gateway resilience is built in
Unlike NAT gateways, an internet gateway is a horizontally scaled, redundant AWS-managed component attached at the VPC level rather than per-subnet — there’s no capacity planning or multi-AZ duplication needed for it specifically, since AWS already engineered it for regional resilience.
Route table failover for hybrid connectivity
For VPN or Direct Connect links to on-premises networks, redundancy comes from provisioning two tunnels or two Direct Connect circuits over physically diverse paths, with routing protocols like BGP automatically preferring the healthy path. A single VPN tunnel, however “always up” it looks in testing, is a design that will eventually cause an outage during real hardware maintenance on the provider side.
8Security
VPC security is a layered system — network placement, two filtering mechanisms, and private connectivity options that avoid the public internet entirely.
| Mechanism | Scope | Behavior |
|---|---|---|
| Security Group | Network interface | Stateful; allow rules only; evaluates all rules together |
| Network ACL | Subnet | Stateless; allow and deny rules; evaluated in numbered order |
| VPC Endpoint | Service access | Private route to an AWS service, bypassing the public internet |
Interface endpoints versus gateway endpoints
VPC endpoints come in two forms. Gateway endpoints (used for S3 and DynamoDB) work by adding a route table entry — no ENI, no additional cost per hour. Interface endpoints (used for most other AWS services) place an actual ENI with a private IP inside your subnet, powered by AWS PrivateLink, letting you reach a service like Amazon SNS or Secrets Manager without any traffic touching the public internet, even indirectly through a NAT gateway.
A gateway endpoint is like adding a private hallway directly from your office to a specific nearby building — cheap and simple, but only built for a couple of specific destinations. An interface endpoint is like installing a dedicated, private phone line to a specific service, appearing as a normal-looking extension inside your own office directory.
Segmentation as a security control
Placing databases and internal services in private subnets with no route to an internet gateway at all is one of the strongest, simplest security controls available — it’s not just about firewall rules, but about removing the reachability entirely, so a misconfigured security group can’t accidentally expose the resource to the internet.
Problem
Using an overly broad security group rule, such as allowing all inbound traffic from 0.0.0.0/0 on a database port, as a quick way to unblock a developer.
Why It’s Harmful
Security groups are frequently the last layer of defense once a resource is in a subnet with internet reachability; a broad rule like this removes that defense entirely and is a leading cause of publicly exposed data stores found in security audits.
Correct Approach
Reference other security groups as the source instead of IP ranges wherever possible, and keep data-tier resources in private subnets with no internet gateway route regardless of security group configuration.
9Monitoring, Logging and Metrics
Network visibility in VPC comes from three complementary tools, each answering a different kind of question.
VPC Flow Logs
Records accepted and rejected traffic at ENI, subnet, or VPC scope — the primary tool for answering “was this connection allowed or blocked, and where?”
Reachability Analyzer
Statically analyzes configuration to predict whether a path between two resources would succeed, without sending any actual traffic.
Traffic Mirroring
Copies actual packet contents from an ENI to a monitoring appliance for deep inspection — used when metadata alone isn’t enough.
CloudWatch (NAT/VPN metrics)
Tracks NAT gateway connection counts and bandwidth, and VPN tunnel state, feeding alarms for capacity or connectivity issues.
Enabling Flow Logs only after an incident, rather than as a standing default. Flow Logs have no meaningful performance impact and are usually the single most useful artifact during a security investigation — treating them as optional tooling delays every future investigation.
10Deployment and Multi-Account Connectivity
Real organizations rarely run one VPC in isolation — deployment decisions here are mostly about how many VPCs talk to each other, and how.
VPC Peering
A direct, non-transitive connection between two VPCs, simple for a handful of relationships but unwieldy past a few VPCs.
Transit Gateway
A central hub that scales to hundreds of VPC and on-premises attachments with centralized route control.
Shared VPC (via AWS RAM)
Lets multiple AWS accounts provision resources into subnets owned by a central network account, centralizing network administration.
IP Address Manager (IPAM)
Centrally plans, tracks, and monitors CIDR allocation across many VPCs and accounts, preventing the overlapping-range problem raised in Chapter 1.
Hybrid connectivity: VPN versus Direct Connect
Site-to-Site VPN establishes an encrypted tunnel over the public internet — quick to set up, variable in latency. AWS Direct Connect provisions a dedicated, private physical network connection into AWS, offering more consistent latency and higher throughput, typically chosen once VPN’s variability becomes a real operational or compliance problem rather than a theoretical one.
11Design Patterns and Anti-patterns
A handful of recurring topology patterns cover the overwhelming majority of production VPC designs.
Pattern: Three-Tier Subnet Layout
Public subnets for load balancers, private application subnets for compute, and isolated data subnets with no NAT route at all for databases — a layering that maps security boundaries directly onto network boundaries.
Pattern: Hub VPC for Shared Services
A dedicated VPC hosting shared resources — a NAT gateway fleet, a DNS resolver, security tooling — that spoke VPCs reach through Transit Gateway, avoiding duplicated infrastructure per application team.
Pattern: Endpoint-First Service Access
Defaulting to VPC endpoints for AWS service access from private subnets instead of routing that traffic out through NAT, reducing both cost and internet exposure simultaneously.
Problem
Building a full mesh of VPC peering connections as an organization’s VPC count grows past four or five.
Why It’s Harmful
Peering connections aren’t transitive, so full connectivity between N VPCs needs roughly N-squared peering connections and route table entries, which becomes operationally unmanageable and error-prone very quickly.
Correct Approach
Move to Transit Gateway once more than a few VPCs need to interconnect, centralizing route management into one place instead of N-squared pairwise configurations.
12Best Practices and Common Mistakes
Most VPC-related incidents come from a small set of overlooked defaults rather than exotic misconfigurations.
Advantages
- Plan CIDR ranges organization-wide before creating VPCs, ideally with IPAM, to avoid future overlap.
- Enable VPC Flow Logs by default on every VPC, not just after something goes wrong.
- Prefer security group references over hardcoded IP ranges for internal traffic rules.
- Use VPC endpoints for AWS service traffic from private subnets wherever the service supports it.
Disadvantages / Trade-offs
- Choosing an overly small CIDR range early, then running out of subnet space as the environment grows.
- Relying on a single NAT gateway for an entire VPC without weighing the availability trade-off explicitly.
- Forgetting matching outbound NACL rules for ephemeral ports, causing intermittent, confusing failures.
- Letting peering connections multiply unmanaged instead of consolidating onto Transit Gateway early.
Reachability Analyzer can check a proposed connectivity path before it’s ever tested with real traffic, which is often faster than launching a test instance just to confirm a security group and route table combination actually works.
13Real-world and Industry Examples
The shape of a company’s VPC design usually mirrors the shape of its organization — and that’s by design, not accident.
Financial Services Multi-Account Landing Zones
Regulated organizations commonly use a hub VPC with Transit Gateway connecting dozens of application-team VPCs, centralizing egress inspection through a shared security VPC that every outbound packet must pass through.
SaaS Platforms with Per-Customer Isolation
Some SaaS providers isolate customer workloads into separate VPCs or subnets specifically so a security boundary maps cleanly to a billing and compliance boundary, simplifying customer-specific audits.
Hybrid Enterprises Migrating Gradually
Enterprises mid-migration from on-premises data centers frequently run Direct Connect alongside Transit Gateway, letting newly migrated workloads reach still-on-premises systems as if they were on the same network.
14Frequently Asked Questions
A subnet is public only because its route table sends 0.0.0.0/0 traffic to an internet gateway and its resources have public IPs — there’s no separate public/private flag stored anywhere else.
Yes for direct pairs, but peering isn’t transitive: VPC A peered with B and B peered with C does not let A reach C. A itself would need its own peering connection to C, or all three would need to attach to a Transit Gateway instead.
NACLs default to allowing all traffic when first created for a default VPC, but a custom NACL defaults to denying everything until rules are added — and NACL rules are evaluated independently of, and in addition to, security group rules.
No. Gateway endpoints (S3, DynamoDB) have no hourly charge; interface endpoints, built on PrivateLink, incur an hourly charge per endpoint plus data processing charges, since they provision an actual network interface.
No — if a private subnet’s workloads only need to reach other AWS services (via endpoints) or other internal subnets, skipping the NAT gateway entirely both saves cost and removes an unnecessary path to the internet.
Once the variability of internet-routed VPN latency becomes a measurable operational problem, or throughput needs consistently exceed what a VPN tunnel comfortably supports, Direct Connect’s dedicated physical connection becomes the more defensible choice.
15Summary and Key Takeaways
Amazon VPC’s real complexity lives in how its independent pieces interact — CIDR ranges that must never overlap where connectivity is needed, subnets locked to single Availability Zones, route tables resolved by longest prefix match, and two differently-behaved filtering layers stacked on top of each other. None of this is arbitrary: each piece exists to give you precise, composable control over isolation and reachability, at the cost of needing to actually understand how they compose. Teams that plan addressing early, default to private placement and endpoint access, and treat Flow Logs as standing infrastructure rather than an incident-response afterthought tend to scale their networks without drama.
Key Takeaways
- CIDR planning is nearly permanent — overlapping ranges block future connectivity between VPCs, so plan organization-wide, ideally with IPAM.
- Subnets are single-AZ — high availability comes from deliberately duplicating subnets, route tables, and NAT gateways across zones.
- Route tables resolve by longest prefix match, letting specific peering or Transit Gateway routes coexist safely with a default internet route.
- Security groups are stateful; NACLs are stateless — forgetting a NACL’s matching outbound rule is a leading cause of confusing connectivity failures.
- Peering isn’t transitive — beyond a few VPCs, Transit Gateway replaces an unmanageable mesh with a single routing hub.
- VPC endpoints keep AWS service traffic off the public internet entirely, improving both security posture and, often, cost.
- Flow Logs, enabled by default, are the fastest path to diagnosing “why can’t these two things talk to each other” during an incident.