AWS VPC Peering: A Complete Technical Guide for Solutions Architects
Everything you need to know about VPC Peering from foundational concepts to exam traps to real-world design decisions
There is a certain class of AWS topic that exam candidates underestimate precisely because it sounds simple on the surface. VPC Peering is one of them. The concept connect two VPCs so they can communicate privately is easy enough to state. The operational details, the behavioral edge cases, and the architectural consequences of its limitations are where most candidates stumble, and where most real-world implementations go wrong.
This guide covers VPC Peering comprehensively: what it is, how it behaves at the network level, where it breaks down, and how to think about it against the backdrop of alternatives like Transit Gateway. Whether you are preparing for the AWS Solutions Architect Associate exam or designing production infrastructure, this is the reference you want.
Hi — this is Pushpit from CloudOdyssey . Each week, I write about Cloud, DevOps, Systems Design deep dives and community update around it. If you have not subscribed yet, you can subscribe here.
What VPC Peering Actually Is
A VPC Peering connection is a networking construct that establishes a direct, private network route between two VPCs. Traffic routed through a peering connection travels within the AWS network it does not traverse the public internet, does not require an internet gateway, and does not require a VPN or Direct Connect circuit.
At its core, a peering connection is a one-to-one relationship. One peering connection links exactly two VPCs. You cannot attach additional VPCs to an existing connection, and you cannot use a peering connection as a conduit to reach a third VPC. That limitation non-transitivity is arguably the most architecturally significant characteristic of VPC Peering, and we will return to it in detail.
Internally, AWS represents a peering connection as a logical object called a VPC Peering Connection, identified by a resource ID in the format pcx-xxxxxxxxxxxxxxxxx. This object appears in both VPCs’ route tables as a valid route target, and it is what you point traffic at when configuring routes. Think of it as a virtual cable between two specific VPCs: it exists, it has identity, and routing decisions reference it explicitly.
Supported Configurations
VPC Peering is flexible in terms of where the two VPCs live, but it is important to understand the distinctions between configurations because they carry different behavioral implications.
Same-region peering is the most common configuration. Both VPCs exist in the same AWS Region and, optionally, within the same AWS account. Same-region peering unlocks features that cross-region peering does not support, most notably the ability to reference Security Groups by ID across peered VPCs a topic covered in depth in the security section below.
Cross-region peering connects VPCs in different AWS Regions. This is fully supported and has been a generally available feature since 2017. The networking behavior differs in one meaningful respect: traffic between cross-region peered VPCs travels over the AWS global backbone network rather than any regional infrastructure. It remains private and encrypted, but the physical path crosses AWS’s inter-region fiber links. This matters for latency (which will be higher than same-region peering), for data transfer pricing (inter-region data transfer rates apply), and for compliance requirements (data is physically moving between geographic locations).
Cross-account peering works in both same-region and cross-region configurations. One account initiates the peering request, and the other account must explicitly accept it. This acceptance model is important from a security governance standpoint: VPCs cannot be peered without bilateral agreement between the account owners. There is no way to force a peering connection on an account that has not accepted it.
Combining these dimensions, the full matrix of supported configurations is: same-account same-region, same-account cross-region, cross-account same-region, and cross-account cross-region. All four are valid. The peering mechanism itself is the same across all of them; what changes are the behavioral nuances noted above.
Network Traffic Behavior
When two VPCs are connected via a peering connection, traffic between them behaves as though the VPCs are on the same private network from a routing standpoint. There is no NAT involved. Source and destination IP addresses are preserved end to end. A resource in VPCA sending traffic to a resource in VPCB sees the private IP address of the destination, and the destination sees the private IP address of the source.
This is meaningfully different from configurations that involve internet gateways, NAT gateways, or public endpoints. VPC Peering provides true private IP connectivity.
For cross-region peering specifically, the AWS documentation is explicit: traffic uses the AWS global network and is encrypted in transit. It does not leave the AWS infrastructure to traverse the public internet. This is an exam-relevant distinction. When a question asks whether cross-region VPC Peering traffic is encrypted or whether it transits the internet, the correct answers are yes (encrypted) and no (does not traverse the internet), respectively.
One thing VPC Peering does not do is extend routing beyond the peered VPCs. Resources in a peered VPC cannot, for example, reach your on-premises network through your VGW (Virtual Private Gateway) by routing through the peering connection. Each connectivity relationship must be direct. This is part of the same non-transitive principle that governs VPC-to-VPC traffic.
DNS Resolution Across Peered VPCs
By default, enabling a VPC peering connection does not change how DNS works. If a resource in VPCA queries the public hostname of a resource in VPCB, the DNS response returns the public IP address even if there is a peering connection in place. Traffic would then flow via the internet rather than through the private peering path, which is almost certainly not what you want.
To fix this, VPC Peering supports an optional setting called DNS Resolution Support (sometimes called “Enabler for DNS resolution from accepter/requester VPC”). When enabled on both sides of the peering connection, public DNS hostnames for instances in a peered VPC resolve to the private IP address of those instances when queried from within the peer VPC.
This setting must be explicitly enabled. It is not on by default. And it must be configured at both ends of the peering connection enabling it only on the requester side does not affect DNS resolution for resources in the accepter VPC, and vice versa.
For exam purposes, the key scenario is this: you have two VPCs connected by a peering connection, and you want resources to communicate via private IP without hardcoding IP addresses. The answer is to enable DNS resolution on both sides so that DNS hostnames resolve to private IPs across the peering boundary.
Security Behavior: Groups, NACLs, and Peer References
A VPC Peering connection does not bypass any of your existing security controls. Both Network Access Control Lists (NACLs) and Security Groups apply to traffic traversing a peering connection, exactly as they apply to any other traffic within a VPC. This is an important conceptual point: peering creates a path, it does not grant access. You must explicitly allow the desired traffic in your security controls.
NACLs operate at the subnet level and are stateless. If you have NACLs configured on subnets in either VPC, you need to ensure that both inbound and outbound rules permit the traffic you intend to allow. The remote VPC’s CIDR block is the relevant IP range for NACL rules.
Security Groups operate at the instance level and are stateful, which means return traffic for allowed connections is automatically permitted. When allowing inbound traffic from a peered VPC, the straightforward approach is to specify the remote VPC’s CIDR range in the inbound rule. This works in all configurations.
However, same-region peering unlocks an additional and more precise capability: Security Group cross-reference. In a same-region peering configuration, you can specify a Security Group ID from the peered VPC as the source or destination in a Security Group rule, rather than a CIDR block. This means you can write a rule that says “allow inbound port 5432 from Security Group sg-0abc123 in VPCB” and that rule will apply to all instances that are members of that specific Security Group, regardless of their IP addresses.
This is operationally cleaner than CIDR-based rules for several reasons. It avoids the need to track IP addresses or CIDR ranges. It is more precise you are referencing a specific security boundary, not a broad IP range. And it automatically applies as instances are added to or removed from the referenced Security Group.
Cross-region peering does not support Security Group cross-reference. In that configuration, you must fall back to CIDR-based rules.
Routing Requirements: Both Sides, Always
This is the area where most implementation errors occur, and it is a reliable source of exam questions. A VPC Peering connection alone does not route any traffic. It creates the logical path, but traffic will not actually traverse it until you configure route tables on both sides to direct traffic toward the peering connection.
The requirement is bilateral. The route table in VPCA must contain a route that sends traffic destined for VPCB’s CIDR block to the peering connection object (pcx-xxxxxxxxxxxxxxxxx). Simultaneously, the route table in VPCB must contain a route that sends traffic destined for VPCA’s CIDR block to the same peering connection object. If either side is missing its route, traffic in that direction fails. The connection exists, but packets have nowhere to go.
The route table entries look something like this in concept:
In VPCA’s route table:
Destination:
10.17.0.0/16(VPCB’s CIDR) → Target:pcx-ab000
In VPCB’s route table:
Destination:
10.16.0.0/16(VPCA’s CIDR) → Target:pcx-ab000
The peering connection object (pcx-ab000 in this example) is what AWS calls the peer gateway object. When you add a route that targets a VPC Peering connection, you are telling the routing engine: “send traffic matching this destination prefix out through this specific peering connection.” The pcx object is the logical gateway, analogous to the way an Internet Gateway or NAT Gateway is a target in other route table configurations.
If a VPC has multiple subnets with separate route tables, each subnet’s route table that needs access to the peered VPC must be updated independently. A route in one subnet’s table does not propagate to other subnets automatically.
For cross-account peering, the same logic applies. Each account manages its own route tables and must configure routes independently. Neither account can add routes to the other’s route tables that would be a significant security boundary violation, and AWS does not permit it.
Non-Transitive Peering: The Core Architectural Constraint
This is the most important limitation of VPC Peering, and it is worth spending significant time on it because it fundamentally shapes how you design multi-VPC architectures.
Consider the architecture illustrated in the diagram below:
In this diagram, VPCA (10.16.0.0/16) is peered with VPCB (10.17.0.0/16) via a peering connection labeled pcx-ab000. VPCB is separately peered with VPCC (10.18.0.0/16) via pcx-bc000. The route tables on both sides of each peering connection are configured, and the CIDR ranges for the peer are available at each end.
The question is: can VPCA communicate with VPCC?
The answer is no, and it will never work regardless of how you configure routing. VPC Peering is non-transitive. The existence of a VPCA↔VPCB connection and a VPCB↔VPCC connection does not create any kind of path between VPCA and VPCC. Traffic originating in VPCA that is destined for VPCC’s 10.18.0.0/16 range has no valid route VPCA has no route table entry for that prefix, and even if you tried to add one pointing at pcx-ab000, VPCB is not configured to forward that traffic onward to VPCC.
The diagram makes this explicit: “No VPC Peer between A and C — A→B→C doesn’t work, peering is not Transitive.” The crossed-out line between VPCA and VPCC and the blocked traffic indicator between them visually reinforce what the routing logic confirms: this path does not exist.
The diagram also illustrates another key point: the route tables at both sides of the peering connection include the specific remote CIDRs (172.16.0.0, 172.16.1.0, 172.16.2.0 are shown as example subnet routes being directed toward the peer gateway object). This reinforces that routing is explicit, bilateral, and scoped to the direct peers only.
For VPCA and VPCC to communicate, you need one of two things: a direct peering connection between them, or a different connectivity solution altogether (Transit Gateway, which we discuss shortly).
If you have a hub-and-spoke architecture with a central shared services VPC and 10 spoke VPCs, all of which need to communicate with the hub, you need 10 peering connections one from each spoke to the hub. If all 10 spokes also need to communicate with each other, you need an additional 45 connections (the number of edges in a complete graph of 10 nodes). At scale, this becomes unmanageable. That scaling problem is precisely what Transit Gateway was designed to solve.
CIDR Overlap: The Other Hard Constraint
VPC Peering cannot be created between two VPCs if their CIDR blocks overlap. This is not a soft limitation or a configuration option it is a hard technical requirement enforced by the service. The AWS console and API will reject the peering request if the CIDRs overlap.
The reason is straightforward: routing decisions are based on IP addresses, and overlapping CIDRs would create ambiguity. If VPCA has the range 10.0.0.0/16 and VPCB also has 10.0.0.0/16, a packet destined for 10.0.1.50 could belong to either VPC. There is no way to route correctly.
This constraint has a practical implication that is easy to underestimate: your CIDR planning decisions made at VPC creation time are permanent. VPCs cannot have their primary CIDR block changed. You can add secondary CIDR blocks to an existing VPC, but you cannot remove or modify the primary one. If two VPCs were created with overlapping ranges which is easy to do when each was created in isolation without a centralized IP addressing plan they can never be peered.
As the diagram notes, the best practice is to “NEVER use the same address ranges in multiple VPCs.” For organizations managing multiple accounts and regions, this requires a deliberate IP address management (IPAM) strategy from the outset. AWS has an IPAM service specifically for this purpose. The point stands regardless: overlapping CIDRs create permanent peering incompatibility, and fixing it requires rebuilding VPCs.
For the exam, if you see a scenario where VPC Peering is described as failing or unavailable, CIDR overlap is one of the first things to check. The other is missing routes, which we covered above.
When to Use VPC Peering and When Not To
VPC Peering is the right tool in specific circumstances. Understanding those circumstances and the circumstances where it is wrong is essential both for real infrastructure design and for exam scenario questions.
Use VPC Peering when:
The architecture involves a small number of VPCs (typically fewer than five to ten) that need point-to-point connectivity. When you have two VPCs that need to share data a shared services VPC and an application VPC, for example peering is the appropriate, lowest-complexity solution. There is no additional infrastructure to manage, no routing bottleneck, and traffic takes the most direct path possible.
Peering is also appropriate when you specifically need same-region Security Group cross-referencing, since Transit Gateway does not support that feature. If your security model relies on referencing Security Group IDs across VPCs, peering in the same region is the only option.
Peering is appropriate when data transfer costs matter significantly. VPC Peering within the same region has lower data transfer costs than Transit Gateway for the same traffic. If you are moving large volumes of data between two specific VPCs in the same region, peering will be cheaper per GB than Transit Gateway attachment.
Do not use VPC Peering when:
You have more than a handful of VPCs that all need to communicate with each other. The combinatorial explosion of required peering connections makes this approach unmanageable at scale. Ten VPCs in a full mesh requires 45 connections; 20 VPCs requires 190. Each connection requires bilateral route table management. The operational overhead becomes prohibitive.
Do not use VPC Peering when you need centralized network control or inspection. Because there is no central transit point in a mesh of peering connections, you cannot easily insert a firewall or inspection layer between VPCs. Transit Gateway, combined with a centralized security VPC, enables that architecture.
Do not use VPC Peering when your VPCs have overlapping CIDRs and you need connectivity VPC Peering is simply unavailable in that case. The solutions are VPC Peering with PrivateLink (for service-specific access) or Transit Gateway with NAT.
VPC Peering vs. Transit Gateway: A Practical Comparison
Transit Gateway (TGW) is the most common alternative to VPC Peering for multi-VPC connectivity. The choice between them is a recurring theme in AWS Solutions Architect exam questions, and it is a real architectural decision point.
Architecture model: VPC Peering creates a decentralized mesh of point-to-point connections. Transit Gateway creates a centralized hub through which all VPC-to-VPC traffic is routed. All VPCs attach to the TGW, and the TGW’s route tables control which VPCs can reach which others.
Scalability: VPC Peering scales poorly with the number of VPCs (O(n²) connections for a full mesh). Transit Gateway is designed for scale a single TGW can have thousands of VPC attachments, and adding a new VPC to the network requires one attachment and route table update rather than N new peering connections.
Routing control: Transit Gateway provides centralized, fine-grained routing control through its route tables. You can segment VPCs into route domains, control which VPCs can reach each other, and insert inspection appliances in the traffic path. VPC Peering offers no centralized routing control.
Cost model: VPC Peering within the same region has no per-attachment cost you pay only for data transfer. Transit Gateway charges both a per-attachment-hour fee and a per-GB data processing fee on top of data transfer charges. For high-throughput traffic between a small number of VPCs, peering is typically cheaper. For complex multi-VPC networks with many connections, the simplicity of TGW offsets its higher cost.
Transitive routing: Transit Gateway supports transitive routing by design. Any VPC attached to a TGW can reach any other attached VPC if the route tables permit it. This is the fundamental capability that VPC Peering lacks.
On-premises integration: Transit Gateway can connect to on-premises networks via VPN or Direct Connect, and those connections can reach all attached VPCs. VPC Peering cannot propagate routes to or from on-premises networks.
Same-region Security Group references: Only available with VPC Peering; not supported through Transit Gateway.
The exam scenario where this choice comes up most often: you have a growing number of VPCs and are asked how to connect them. If the number is large or the question mentions centralized management, the answer is Transit Gateway. If the question involves two VPCs, same-region Security Group references, or minimizing cost for high-throughput point-to-point traffic, the answer is VPC Peering.
Common Exam Traps
A handful of scenarios appear repeatedly in exam questions specifically to test whether candidates understand the nuances of VPC Peering.
The transitive routing trap. A question describes VPCA peered with VPCB, and VPCB peered with VPCC. It asks whether VPCA can reach VPCC, or asks what change is needed to enable that communication. Candidates who do not understand non-transitivity may answer “update the route tables” but no route table configuration can make transitive peering work. The correct answer is either establish a direct peering connection between VPCA and VPCC, or replace the architecture with Transit Gateway.
The missing route trap. A question describes a peering connection that has been created and accepted, but traffic is still not flowing. The answer is almost always missing route table entries. Peering connection creation does not add routes that is always a separate, manual step. Candidates who conflate “connection established” with “routing configured” will get this wrong.
The DNS resolution trap. A question describes an architecture where resources in peered VPCs communicate using DNS hostnames, but connections are failing or going over the internet. The answer is to enable DNS resolution support on the peering connection. If that option is not enabled, DNS hostnames resolve to public IPs even across a peering connection.
The CIDR overlap trap. A question asks why a VPC Peering connection cannot be created, or presents a scenario where two VPCs both use 10.0.0.0/16. CIDR overlap is the reason, and the fix is either to redesign the IP addressing scheme (which requires recreating VPCs) or to use PrivateLink for specific service access. Candidates who do not know this constraint will waste time looking for other explanations.
The cross-region Security Group trap. A question describes a cross-region peering scenario and asks whether Security Groups can reference peer Security Group IDs. The answer is no that feature is available only for same-region peering. In cross-region configurations, CIDR ranges are the only option for Security Group rules referencing peered VPC resources.
Real-World Implementation Considerations
For engineers designing actual infrastructure rather than answering exam questions, a few additional operational points are worth noting.
IP address planning is foundational. The CIDR overlap constraint means that VPC Peering requires coordinated IP address management across all VPCs in your network from the very beginning. Organizations that grow organically often find themselves with overlapping CIDRs that block peering. Use AWS IPAM or a manual address plan to assign non-overlapping ranges to all VPCs in your environment before they are created. A common approach is to allocate a /8 or /10 to the organization and carve /16 or /20 blocks to individual VPCs systematically.
Route table management at scale. Even with a modest number of peering connections, manually managing route tables becomes error-prone. Infrastructure-as-code tools (Terraform, CloudFormation) are essential for maintaining consistency. A missing route in one subnet’s table while another subnet’s table is correctly configured creates debugging headaches that are disproportionate to the actual problem.
Peering does not span VPC endpoints. If VPCA has a VPC Interface Endpoint for S3 or another service, resources in a peered VPCB cannot use that endpoint. Each VPC must have its own endpoints, or you must use a centralized endpoint architecture via Transit Gateway and endpoint services.
Cross-account peering and resource sharing. In multi-account organizations, peering is one mechanism for cross-account resource access, but it is not the only one. AWS Resource Access Manager (RAM) can share specific resources (like subnets) across accounts without requiring full VPC-level connectivity. For some use cases, that is a more appropriate scope of access than a full peering connection.
Monitoring peered connections. VPC Flow Logs capture traffic on peering connections, but the log records for peered traffic appear in the flow logs of the VPC where the traffic is captured. If you need end-to-end visibility of cross-VPC traffic, you may need to enable flow logs in both VPCs and correlate the records. Each side only sees the traffic as it relates to its own VPC.
Summary
VPC Peering is a foundational AWS networking service that provides private, encrypted connectivity between pairs of VPCs. It works across regions and accounts, requires no additional infrastructure, and preserves source and destination IP addresses end to end. For the right use case a manageable number of VPCs that need point-to-point private connectivity it is the simplest and most cost-effective solution available.
Its limitations define its appropriate scope. Non-transitive routing means every communication path requires its own direct peering connection. CIDR overlap makes peering permanently impossible between VPCs with conflicting address ranges. The combinatorial growth of connections in mesh topologies makes peering impractical beyond a handful of VPCs. And the lack of centralized routing control means it cannot serve as the foundation for network security inspection or segmentation architectures.
Transit Gateway fills the gap where VPC Peering falls short: centralized routing, transitive connectivity, and scalable management across many VPCs and on-premises connections. The choice between them reduces to network size, topology complexity, cost sensitivity, and specific feature requirements (like same-region Security Group references, which only peering supports).
For the Solutions Architect Associate exam, the critical concepts to internalize are: peering is non-transitive, routes must be configured bilaterally, DNS resolution must be explicitly enabled, CIDR blocks cannot overlap, and cross-region peering encrypts traffic over the AWS global network. Understanding not just the facts but the architectural implications of these constraints is what separates candidates who pass the exam from those who also know how to design systems that hold up in production.
This article covers AWS VPC Peering as of 2024–2025. AWS service features evolve; always verify current behavior in the official AWS documentation.