VPC Peering Deep Dive: Connect Two VPCs with Private IP Routing

When your architecture spans multiple VPCs — whether for environment isolation (dev/prod), service segmentation, or team boundaries — you need a secure, low-latency path between them that never touches the public internet. VPC Peering is AWS's native, non-transitive solution for exactly this: a private network link between two VPCs using their existing CIDR ranges.

TL;DR

StepActionWhere
1Verify non-overlapping CIDRsVPC Console / CLI
2Create Peering Connection (Requester → Accepter)VPC > Peering Connections
3Accept the Peering RequestAccepter VPC account/region
4Update Route Tables in both VPCsVPC > Route Tables
5Update Security Groups to allow trafficEC2 > Security Groups
6Enable DNS Resolution (optional but recommended)Peering Connection settings

Prerequisites: The Golden Rule — No CIDR Overlap

VPC Peering will fail to route correctly if the two VPCs share overlapping CIDR blocks. This is a hard constraint. Before anything else, confirm your CIDRs are distinct.

  • VPC-A: 10.0.0.0/16
  • VPC-B: 10.1.0.0/16

These are the values used throughout this guide. Substitute your own CIDRs accordingly.

Architecture Overview

Before touching the console or CLI, understand the data flow. A peering connection is a logical, one-to-one link. Traffic from an EC2 instance in VPC-A destined for a private IP in VPC-B must have a route table entry pointing to the peering connection as the target — and vice versa.

graph LR subgraph VPC_A ["VPC-A (10.0.0.0/16)"] EC2_A["EC2-A 10.0.1.10"] RTB_A["Route Table A 10.1.0.0/16 → pcx-xxx"] end subgraph PEERING ["Peering Connection"] PCX["pcx-xxxxxxxx (Active)"] end subgraph VPC_B ["VPC-B (10.1.0.0/16)"] RTB_B["Route Table B 10.0.0.0/16 → pcx-xxx"] EC2_B["EC2-B 10.1.1.5"] end EC2_A -->|"dst: 10.1.1.5"| RTB_A RTB_A --> PCX PCX --> RTB_B RTB_B --> EC2_B
  1. EC2-A (in VPC-A, subnet 10.0.1.0/24) initiates a request to 10.1.1.5.
  2. The subnet's route table in VPC-A has an entry: 10.1.0.0/16 → pcx-xxxxxxxx. Traffic is forwarded to the peering connection.
  3. The peering connection (pcx-xxxxxxxx) acts as the private bridge — no IGW, no NAT, no public IPs involved.
  4. VPC-B's route table has a matching entry: 10.0.0.0/16 → pcx-xxxxxxxx, delivering the packet to EC2-B.
  5. EC2-B's Security Group must explicitly allow inbound traffic from 10.0.0.0/16 (or the specific SG of EC2-A).
Analogy: Think of two private office buildings (VPCs) on the same city block. By default, employees must exit onto the public street to visit the other building. VPC Peering is like building a private, locked corridor directly between the two lobbies — no public exposure, no detours, direct access controlled by internal security desks (Security Groups).

Step-by-Step Implementation

Step 1: Create the Peering Connection

The VPC that initiates the request is the Requester. Since both VPCs are in the same account and region, acceptance is straightforward.

🔽 AWS CLI — Create & Accept Peering Connection 
# --- Variables ---
REQUESTER_VPC_ID="vpc-aaaaaaaa"   # VPC-A: 10.0.0.0/16
ACCEPTER_VPC_ID="vpc-bbbbbbbb"    # VPC-B: 10.1.0.0/16
REGION="us-east-1"

# --- Step 1: Create the peering connection request ---
PEERING_ID=$(aws ec2 create-vpc-peering-connection \
  --vpc-id $REQUESTER_VPC_ID \
  --peer-vpc-id $ACCEPTER_VPC_ID \
  --region $REGION \
  --query 'VpcPeeringConnection.VpcPeeringConnectionId' \
  --output text)

echo "Peering Connection ID: $PEERING_ID"

# --- Step 2: Accept the peering connection ---
# (Same account/region — can be done immediately)
aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id $PEERING_ID \
  --region $REGION

# --- Step 3: Tag it for clarity ---
aws ec2 create-tags \
  --resources $PEERING_ID \
  --tags Key=Name,Value="vpc-a-to-vpc-b-peering" \
  --region $REGION

echo "Peering connection $PEERING_ID is now ACTIVE."

Step 2: Update Route Tables in Both VPCs

This is the most critical step. A peering connection without route table entries is inert — traffic has no path to follow. You must update route tables in both VPCs.

