A VPC has no dedicated physical switches or routers assigned to it — it is a logically isolated network implemented through a mapping service running below the hypervisor on every host, and that single fact explains nearly every advanced VPC behavior.

Every EC2 instance’s network interface is, underneath the abstraction, an Elastic Network Interface (ENI) whose packets are intercepted at the hypervisor layer before they ever touch a physical NIC. AWS’s mapping service — the software layer that implements VPC — decides, per packet, based on the VPC’s route tables, security groups, and NACLs, whether that packet is delivered, dropped, or forwarded elsewhere, entirely in software, on shared physical infrastructure that many customers’ VPCs traverse simultaneously without ever seeing each other’s traffic.

This software-defined nature is precisely why VPC features that sound like they should require physical hardware — a new subnet, a new route, a security group covering millions of instances — can be created or modified in seconds: there is no physical provisioning step, only an update to the mapping service’s routing and policy state, propagated across the relevant hosts.

A single packet leaving an EC2 instance passes through a strict, ordered sequence of enforcement points before it reaches its destination, and knowing that exact order is the fastest path to root-causing a connectivity problem.

flowchart TD
    A["Packet leaves instance via ENI"] --> B["Security Group evaluated (stateful, instance-level)"]
    B --> C["Subnet outbound NACL evaluated (stateless, subnet-level)"]
    C --> D["Route Table lookup: most specific match wins"]
    D --> E{"Destination"}
    E -- Same VPC --> F["Local route: delivered directly via mapping service"]
    E -- Internet --> G["Internet Gateway / NAT Gateway"]
    E -- Peered VPC / On-Prem --> H["Peering connection / Transit Gateway / VGW"]
    F --> I["Destination subnet inbound NACL evaluated"]
    G --> I
    H --> I
    I --> J["Destination Security Group evaluated"]
    J --> K["Packet delivered to destination ENI"]
    

The order matters enormously for troubleshooting: a security group is evaluated first on egress and last on ingress, is stateful (a response to an allowed outbound request is automatically permitted back in, with no separate inbound rule needed), and operates at the instance level. A NACL, by contrast, is evaluated at the subnet boundary, is stateless (return traffic must be explicitly allowed by a separate rule, since the NACL has no memory of the original request), and evaluates numbered rules in order, stopping at the first match — a fundamentally different mental model from a security group’s “allow list, no ordering” approach.

Route table lookup follows longest-prefix-match logic identical to traditional networking: the most specific matching route wins, which is why a deliberately narrow route to a specific peered VPC’s CIDR takes precedence over a broader default route to a NAT Gateway, even though both technically match the destination.

“Public” and “private” subnet are not AWS-defined properties of a subnet at all — they are purely a consequence of what that subnet’s route table happens to point at, and understanding that removes a great deal of confusion for advanced network design.

A subnet is “public” purely because its route table contains a route to an Internet Gateway (IGW) for 0.0.0.0/0 — nothing else distinguishes it. A subnet is “private” simply because its default route instead points to a NAT Gateway (for outbound-only internet access) or has no internet-bound route at all. Because this distinction lives entirely in the route table, an engineer can change a subnet’s public/private status instantly by editing a single route, with no other configuration implying or enforcing that designation — which is exactly the kind of change that can go unnoticed in a large route table and quietly expose resources that were assumed private.

NAT Gateways deserve particular advanced attention: they are AWS-managed, highly available within a single AZ, but not inherently multi-AZ — a NAT Gateway deployed in one AZ becomes a single point of failure for every private subnet routing through it if that AZ experiences an outage, which is why production multi-AZ architectures deploy one NAT Gateway per AZ, each serving only the private subnets in its own AZ, rather than a single shared NAT Gateway serving subnets across multiple AZs.

As organizations grow beyond a single VPC, three distinct connectivity mechanisms — each with a genuinely different scaling and isolation model — compete for the same architectural role, and choosing the wrong one is one of the most consequential mistakes in enterprise AWS networking.

VPC Peering creates a direct, non-transitive connection between exactly two VPCs — non-transitive meaning a peered connection to VPC B does not grant VPC A any reachability to whatever VPC B is itself peered with. This non-transitivity is the mechanism’s defining limitation: connecting N VPCs with full mesh peering requires roughly N(N-1)/2 individual peering connections, a combinatorial growth that becomes operationally unmanageable well before an organization reaches even a few dozen VPCs.

Transit Gateway solves exactly this scaling problem by acting as a central, regional routing hub — every attached VPC (and Site-to-Site VPN, and Direct Connect connection) peers only with the Transit Gateway itself, and the Transit Gateway’s own route tables control which attachments can reach which others, turning what would be a combinatorial peering mesh into a linear number of attachments with centrally governed routing policy.

