VPC Peering

By the end of this lesson you will be able to

• Explain what a VPC peering connection is, where it works (same or different account, same or different Region) and why it needs no gateway, VPN or extra hardware.
• Build one end to end: request, accept, routes in both VPCs, security groups and network ACLs, and DNS resolution across the link.
• Spot the four rules that break peering designs: no overlapping CIDRs, not transitive, no edge-to-edge routing, and the full-mesh explosion of n(n−1)/2 connections.
• Describe what changes with inter-Region peering (encryption, MTU, security-group references, DNS) and what peering costs.
• Troubleshoot a peering that is active but carries no traffic, and decide when peering is the right answer and when Transit Gateway, PrivateLink or VPC sharing is.

#Why connect two VPCs at all

A VPC is a walled network (lesson 3.2). That wall is the point: production cannot be touched from a developer’s test VPC, and one team’s mistake stays inside its own VPC. Most companies therefore end up with many VPCs, often in many accounts (one per team, environment or business unit, managed with AWS Organizations, lesson 20.1).

Sooner or later two of those VPCs must talk. The payments service has to stream transactions to the analytics team’s reporting database. A fraud-scoring service in one VPC must be called by the checkout service in another. Without a private connection the only path is the public internet: public IPs, internet gateways, NAT gateways, traffic leaving AWS and coming back, and a bigger attack surface. VPC peering is the simplest private alternative.

#What VPC peering is

A VPC peering connection is a private network link between exactly two VPCs. Once it is set up, instances in either VPC reach instances in the other using private IPv4 or IPv6 addresses, as if both VPCs were one network.

• On the AWS backbone. Traffic never crosses the public internet. Peering is built into the VPC networking itself: it is not a gateway, not a VPN and not a device, so it has no single point of failure and no bandwidth bottleneck of its own. The limit is what the instances can send.
• Same or different account. The other VPC may belong to you or to another AWS account.
• Same or different Region. Peering between Regions is called inter-Region peering (more below).
• One connection per pair. You cannot create two peering connections between the same two VPCs, and you do not need to: there is nothing to make redundant.
• ID pcx-…. In a route table the peering connection appears as a target, the same way an internet gateway (igw-…) or NAT gateway (nat-…) does (lesson 3.3).

#How a peering connection is built

#Request and accept

A peering connection has a requester and an accepter:

1. The owner of the requester VPC creates a peering request naming the accepter VPC (its VPC ID, and its account ID and Region if they differ).
2. AWS checks the two VPCs’ CIDR blocks. If any of them overlap, the request fails at once.
3. Otherwise the request waits in pending-acceptance. The owner of the accepter VPC accepts or rejects it. If nobody acts, it expires after 7 days.
4. After acceptance it briefly shows provisioning and then becomes active.

Who does what matters in exam questions:

• Same account: you create and accept it yourself.
• Cross-account: the accepter account must accept. The requester cannot accept on its behalf.
• Cross-Region: the request is created in the requester’s Region, and it must be accepted in the accepter VPC’s Region. Looking for it in the requester’s Region console shows nothing to accept.
• Either owner can delete an active peering at any time; both sides lose connectivity immediately.

#Routes in both VPCs

An active peering carries nothing until routes point at it. Creating the connection adds no routes on either side.

• In VPC A, every route table whose subnets must reach VPC B gets a route: destination = VPC B’s CIDR, target = pcx-….
• In VPC B, every route table whose subnets must answer gets the route back: destination = VPC A’s CIDR, target = the same pcx-….
• A missing route on either side breaks the conversation. The nasty case is a missing route on the receiving side: the request arrives, the server even sees it, but the reply has no way home and the caller times out.
• You do not have to route the whole CIDR. Routing only 10.20.2.0/24 instead of 10.20.0.0/16 exposes just the database subnet. Normal longest prefix match applies (lesson 3.3).
• Each owner controls only its own route tables. In a cross-account peering, both teams must do their half.

#Security groups and network ACLs

Routes decide where a packet goes; firewalls decide whether it is allowed (lesson 3.5).

