VPC peering is a private network connection between two virtual private clouds that lets resources in each network reach the other using private IP addresses, as if they shared one network. In cloud networking, the traffic stays on the provider’s internal backbone and never crosses the public internet, and no gateway, VPN tunnel or separate appliance sits in the path.
Every major cloud platform offers the concept under a similar name: VPC peering on AWS and Google Cloud, VNet peering on Azure. The defining properties are the same everywhere: the connection is one-to-one, it is non-transitive, and the two address ranges must not overlap.
How VPC peering connects two networks
A peering connection is established through a request and accept handshake. The owner of one VPC requests the connection, the owner of the other accepts it, and both can belong to different accounts or projects. On AWS, peering also works across regions; on Google Cloud, a VPC network is global, so peering joins all regional subnets at once.
Creating the connection alone does not move any packets. On AWS, each side must add route table entries that send the remote CIDR block to the peering connection, and security groups or firewall rules must allow the traffic. Google Cloud and Azure exchange subnet routes automatically, but firewall rules still decide what is permitted.
The data path is direct. There is no bandwidth bottleneck at a gateway and no single point of failure, because the provider implements peering in its software-defined network fabric. Latency is therefore the same as between instances inside one VPC in the same region.
Rules and limits that shape a peering design
VPC peering has a small number of strict rules that decide whether it fits a design. The most important is non-transitivity: if VPC A peers with B and B peers with C, A cannot reach C through B.
| Constraint | What it means | Design consequence |
|---|---|---|
| Non-transitive routing | Traffic cannot hop through a middle VPC | Every pair that must talk needs its own peering |
| No overlapping CIDRs | Address ranges must be distinct | IP address planning must happen early |
| No edge-to-edge routing | A peer cannot use the other side’s gateways | No shared internet, NAT or VPN egress |
| Per-VPC connection quota | Default limits per VPC, often around 50 | Full mesh stops scaling beyond small numbers |
| One connection per pair | Only one peering between the same two VPCs | Redundancy is built into the fabric, not added |
The limit on edge-to-edge routing often surprises teams. A spoke VPC cannot send traffic to the internet through a peer’s Cloud NAT or internet gateway, and it cannot reach an on-premises network over the peer’s VPN gateway. Those patterns require a hub service instead.
Because a full mesh of n VPCs needs n(n-1)/2 connections, ten VPCs already require 45 peerings with matching routes on both ends. This growth is the main reason large estates move to a hub-and-spoke design.
VPC peering compared with other private connectivity options
VPC peering is one of several ways to connect networks privately. It is the simplest and cheapest option for a few VPCs, while other services trade simplicity for scale or tighter exposure.
| Option | Topology | Transitive | Best fit |
|---|---|---|---|
| VPC peering | One-to-one | No | A few VPCs with full mutual access |
| Transit gateway | Hub and spoke | Yes | Dozens to thousands of VPCs and on-premises links |
| Private endpoint | Consumer to one service | Not applicable | Exposing a single service without network merging |
| VPN gateway | Site to cloud | Through the hub | Encrypted links over the internet |
| Cloud interconnect | Dedicated physical link | Through the hub | High-bandwidth on-premises connectivity |
The decisive distinction is scope of exposure. Peering joins entire networks at layer 3, so every subnet becomes reachable unless firewall rules restrict it. A private endpoint exposes only one service, which suits partners or SaaS providers who should not see each other’s address space at all.
Cost, security and operations
Peering connections usually carry no hourly charge, but data transfer is billed. Traffic within the same Availability Zone is often free or very cheap, while traffic across zones or regions is charged per gigabyte in each direction, depending on the provider and region pair. A transit gateway adds a per-attachment and per-gigabyte processing fee, which is why peering stays attractive for high-volume flows between two VPCs.
From a security perspective, peering removes internet exposure but widens the trust boundary. Security groups can reference security groups in a peered VPC in the same region on AWS, which allows precise rules. VPC flow logs on both sides help verify that only intended traffic crosses the connection.
| Situation | Recommended choice | Reason |
|---|---|---|
| Two to five VPCs, full access needed | VPC peering | Lowest cost and no gateway to manage |
| Many VPCs plus on-premises sites | Transit gateway | Transitive routing and central control |
| Partner needs one API only | Private endpoint | Exposes a service, not a network |
| Overlapping address ranges | Private endpoint or NAT-based design | Peering is impossible with overlap |
Common mistakes with VPC peering
Most peering problems are routing or planning errors rather than service failures. The following mistakes appear repeatedly in real deployments.
- Missing return route: a route is added on one side only, so packets arrive but replies are dropped.
- Overlapping CIDR blocks chosen by teams that never coordinated, which makes peering impossible later.
- Assuming transitivity and expecting a spoke to reach another spoke through a shared VPC.
- Forgetting DNS settings, so private hostnames resolve to public addresses instead of private ones.
- Overly broad firewall rules that open the whole peer CIDR when only one port is required.
A disciplined IP address management plan, with non-overlapping ranges reserved per account and region, prevents the hardest of these problems because overlapping ranges cannot be fixed without renumbering.
The simple explanation
Think of two office buildings owned by related companies. VPC peering is like building a private corridor between them, so staff can walk from one to the other without going out onto the street.
The corridor only joins those two buildings. If a third building connects to one of them, people still cannot pass through to the other side; each pair needs its own corridor. It also only works if the two buildings do not use the same room numbers, otherwise nobody would know which room is meant.
How it is used in practice
A software company runs its customer application in one VPC with the range 10.10.0.0/16 and a shared analytics platform in another VPC with 10.20.0.0/16, both in the same region but in separate accounts. The application must send event data to a Kafka cluster in the analytics VPC, roughly several terabytes per month.
The network team creates a peering connection, adds a route for 10.20.0.0/16 in the application route tables and a route for 10.10.0.0/16 on the analytics side, and allows only the Kafka broker ports in the security groups. Private DNS resolution is enabled across the connection. The result is private, low-latency traffic without any gateway charges, and the team documents that a third VPC will require a transit gateway rather than more peerings.