AWS VPC Peering Explained: How It Works, Limits, and When to Use It
AWS VPC peering creates a private network connection between two VPCs so their resources can communicate using private IP addresses. Traffic stays on the AWS backbone and never touches the public internet. VPC peering is simple and effective for a small number of VPCs, but it has one hard constraint you need to understand before designing around it: the connection is not transitive. That single limitation determines when peering is the right tool and when it is not.
What VPC peering is, in plain terms
A VPC is a private network you control inside AWS. By default, VPCs are isolated from each other. Resources in one VPC cannot reach resources in another. VPC peering creates a direct link between two specific VPCs so their resources can talk using private IPs, as if they were on the same network.
What peering does not do: it does not connect a chain of VPCs. If VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A has no path to VPC C. Each peering connection is a one-to-one private link, and AWS does not allow traffic to pass through an intermediate VPC. This is the non-transitive rule, enforced at the AWS network layer. No routing trick can bypass it.
VPC peering is not transitive. Traffic from VPC A cannot pass through VPC B to reach VPC C, even if VPC B is peered with both. AWS enforces this at the network layer. If you need any VPC to reach any other VPC through a central hub, use Transit Gateway instead.
Office buildings with private roads: Two office buildings connected by a private road. Employees can drive between them without using public streets. If building A also has a road to building C, that does not mean building B can reach building C through building A. Each road is its own direct connection. No one passes through an intermediate building.
How VPC peering works
Request and acceptance
One VPC owner sends a peering connection request, specifying the target VPC (and target account or region, for cross-account and cross-region peering). The target VPC owner accepts the request. For same-account connections, acceptance can be automated. For cross-account peering, someone in the accepting account must log in and approve it. The connection moves to an Active state once accepted.
Accepting the request is not enough to make traffic flow. Two more steps are required on both sides.
Route tables on both sides
After the peering connection is active, you must add routes to the route tables of every subnet that needs to communicate across the peering. The route points traffic destined for the other VPC’s CIDR at the peering connection ID. This must happen on both VPCs. If you add a route in VPC A pointing to VPC B but forget VPC B’s return route, traffic flows one way only. Asymmetric routing failures are the most common peering mistake.
Security groups and network ACLs
Route tables control where traffic goes. Security groups and network ACLs control whether traffic is allowed. Adding the peering route without updating security groups results in traffic routed correctly to the destination but dropped there. Update the inbound rules on target resources to allow traffic from the remote VPC’s CIDR. For same-region same-account peering, you can reference the remote security group ID directly instead.
DNS resolution
By default, private DNS hostnames (like those assigned to EC2 instances) do not resolve across peering connections. If you want instances in VPC A to resolve the private DNS name of an instance in VPC B, you must enable the DNS resolution option on the peering connection. Both sides must have it enabled. Without this, DNS queries for cross-VPC names return no result or fall back to public IPs. This setting is separate from whether private hosted zones are shared. Both may need to be configured depending on your setup.
Same-account, cross-account, and cross-region
VPC peering supports all three configurations. Cross-account peering requires the accepting account to approve the request. Cross-region peering requires specifying the —peer-region parameter and incurs inter-region data transfer charges. Same-region peering within the same account is the simplest case.
Requirements before you set it up
Check all of these before creating a peering connection:
- Non-overlapping CIDRs. Both VPCs must have completely distinct CIDR blocks. There is no workaround if they overlap.
- Route table updates on both sides. Add routes for the remote VPC’s CIDR in every subnet that needs cross-VPC access.
- Security group rules on target resources. Inbound rules must allow traffic from the remote VPC’s CIDR (or remote security group for same-region/account).
- Network ACL rules if in use. If your subnets use custom network ACLs, verify that inbound and outbound rules allow the peering traffic. NACLs are stateless, so both directions need explicit allow rules.
- DNS resolution option enabled if you need cross-VPC private hostname resolution. Must be enabled on both sides of the connection.
- Account permissions for cross-account peering. The accepting account owner must have IAM permission to accept the peering request.
- Region awareness. Cross-region peering works but incurs higher data transfer costs and does not support edge routing or Gateway Load Balancer.
NACLs are stateless. Unlike security groups, network ACLs do not automatically allow return traffic. If you add an inbound allow rule, you must also add a matching outbound rule on both sides. Missing one direction blocks traffic silently.
When to use VPC peering
VPC peering is the right tool when you have a small, stable number of VPCs that need broad private connectivity. Concrete situations where it works well:
- Shared services VPC. You run logging, monitoring, or internal tooling in a dedicated VPC. Application VPCs each peer with it. Two or three peering connections, straightforward to manage.
- Database isolation. Sensitive databases live in a separate VPC. Application VPCs peer with it for private access. The database VPC has no internet gateway, and the peering connection provides the only access path.
- Cross-account team separation. Different teams own different AWS accounts. A peering connection gives one team’s VPC private access to another team’s services without making anything public. This is cleaner than sharing credentials or routing through the internet.
- Dev/staging/prod with infrequent cross-environment needs. If your environments occasionally need to reach a common config service or secrets store, a peering connection per environment is manageable and cheap.
The general rule: use peering when the number of required connections is small and stable, and when both VPCs need broad network-level access to each other.
When not to use VPC peering
You have more than 4-5 VPCs
Peering scales as a mesh. To connect N VPCs fully, you need N times (N minus 1) divided by 2 peering connections. For 5 VPCs that is 10 connections. For 10 VPCs it is 45. For 20 VPCs it is 190. Each connection needs route table entries and security group rules maintained on both ends. This gets unmanageable fast.
The handshake problem: At a party, if every person must shake hands with every other person, 5 people need 10 handshakes and 20 people need 190. VPC peering works the same way. Every new VPC you add needs a direct connection to every existing VPC. Transit Gateway replaces all of this with one central connection point.
You need transitive routing
If your design requires VPC A to reach VPC C through VPC B, peering cannot do this. AWS blocks it at the network layer. There is no routing workaround. If you need transitive routing, use Transit Gateway.
You only need service-level access, not full network access
If one VPC needs to reach a specific API or database in another VPC but does not need broad network access, AWS PrivateLink is a better fit. PrivateLink exposes a single endpoint, not the full VPC network. It also works even if the VPCs have overlapping CIDRs, which peering does not support.
You want centralized network control
Peering connections are pairwise. There is no central place to enforce routing policy or inspect traffic across all VPCs. If you need centralized inspection, logging, or control of inter-VPC traffic, Transit Gateway with a firewall VPC is the standard architecture.
You are connecting to on-premises
VPC peering is VPC-to-VPC only. For connecting your VPC to an on-premises data center, use Site-to-Site VPN or Direct Connect. If you need on-premises access to reach multiple VPCs, peering will not propagate that access. Transit Gateway handles this.
VPC peering vs alternatives
Each option solves a different problem. This table helps you decide which one fits your situation.
| Option | Best for | Main advantage | Main limitation |
|---|---|---|---|
| VPC Peering | Small number of VPCs needing full bilateral access | Simple, low-cost, low-latency, no additional service to manage | Non-transitive; does not scale past a handful of VPCs |
| Transit Gateway | Many VPCs, hub-and-spoke, or transitive routing | Centralized routing, scales to thousands of VPCs, supports complex topologies | Hourly attachment charges and per-GB processing fees add up at scale |
| PrivateLink | Exposing a specific service to other VPCs or accounts | No CIDR overlap requirement; exposes only the endpoint, not the full network | One-directional (consumer reaches provider); requires an NLB on the provider side |
| Shared VPC | Multiple accounts sharing common network infrastructure | Single VPC managed centrally via AWS RAM; no peering connections needed | All accounts share the same address space; less network-level isolation |
| Site-to-Site VPN / Direct Connect | Connecting AWS VPCs to on-premises networks | Extends your private network to AWS; supports existing network infrastructure | Not designed for VPC-to-VPC connectivity; higher cost and complexity for that use case |
Decision shortcut: Use VPC peering when you have fewer than 5 VPCs and need full private network access between them. Switch to Transit Gateway when you need more than 5 VPCs, transitive routing, or centralized control. Use PrivateLink when a VPC needs to reach a specific service, not a full network.
CIDR overlap: the problem with no workaround
Both VPCs must use non-overlapping CIDR blocks. If VPC A is 10.0.0.0/16 and VPC B is also 10.0.0.0/16, AWS cannot build routing rules that distinguish traffic destined for one from the other. The peering request is rejected.
This becomes a real problem in large organizations where teams created VPCs independently and all used the default 10.0.0.0/16. Planning your CIDR allocation strategy before you scale is worth the effort. A common approach is to assign each VPC a /16 from non-overlapping ranges: 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16, and so on.
No workaround for overlapping CIDRs. If you are already in this situation, your options are: re-IP one VPC (painful but possible), use PrivateLink for service-level access (does not require non-overlapping CIDRs), or use a NAT-based solution (complex, not recommended). VPC peering is not an option.
How to set up VPC peering
The setup has five steps. The peering connection itself is step one. The route and security group updates are what actually make traffic flow.
# Step 1: Create the peering connection request from VPC A
# For cross-region, add: --peer-region us-west-2
# For cross-account, add: --peer-owner-id 123456789012
aws ec2 create-vpc-peering-connection \
--vpc-id vpc-aaaaaaaaa \
--peer-vpc-id vpc-bbbbbbbbb
# The output returns a VpcPeeringConnectionId like: pcx-0abc123def456789a
# Step 2: Accept the connection (same account)
# For cross-account, run this command in the accepting account
aws ec2 accept-vpc-peering-connection \
--vpc-peering-connection-id pcx-0abc123def456789a
# Step 3: Add a route in VPC A's route table pointing to VPC B's CIDR
aws ec2 create-route \
--route-table-id rtb-vpc-a \
--destination-cidr-block 10.2.0.0/16 \
--vpc-peering-connection-id pcx-0abc123def456789a
# Step 4: Add a route in VPC B's route table pointing to VPC A's CIDR
aws ec2 create-route \
--route-table-id rtb-vpc-b \
--destination-cidr-block 10.1.0.0/16 \
--vpc-peering-connection-id pcx-0abc123def456789a
# Step 5 (optional): Enable private DNS resolution across the peering
# Must be enabled on both sides for cross-VPC hostname resolution
aws ec2 modify-vpc-peering-connection-options \
--vpc-peering-connection-id pcx-0abc123def456789a \
--requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true \
--accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=trueAfter these commands, update the security groups on any instances that need to accept cross-VPC traffic. Add an inbound rule allowing traffic from the remote VPC’s CIDR block on the required ports. Without this, the routes exist but packets are dropped at the security group layer.
Check which route table your subnet actually uses. If your subnets use custom route tables (not the VPC’s main table), those are the ones that need the peering route. Adding a route to the main route table has no effect on subnets associated with a custom table.
Cost considerations
| Peering type | Data transfer cost | Notes |
|---|---|---|
| Same-AZ | Free | Traffic between instances in the same Availability Zone has no data transfer charge |
| Same-region, cross-AZ | Standard cross-AZ rates apply | Same rates as any other cross-AZ data transfer in the region |
| Same-region, cross-account | Standard cross-AZ rates apply | The accepting account receives the peering request and approves it |
| Cross-region | Inter-region data transfer rates (higher) | No edge routing or Gateway Load Balancer support; higher latency |
There is no hourly charge for the peering connection itself. You pay only for data transferred. Check the current AWS data transfer pricing page for exact rates, as they vary by region and change over time.
Common mistakes and how to avoid them
Forgetting to add routes on both sides. The peering connection alone does not route traffic. Both VPCs need route table entries pointing to the peering connection for the other VPC’s CIDR. If you add the route only in VPC A, instances in A can reach B but B cannot reach A. This asymmetric failure looks like a one-directional network problem.
Expecting transitive routing to work. Teams new to peering often plan a hub VPC that connects to all other VPCs and forwards traffic between them. AWS blocks this at the network level. There is no route you can add to make it work. If you need transitive routing, switch to Transit Gateway before you build around an assumption that will not hold.
Not planning CIDR ranges in advance. Discovering that two VPCs have overlapping CIDRs when you need to peer them is expensive to fix. The only real option is to re-IP a VPC, which requires migrating workloads. Allocate non-overlapping CIDRs before you create VPCs in production.
Forgetting to update security groups. Route tables route; security groups allow or deny. A correct route with a missing security group rule means traffic is routed to the right place but dropped there. Both layers must be updated. If your subnets use custom NACLs, check those too. NACLs are stateless and require explicit inbound and outbound rules.
Not enabling DNS resolution for private hostnames. If you need VPC A instances to resolve the private DNS names of VPC B instances (e.g.,
ip-10-2-0-5.ec2.internal), you must enable the DNS resolution option on the peering connection for both sides. Without this, private hostnames do not resolve across the peering, and services that rely on DNS-based discovery will fail silently or fall back to public IPs.Updating only the main route table. If your subnets use custom route tables, those are the ones that need the peering route. Adding a route to the main route table has no effect on subnets associated with a custom table. Identify which route table is associated with each affected subnet before making changes.
Troubleshooting checklist
For deeper diagnosis, see the VPC connectivity troubleshooting guide. These are the most common peering-specific failure patterns:
Peering connection is active but traffic fails
- Check that both VPCs have route table entries pointing to the peering connection for the remote CIDR.
- Check that the route is in the route table used by the affected subnet, not just the main route table.
- Verify the security group on the target instance allows inbound traffic from the remote VPC’s CIDR on the correct port.
- Check network ACLs on both subnets. NACLs are stateless, so both inbound and outbound rules must allow the traffic.
One side can connect but the other cannot
- This is almost always a missing route on the side that cannot connect. Check that both VPCs have routes in both directions.
- Also check security groups on both instances. Each needs inbound rules allowing traffic from the other VPC.
DNS names do not resolve across the peering
- Confirm the DNS resolution option is enabled on the peering connection. It must be enabled on both the requester and accepter side.
- Confirm that DNS hostnames and DNS resolution are enabled on both VPCs (VPC settings, not just peering options).
- If using private hosted zones, verify the zones are associated with the correct VPCs.
Cross-account peering is stuck in pending state
- The accepting account must log in and accept the request. It does not auto-accept across accounts.
- Peering requests expire after 7 days if not accepted.
- Confirm the accepting account’s IAM user or role has the
ec2:AcceptVpcPeeringConnectionpermission. - Verify the requester specified the correct account ID and VPC ID for the peer.
Route exists but traffic is still blocked
- Run VPC Reachability Analyzer in the AWS Console to trace the exact path and identify which layer is dropping traffic.
- Check for host-level firewalls (iptables, Windows Firewall) on the instance. These operate below the AWS security layer and are not visible in VPC settings.
- Confirm the instance is actually in the subnet associated with the route table you updated.
Summary
- VPC peering connects two VPCs privately over the AWS backbone. Traffic never touches the public internet.
- Peering is non-transitive: A peers with B, B peers with C, but A cannot reach C through B. Each pair needs its own direct connection.
- VPCs must have non-overlapping CIDR blocks. There is no workaround. Plan your CIDR ranges before you scale.
- Three things are required after creating the connection: route table updates on both sides, security group updates on target instances, and (optionally) DNS resolution settings.
- Use peering for fewer than 5 VPCs with broad private connectivity needs. Switch to Transit Gateway when you need transitive routing, more VPCs, or centralized control. Use PrivateLink for service-level access without full network exposure.
- Cross-account peering requires manual acceptance in the accepting account. Cross-region peering works but incurs higher data transfer costs.
Frequently asked questions
Is VPC peering transitive? Can I route through a peered VPC to reach a third VPC?
No. VPC peering is explicitly non-transitive. If VPC A peers with VPC B and VPC B peers with VPC C, traffic from VPC A cannot reach VPC C through VPC B. AWS blocks it at the network level. You cannot work around it with custom routes. Each pair of VPCs that needs to communicate requires its own direct peering connection. For hub-and-spoke or mesh topologies beyond a handful of VPCs, use AWS Transit Gateway instead.
Can peered VPCs have overlapping CIDR blocks?
No. The two VPCs must have non-overlapping CIDRs. If both use 10.0.0.0/16, AWS cannot build routing rules that distinguish between them and peering will be rejected. There is no workaround. Plan your CIDR ranges before you scale to multiple VPCs. If you are already stuck with overlapping CIDRs, consider AWS PrivateLink for service-to-service access instead.
Does VPC peering traffic travel over the public internet?
No. VPC peering traffic stays entirely on the AWS backbone network. It never touches the public internet. This means lower latency than internet routing, no exposure to internet threats, and no need for public IP addresses on your instances.
Can I peer VPCs across AWS accounts or regions?
Yes to both. For cross-account peering, the requesting account sends an invitation specifying the other account ID and VPC ID, and the accepting account approves it. For cross-region peering, specify the peer-region parameter when creating the connection. Cross-region peering incurs inter-region data transfer charges and has slightly higher latency, but works the same way once established.
When should I use Transit Gateway or PrivateLink instead of VPC peering?
Use Transit Gateway when you have more than 4-5 VPCs that all need to reach each other, or when you need transitive routing. Peering requires a direct connection for every pair, which becomes a management burden at scale. Use PrivateLink when one VPC only needs to reach a specific service in another VPC, not the full network. PrivateLink exposes a single endpoint, does not require non-overlapping CIDRs, and works well for producer/consumer access patterns.