PrivateLink (interface VPC endpoints) solves a different problem entirely: rather than connecting whole networks, it exposes a single specific service privately, over ENIs placed directly in your subnets, without requiring any IP address space planning coordination between provider and consumer VPCs at all — the standard pattern for securely consuming a specific AWS service or a partner’s SaaS offering without broad network-level connectivity.

A VPC itself is a regional construct with no single point of failure, but the resources and gateways placed inside it very much can be — and VPC-level HA design is really about correctly distributing those resources across Availability Zones.

Subnets are inherently AZ-scoped — a subnet exists entirely within one Availability Zone and cannot span multiple. Genuine high availability therefore requires deliberately creating subnets (and the resources within them) across at least two, typically three, AZs, with load balancers, Auto Scaling groups, and NAT Gateways all explicitly configured to span that same AZ set, rather than assuming the VPC construct itself provides multi-AZ resilience automatically.

The most common HA misconfiguration at the VPC layer is exactly the single-NAT-Gateway mistake from Chapter 3: a cost-optimization decision to run one shared NAT Gateway for an entire VPC, made without recognizing that it silently reintroduces a single-AZ failure domain for every private subnet’s outbound connectivity, undermining an otherwise carefully designed multi-AZ compute architecture.

Network performance inside a VPC is governed by instance-type-level networking capability, Enhanced Networking, and placement strategy far more than by anything configured at the VPC construct itself.

Elastic Network Adapter (ENA) support, tied to instance type and size, determines the maximum achievable network throughput and packet-per-second rate for a given instance — a networking-intensive workload placed on an instance type without adequate ENA-driven bandwidth will bottleneck regardless of how well the surrounding VPC is designed. Cluster placement groups reduce inter-instance latency and increase achievable throughput specifically for instances that need to communicate heavily with each other, by packing them onto physically proximate hardware within a single AZ — a meaningful lever for tightly-coupled, high-throughput workloads like distributed training or HPC clusters.

NAT Gateway bandwidth is itself a scalable-but-not-infinite resource — each NAT Gateway supports a large but finite amount of bandwidth, and workloads with very high sustained outbound throughput requirements should validate NAT Gateway bandwidth limits explicitly rather than assuming unlimited scaling, potentially distributing load across multiple NAT Gateways per AZ if genuinely necessary.

The combination of stateful security groups and stateless NACLs is a genuine defense-in-depth design, not redundant duplication — advanced security architectures deliberately use both layers for what each does best.

Security groups, being stateful and instance-scoped, are the right place for fine-grained, application-aware access control — “only the load balancer’s security group may reach port 443 on this instance.” NACLs, being stateless and subnet-scoped, are the right place for broad, subnet-wide guardrails, most notably explicit deny rules — security groups support allow rules only, so any requirement to explicitly block a specific known-bad CIDR range regardless of any other rule must be implemented at the NACL layer, since it’s the only layer capable of expressing a deny.

VPC Flow Logs provide the audit and forensic layer underneath both: a record of accepted and rejected traffic at the ENI, subnet, or VPC level, essential for both security investigation and for validating that security group and NACL rules are actually producing the intended traffic pattern rather than the one an engineer assumed they’d configured.

VPC observability leans on three purpose-built tools — Flow Logs, Traffic Mirroring, and Reachability Analyzer — each answering a genuinely different question about what’s happening inside a software-defined network.

VPC Flow Logs answer “what traffic was allowed or rejected, and by which layer” at a summary level (source, destination, port, protocol, accept/reject), making them the primary tool for security auditing and for diagnosing “traffic I expected to be blocked is getting through” or vice versa. Traffic Mirroring answers a deeper question — “what does the actual packet content look like” — by copying real traffic from an ENI to a monitoring target, essential for deep packet inspection or intrusion detection use cases that flow-level summaries can’t support. VPC Reachability Analyzer answers a third, entirely different question: “is a path between these two points even theoretically possible, given the current route tables, security groups, and NACLs” — a static configuration analysis tool that can identify a broken path without generating any actual traffic at all, valuable for pre-validating a design change before it ever reaches production.

The durable large-scale VPC architectures share a common shape: centralized, explicitly governed connectivity and shared services, rather than organically grown, ad hoc network relationships between independently managed VPCs.

VPC’s core trade-off is one of near-total networking flexibility against the genuine architectural discipline required to keep that flexibility from producing an unmanageable, ungoverned network sprawl at scale.

Nearly every advanced VPC incident traces back to a small, well-known set of planning mistakes made early and discovered late — CIDR overlap, single-AZ NAT dependencies, and organically grown peering meshes chief among them.

VPC architecture patterns scale directly with organizational complexity — from a single team’s simple two-tier subnet layout to enterprise-wide, centrally governed multi-account network topologies.