• The receiving instance’s security group must allow the peer’s traffic. By default it allows nothing from another VPC.
• In the same Region, a security group rule can reference a security group in the peer VPC, even in another account. Across accounts you write it as account-id/sg-id, for example 111122223333/sg-0aa11bb22.
• Across Regions, security-group references are not supported: use the peer’s CIDR (as narrow as possible) instead.
• If the peer later deletes the referenced group, or the peering is deleted, the rule becomes a stale security group rule. It stops matching but stays in your group until you remove it (describe-stale-security-groups lists them).
• Network ACLs on both subnets must allow the traffic and, because they are stateless, the return traffic on ephemeral ports.

#DNS across a peering

Instances often call each other by name, not by IP. By default, if an instance uses the public DNS hostname of an instance in the peer VPC (ec2-203-0-113-40.ap-southeast-1.compute.amazonaws.com), the name resolves to the public IP, and the traffic tries the internet instead of the peering.

• Turn on DNS resolution for the peering connection. In the console: Edit DNS settings → Requester DNS resolution (“Allow accepter VPC to resolve the DNS of requester VPC”) and Accepter DNS resolution (“Allow requester VPC to resolve the DNS of accepter VPC”). In the API it is AllowDnsResolutionFromRemoteVpc in each side’s peering options.
• After that, the public hostname of a peer instance resolves to its private IP when looked up from the other VPC, and the traffic rides the peering.
• Requirements: the peering must be active, both VPCs need DNS resolution and DNS hostnames enabled, and each owner sets the option for its own side.
• For inter-Region peering, or a VPC whose CIDR is outside the private RFC 1918 ranges, this option is needed even to resolve private DNS hostnames to private IPs.
• You cannot query the Amazon DNS server of the peer VPC directly. For private hosted zones, associate the zone with both VPCs (Route 53, chapter 8).

#The four rules that make or break peering

#Rule 1: CIDRs must not overlap, not even partly

AWS refuses to create a peering between VPCs whose CIDR blocks overlap (lesson 3.1). The reason is routing: if both VPCs own 10.0.5.9, VPC A’s route table would need 10.0.0.0/16 → pcx, but that range is already its own local route. No router can tell “my 10.0.5.9” from “yours”.

• Identical ranges overlap (10.0.0.0/16 and 10.0.0.0/16).
• Contained ranges overlap (10.0.0.0/16 and 10.0.128.0/20).
• Secondary CIDR blocks count: if any IPv4 or IPv6 block of one VPC overlaps any block of the other, the peering is refused, even if you only plan to route the non-overlapping blocks.
• A VPC’s primary CIDR cannot be changed later. The fix for an existing overlap is a re-IP: build a new VPC on a free range and move the workloads.

The same rule applies to on-premises networks: the VPC’s range and the data centre’s range must not overlap, or VPN and Direct Connect routing fails in the same way (lessons 22.4 and 22.5). Plan one company-wide address plan, for example with VPC IP Address Manager (IPAM), before anyone creates VPCs.

#Rule 2: peering is not transitive

If A is peered with B, and B is peered with C, A cannot reach C. A peering only delivers packets whose destination is inside the peer VPC. A packet from A addressed to C is dropped at the A–B link, whatever routes anyone adds, because B never receives it to forward.

To let A and C talk, create a direct A–C peering (with routes in both), or put all of them on a Transit Gateway, which does route between attachments (lesson 22.6).

#Rule 3: no edge-to-edge routing

A peer can reach addresses inside your VPC, nothing behind it. It cannot use your VPC as a path to somewhere else. If VPC A has any of the following, VPC B cannot use it through the peering:

• an internet gateway (B cannot reach the internet through A);
• a NAT gateway or NAT instance;
• a Site-to-Site VPN connection or Direct Connect connection to a corporate network;
• an S3 or DynamoDB gateway endpoint (lesson 10.10 showed this one).

What does work is anything with a real address inside the peer: an instance, a database, an internal load balancer, or an interface endpoint ENI, because its private IP is inside the peer VPC.

#Rule 4: the full mesh grows fast

Because peering is not transitive, every pair of VPCs that must talk needs its own connection. For n VPCs that must all reach each other, a full mesh needs n(n−1)/2 peerings, each with routes on both sides:

