VPC Peering: Routing IPs Between Private Clouds

The Problem of Isolated Cloud Networks

Cloud providers give you complete network isolation by default. Each Virtual Private Cloud (VPC) is its own private address space, completely separated from all other VPCs even within the same account. Your database cluster in VPC-A and your application tier in VPC-B cannot communicate, period — until you deliberately connect them.

The naive solution is to give both services public IP addresses and route traffic over the internet. That approach is expensive, introduces latency, expands your attack surface, and forces you to encrypt all inter-service traffic carefully because it traverses public infrastructure. The correct solution is VPC Peering: a private network connection between two VPCs that routes traffic entirely through the cloud provider's internal backbone, bypassing the public internet completely.

This article covers how VPC Peering works at the routing level, how to configure it correctly, the common mistakes that break it, and when to use alternatives like AWS Transit Gateway instead.

How VPC Peering Works: The Routing Reality

A VPC Peering connection is not a tunnel and it is not a VPN. There is no VPN gateway, no encryption overhead, and no IPsec negotiation. A peering connection is simply an agreement between two VPC route tables that traffic destined for the remote VPC's CIDR range should go through the peering link rather than being dropped.

When you create a VPC Peering connection in AWS, you create a logical link between two VPCs. AWS assigns it a Peering Connection ID (format: pcx-xxxxxxxxxxxxxxxxx). However, the mere existence of this connection does not route any traffic. You must manually add route entries in each VPC's route tables pointing at the Peering Connection ID for the remote CIDR range. Forgetting this step is the single most common VPC Peering misconfiguration.

Additionally, security groups and network ACLs on both sides must explicitly permit the traffic you want to flow. A correctly configured route table entry that is blocked by a security group rule will still result in dropped connections. Both layers must be configured.

Step-by-Step Configuration

The configuration sequence for connecting VPC-A (10.1.0.0/16) to VPC-B (10.2.0.0/16) is:

1. Create the peering connection: In the VPC console, initiate a peering request from VPC-A targeting VPC-B. If VPC-B is in a different account, you will need the account ID and VPC ID. VPC-B must accept the request.
2. Update VPC-A's route table: Add a route: Destination 10.2.0.0/16, Target: the Peering Connection ID. This tells VPC-A that traffic for the 10.2.x.x range should go through the peering link.
3. Update VPC-B's route table: Add a route: Destination 10.1.0.0/16, Target: the same Peering Connection ID. This tells VPC-B how to send return traffic back.
4. Update security groups: On the resources in VPC-B you want to access, add inbound rules allowing traffic from 10.1.0.0/16 on the required ports. On resources in VPC-A initiating connections, ensure outbound rules permit traffic to 10.2.0.0/16.
5. Update network ACLs if applicable: If you use network ACLs (stateless), you must add both inbound and outbound rules for the traffic and remember to account for ephemeral port ranges for return traffic.

Architecture Patterns

Simple Two-VPC Peering

The basic pattern: one peering connection between VPC-A and VPC-B. Suitable for connecting an application tier to a database tier, or a development VPC to a shared services VPC. Route configuration as described above. Security group rules locked down to the minimum required ports.

Hub-and-Spoke with a Shared Services VPC

Many organizations run a central "shared services" VPC containing DNS resolvers, monitoring agents, logging infrastructure, and security tooling. Individual application VPCs peer with this hub VPC. Each spoke VPC has one peering connection to the hub, and the hub has peering connections to all spokes.

The limitation: VPC Peering is non-transitive. If VPC-A peers with Hub and Hub peers with VPC-B, VPC-A cannot reach VPC-B through the hub. Traffic does not flow through peering connections. Each spoke can only reach the hub — spokes cannot reach each other via the hub without direct peering connections between them.

Full Mesh Peering

When every VPC needs to communicate with every other VPC, you need a full mesh: a peering connection between every pair of VPCs. For N VPCs, this requires N*(N-1)/2 peering connections. For 5 VPCs: 10 connections. For 10 VPCs: 45 connections. This becomes operationally unmanageable quickly and is why AWS Transit Gateway exists.

VPC Peering vs. Transit Gateway vs. PrivateLink

CIDR Overlap: The Fatal Constraint

VPC Peering has one hard requirement that causes significant architecture headaches: the CIDR ranges of peered VPCs must not overlap. You cannot peer a VPC using 10.0.0.0/16 with another VPC using 10.0.0.0/16 — there is no way for the route table to distinguish between the two networks.