graph TD subgraph VPC_A_RT ["VPC-A Route Table (rtb-11111111)"] R1["10.0.0.0/16 → local"] R2["10.1.0.0/16 → pcx-xxxxxxxx"] R3["0.0.0.0/0 → igw-aaa (optional)"] end PCX["Peering Connection pcx-xxxxxxxx"] subgraph VPC_B_RT ["VPC-B Route Table (rtb-22222222)"] R4["10.1.0.0/16 → local"] R5["10.0.0.0/16 → pcx-xxxxxxxx"] R6["0.0.0.0/0 → igw-bbb (optional)"] end R2 -->|"Routes cross-VPC traffic"| PCX PCX -->|"Delivers to peer VPC"| R5
  1. VPC-A's route table gets a new entry: destination 10.1.0.0/16, target pcx-xxxxxxxx.
  2. VPC-B's route table gets a new entry: destination 10.0.0.0/16, target pcx-xxxxxxxx.
  3. Both entries are required. Missing either one results in one-way or no connectivity.
🔽 AWS CLI — Update Route Tables in Both VPCs 
# --- Variables (continue from above) ---
RTB_VPC_A="rtb-11111111"   # Route table associated with VPC-A subnets
RTB_VPC_B="rtb-22222222"   # Route table associated with VPC-B subnets

# --- Add route in VPC-A: send 10.1.0.0/16 traffic through the peering connection ---
aws ec2 create-route \
  --route-table-id $RTB_VPC_A \
  --destination-cidr-block "10.1.0.0/16" \
  --vpc-peering-connection-id $PEERING_ID \
  --region $REGION

echo "Route added to VPC-A route table."

# --- Add route in VPC-B: send 10.0.0.0/16 traffic through the peering connection ---
aws ec2 create-route \
  --route-table-id $RTB_VPC_B \
  --destination-cidr-block "10.0.0.0/16" \
  --vpc-peering-connection-id $PEERING_ID \
  --region $REGION

echo "Route added to VPC-B route table."

Step 3: Update Security Groups

Route tables control where traffic goes. Security Groups control whether it's allowed. An instance in VPC-B must explicitly permit inbound traffic from VPC-A's CIDR (or a specific Security Group ID).

# Allow inbound traffic from VPC-A (10.0.0.0/16) on port 443 to an instance in VPC-B
SG_VPC_B="sg-bbbbbbbb"   # Security group attached to EC2-B

aws ec2 authorize-security-group-ingress \
  --group-id $SG_VPC_B \
  --protocol tcp \
  --port 443 \
  --cidr "10.0.0.0/16" \
  --region $REGION

echo "Security group updated for VPC-B instances."

Least Privilege Tip: Instead of allowing the entire VPC-A CIDR, reference the specific Security Group ID of the source instances in VPC-A. This is more precise and reduces blast radius.

# More precise: allow traffic from a specific SG in VPC-A
SG_VPC_A="sg-aaaaaaaa"

aws ec2 authorize-security-group-ingress \
  --group-id $SG_VPC_B \
  --protocol tcp \
  --port 443 \
  --source-group $SG_VPC_A \
  --region $REGION

Step 4: Enable DNS Resolution (Recommended)

By default, DNS hostnames from one VPC are not resolvable in the peer VPC. Enable this so instances can resolve each other's private DNS names across the peering link.

# Enable DNS resolution from VPC-A to VPC-B
aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id $PEERING_ID \
  --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true \
  --region $REGION

# Enable DNS resolution from VPC-B to VPC-A
aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id $PEERING_ID \
  --accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=true \
  --region $REGION

Verification

After all steps are complete, SSH into an EC2 instance in VPC-A and test connectivity to a private IP in VPC-B.

# From EC2-A (10.0.1.10), ping EC2-B's private IP
ping 10.1.1.5

# Or test a specific port with nc (netcat)
nc -zv 10.1.1.5 443

If the ping fails, work through this checklist:

  • ✅ Peering connection status is Active (not Pending-Acceptance)
  • ✅ Route table entries exist in both VPCs pointing to the peering connection ID
  • ✅ The correct route table is associated with the relevant subnets
  • ✅ Security Groups on the target instance allow inbound from the source CIDR/SG
  • ✅ Network ACLs (NACLs) on both subnets are not blocking the traffic (NACLs are stateless)

Key Limitations to Know