Quotas make this worse: a VPC may have 50 active peering connections by default, adjustable up to 125, and 25 outstanding requests. So a full mesh of more than 126 VPCs is impossible, and above 51 it needs quota increases and thousands of routes (a route table also has its own route limit). This is why “simplify a complex mesh of VPC peering connections” or “hundreds of VPCs” points to Transit Gateway (lesson 22.6): 100 VPCs become 100 attachments to one hub.

#Inter-Region peering

Peering works between VPCs in different Regions, in the same or different accounts, with a few differences:

• Encrypted. Inter-Region traffic is encrypted by AWS and stays on the AWS global backbone, still with no single point of failure or bandwidth bottleneck.
• Accept in the accepter’s Region, as described above.
• No security-group references across Regions: use CIDRs.
• MTU: jumbo frames up to 9,001 bytes within a Region, 8,500 bytes between Regions.
• DNS: you must enable DNS resolution on the peering even to resolve private hostnames to private IPs.
• Cost: traffic is charged at inter-Region data transfer rates.

#What peering costs

• No charge to create a peering connection and no hourly fee. There is no per-GB processing fee either, unlike a transit gateway.
• Data transfer within one Availability Zone is free, even between accounts (since May 2021). The AZ is compared by AZ ID (for example aps1-az1), not by AZ name, because ap-south-1a in one account may be a different physical AZ in another.
• Cross-AZ traffic over a peering is charged like any cross-AZ traffic in the Region, about $0.01 per GB in each direction.
• Inter-Region traffic is charged at the sending Region’s inter-Region data transfer rate (about $0.02 per GB in many Regions, more in some).
• Compared with a transit gateway (attachment-hours plus about $0.02 per GB processed), peering is the cheapest way to move a lot of data between two VPCs. Lesson 22.8 (network costs) puts these numbers side by side. Prices change: check the VPC and EC2 pricing pages for your Region.

#What goes wrong

• Peering stuck in pending-acceptance: the accepter account never accepted, or is looking in the wrong Region. After 7 days the request expires and must be recreated.
• Request failed at once: overlapping CIDRs, including a forgotten secondary block or IPv6 block.
• Active but nothing flows: no route on one side, or the route was added to the main route table while the subnet uses a custom one.
• The server sees the connection, the client times out: the receiving VPC has no route back.
• Timeouts with correct routes: the receiver’s security group does not allow the peer, or a network ACL drops the traffic or its return on ephemeral ports.
• Security group rule rejected: referencing a security group in a peer VPC in another Region. Use CIDRs.
• Traffic goes to the internet instead: the app uses public DNS names or public IPs; enable DNS resolution on the peering and use private IPs. Traffic to a peer’s public IP leaves through the internet gateway and is billed as internet-facing transfer.
• A third VPC unreachable: someone assumed transitivity.
• No internet or no on-premises access from the peer: someone assumed edge-to-edge routing.
• Stale security group rules after the peer deletes a group or the peering: clean them up.
• Large packets dropped between Regions: jumbo frames over 8,500 bytes on inter-Region peering; let Path MTU Discovery work (allow ICMP “fragmentation needed”).

#How it is used in system design

• Prod and analytics, or app and shared database: two VPCs with heavy, low-latency traffic. Peering is free in the same AZ and has no processing fee, so it beats a hub for one busy pair.
• Shared services for a handful of VPCs: a few application VPCs each peered with one shared-services VPC (directory, CI runners, monitoring). The application VPCs cannot reach each other through it, which is often exactly the isolation you want.
• Cross-Region replication paths: database replicas, cache warming or file sync between two Regions over inter-Region peering, encrypted, without VPN appliances.
• Partner integration: two companies’ accounts peered for one data feed, each controlling its own routes and security groups. If only one service should be exposed, or ranges overlap, PrivateLink is cleaner.
• At scale: Transit Gateway for many VPCs and hybrid links, and teams keep peering beside the transit gateway for the few VPC pairs that move the most data, to avoid per-GB processing fees.

#Peering or something else?

#Try it yourself

# 1. In the prod account (ap-south-1): request a peering with the analytics account's VPC
aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-0a1b2c3d4e5f67890 \
  --peer-vpc-id vpc-0f9e8d7c6b5a43210 \
  --peer-owner-id 444455556666