This constraint forces disciplined IP address planning at the organizational level. Cloud architecture teams typically maintain an IP address management (IPAM) registry that assigns non-overlapping CIDR ranges to every VPC across all accounts and regions. AWS introduced AWS IPAM as a managed service to help with this. Without it, CIDR conflicts are common, especially when organizations grow through acquisition and merge cloud environments that were planned independently.

AWS PrivateLink sidesteps this constraint entirely by using DNS-based service endpoints rather than IP routing, making it preferable when CIDR ranges are not under your control.

Common Misconceptions About VPC Peering

Misconception 1: "Creating the peering connection is all you need to do"

The peering connection itself is just a logical construct — no traffic flows through it until you add matching route table entries on both sides. This is the most common configuration mistake. After creating a peering connection, always immediately check both route tables and verify the CIDR-to-pcx route entries are present. AWS will not warn you if you forget.

Misconception 2: "VPC Peering works like a VPN so traffic is encrypted"

VPC Peering does not add encryption. Traffic flows over AWS's internal network fabric, which is physically isolated from the public internet, but the packets themselves are not encrypted by the peering mechanism. If your compliance requirements mandate encryption in transit, you need to implement TLS at the application layer regardless of peering.

Misconception 3: "Peered VPCs can share internet gateways or NAT gateways"

This is explicitly not supported. Resources in VPC-A cannot reach the internet through VPC-B's internet gateway or NAT gateway, even if the peering connection is active and routes are configured. Each VPC must have its own internet gateway or NAT gateway for outbound internet access. Attempting to route internet traffic through a peered VPC results in dropped packets.

Misconception 4: "VPC Peering replaces all need for Transit Gateway"

VPC Peering is ideal for simple, stable connections between a small number of VPCs. Once you have more than 5-7 VPCs that need inter-connectivity, the number of peering connections and route table entries becomes operationally complex and error-prone. AWS Transit Gateway provides centralized management, transitive routing, and scales to thousands of VPCs — scenarios where maintaining a VPC Peering mesh is impractical.

Pro Tips for VPC Peering Configurations

• Plan CIDR ranges before you deploy anything. Retroactively changing VPC CIDR ranges is painful — AWS added the ability to associate secondary CIDRs with a VPC, but primary CIDR ranges cannot be changed after creation. Use an IPAM tool or spreadsheet to track all assigned ranges across accounts and regions before creating any new VPC.
• Use specific subnets in route tables rather than full VPC CIDRs when possible. Instead of routing all of 10.2.0.0/16 through the peering connection, route only the specific subnets that contain the resources you need access to. This limits blast radius if a routing error occurs and makes the intent explicit in the route table.
• Tag peering connections with both VPC names and the purpose. In large environments with dozens of peering connections, untagged pcx IDs are meaningless. Always tag with something like Name: vpc-app-prod to vpc-db-prod and Purpose: app-to-database-connectivity.
• Audit security groups regularly to avoid over-permissive rules. A common pattern is opening a security group to the entire peered VPC CIDR (10.2.0.0/16) when only connections from specific application servers are needed. Use the specific private IPs or security group references for source rules instead of broad CIDR ranges.
• Use VPC Flow Logs on both sides to diagnose connectivity issues. When traffic is not flowing as expected, Flow Logs show whether packets are being accepted or rejected at each hop, making it straightforward to distinguish between a routing problem and a security group problem.
• Consider PrivateLink for services you expose to external accounts. If you want to share a specific service (like an API or database endpoint) with partner accounts without giving them broad access to your VPC, PrivateLink exposes only that service as an endpoint DNS name, significantly limiting what the consuming account can reach.

Inspection, transitivity, and Transit Gateway trade-offs

Peering is non-transitive by design: spoke A cannot reach spoke C through a hub peer unless you hairpin routes and accept asymmetric paths. Centralized inspection VPCs often prefer Transit Gateway attachments with explicit route propagation tables so security appliances see both directions. Remember NACL vs security group statefulness when mixing peering with appliance subnets.

VPC Peering solves a fundamental cloud networking problem cleanly and cheaply for small topologies. Getting it right requires careful IP planning, disciplined route table management, and a clear understanding of its limitations — especially non-transitivity and the CIDR overlap constraint. Check your IP routing and network configuration here.