LimitationDetail
Non-transitiveIf VPC-A peers with VPC-B and VPC-B peers with VPC-C, VPC-A cannot reach VPC-C through VPC-B. Each pair needs its own peering connection.
No overlapping CIDRsHard requirement. Plan your IP address space before deploying VPCs.
No edge-to-edge routingYou cannot route traffic from a peered VPC through an IGW, VPN, or Direct Connect gateway attached to the other VPC.
ScalabilityAt scale (many VPCs), peering becomes a mesh problem. Consider AWS Transit Gateway for hub-and-spoke topologies.

IAM Permissions Required

The IAM principal executing these commands needs the following minimum permissions:

{
  "Effect": "Allow",
  "Action": [
    "ec2:CreateVpcPeeringConnection",
    "ec2:AcceptVpcPeeringConnection",
    "ec2:CreateRoute",
    "ec2:ModifyVpcPeeringConnectionOptions",
    "ec2:AuthorizeSecurityGroupIngress",
    "ec2:CreateTags",
    "ec2:DescribeVpcPeeringConnections",
    "ec2:DescribeRouteTables"
  ],
  "Resource": "*"
}

Glossary

TermDefinition
VPC Peering ConnectionA networking connection between two VPCs enabling private IP routing. Identified by a pcx- prefix.
Route TableA set of rules (routes) that determine where network traffic from a subnet is directed.
Non-transitive PeeringTraffic cannot flow through an intermediate VPC to reach a third VPC — each pair must have a direct peering connection.
CIDR BlockClassless Inter-Domain Routing notation defining the IP address range of a VPC (e.g., 10.0.0.0/16).
Security GroupA stateful virtual firewall controlling inbound and outbound traffic at the instance level.

Next Steps

VPC Peering is the right tool for simple, point-to-point VPC connectivity. If your architecture grows to 5+ VPCs, evaluate AWS Transit Gateway for centralized, scalable routing. For the official VPC Peering documentation, refer to the AWS VPC Peering Guide.

Comments

Post a Comment

Popular posts from this blog

EC2 No Internet Access in Custom VPC: Attaching an Internet Gateway and Fixing Route Tables

Launching an EC2 instance in a custom VPC only to find it cannot reach the internet is one of the most common networking pitfalls in AWS — and it almost always comes down to two missing pieces: an Internet Gateway (IGW) and a correctly configured Route Table. This post walks you through the exact architecture, the root cause, and the precise steps to fix it. TL;DR Step Action Why It Matters 1 Create and attach an Internet Gateway to your VPC Without an IGW, there is no path between your VPC and the public internet 2 Add a 0.0.0.0/0 route pointing to the IGW in your subnet's Route Table The route table is the traffic director — without this entry, outbound packets have nowhere to go 3 Assign a Public IP or Elastic IP to the EC2 instance The IGW performs NAT only for instances with a public IP address 4 Verify Security Group allows outbound traffic Security Groups are stateful firewalls; outbound rules...
Read more

IAM User vs. IAM Role: Why Your EC2 Instance Should Never Use a User

Choosing between an IAM User and an IAM Role is one of the most consequential security decisions in AWS — get it wrong and you either expose long-lived credentials or block your application entirely. This post cuts through the confusion and gives you a definitive answer for the EC2-to-S3 access pattern. TL;DR — Quick Comparison Dimension IAM User IAM Role Identity type A person or a static service account An assumable identity for AWS services, users, or external principals Credential type Long-lived Access Key ID + Secret Access Key Short-lived, auto-rotating STS tokens (max 12 h by default) Credential rotation Manual — you must rotate keys yourself Automatic — AWS rotates them transparently Stored on EC2? Yes — in ~/.aws/credentials or env vars (risky) No — delivered via the In...
Read more

Lambda Infinite Loop with S3: How to Prevent Recursive Triggers

Writing a processed file back to the same S3 bucket that triggered your Lambda function creates a recursive loop — each output file fires a new invocation, which writes another file, ad infinitum. Left unchecked, this silently drains your AWS budget and exhausts Lambda concurrency limits within minutes. TL;DR Strategy Mechanism Best For Complexity Separate Output Prefix/Bucket S3 event filter on prefix Simple pipelines Low Object Metadata Check Lambda reads S3 object metadata before processing Single-bucket requirement Medium Separate Output Bucket Trigger only on source bucket Clean architectural separation Low DynamoDB Idempotency Guard Track processed ETag/key in DynamoDB Exactly-once guarantees Medium-High Understanding the Recursive Loop Before fixing the problem, you need to understand exactly why it happens. The S3 → Lambda trigger is an event-driven subscription: S3 publishes an ObjectCreat...
Read more