# {
#   "VpcPeeringConnection": {
#     "VpcPeeringConnectionId": "pcx-0a1b2c3d4e5f60718",
#     "Status": { "Code": "initiating-request", "Message": "Initiating Request to 444455556666" },
#     "RequesterVpcInfo": { "CidrBlock": "10.10.0.0/16", "OwnerId": "111122223333" }, ...

# 2. In the analytics account: accept it (for cross-Region, run this in the accepter's Region)
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-0a1b2c3d4e5f60718
# "Status": { "Code": "provisioning", "Message": "Provisioning" }

# 3. Routes on BOTH sides
aws ec2 create-route --route-table-id rtb-0aaa1111example \
  --destination-cidr-block 10.20.0.0/16 --vpc-peering-connection-id pcx-0a1b2c3d4e5f60718
aws ec2 create-route --route-table-id rtb-0bbb2222example \
  --destination-cidr-block 10.10.1.0/24 --vpc-peering-connection-id pcx-0a1b2c3d4e5f60718
# { "Return": true }

# 4. Security group in the analytics VPC: allow PostgreSQL from the prod app's security group
aws ec2 authorize-security-group-ingress --group-id sg-0ccc3333example \
  --ip-permissions 'IpProtocol=tcp,FromPort=5432,ToPort=5432,UserIdGroupPairs=[{GroupId=sg-0aa11bb22example,UserId=111122223333,VpcPeeringConnectionId=pcx-0a1b2c3d4e5f60718}]'

# 5. DNS: each owner enables resolution for its own side (accepter side shown)
aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id pcx-0a1b2c3d4e5f60718 \
  --accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=true

# 6. Inter-Region: request from Mumbai to a VPC in Singapore, then accept in Singapore
aws ec2 create-vpc-peering-connection --region ap-south-1 \
  --vpc-id vpc-0a1b2c3d4e5f67890 --peer-vpc-id vpc-0123456789abcdef0 \
  --peer-region ap-southeast-1
aws ec2 accept-vpc-peering-connection --region ap-southeast-1 \
  --vpc-peering-connection-id pcx-0f9e8d7c6b5a43210

# 7. Check state, and find stale security group rules
aws ec2 describe-vpc-peering-connections \
  --query "VpcPeeringConnections[].[VpcPeeringConnectionId,Status.Code]" --output table
aws ec2 describe-stale-security-groups --vpc-id vpc-0f9e8d7c6b5a43210

From an instance in the prod VPC, test the path with private addresses:

$ dig +short ip-10-20-2-30.ap-south-1.compute.internal
10.20.2.30
$ nc -zv 10.20.2.30 5432
Connection to 10.20.2.30 5432 port [tcp/postgresql] succeeded!
$ traceroute -n 10.20.2.30
 1  10.20.2.30  0.612 ms  0.540 ms  0.533 ms

The single hop in traceroute is the point: a peering is not a router, so there is no extra hop in between. If nc hangs, walk the checklist: route on this side, route back on the other side, security group, network ACL.

#Summary

Key takeaways

• VPC peering = a private link between exactly two VPCs over the AWS backbone; same or different account, same or different Region; no gateway, no single point of failure, no bandwidth bottleneck; one connection per pair.
• Request → accept (cross-account: the accepter accepts; cross-Region: accept in the accepter’s Region; requests expire after 7 days).
• Routes in both VPCs (each subnet route table that needs it; whole CIDR or one subnet), then security groups (peer SG references in the same Region only, account/sg-id across accounts) and network ACLs.
• DNS resolution option on the peering makes public hostnames resolve to private IPs; required for private names across Regions.
• CIDRs must not overlap, not partly and not in secondary blocks; the fix is re-IP, or PrivateLink for one service. The same rule applies to on-premises ranges.
• Not transitive: A–B + B–C ≠ A–C. No edge-to-edge routing: no peer’s IGW, NAT, VPN, Direct Connect or gateway endpoint.
• Full mesh = n(n−1)/2: 10 VPCs = 45, 100 = 4,950; quota 50 active per VPC (up to 125) → many VPCs = Transit Gateway.
• Inter-Region: encrypted, MTU 8,500, no SG references, inter-Region transfer charges.
• Cost: no hourly fee, no processing fee; same AZ (by AZ ID) free; cross-AZ ~$0.01/GB each way; cheapest for two busy VPCs.

Self-check: VPC peering30 questions