Kentipedia

What is VPC Peering?

There’s a good probability that you’ve heard about VPC peering if you build and manage apps on public clouds like GCP or AWS. This article explains what VPC peering is, how it works, and how Kentik’s network intelligence platform may be used to reduce the complicated problems that may arise when using VPC peering.

VPC peering is a technique for securely connecting two or more virtual private clouds, or VPCs. According to Amazon, a VPC peering connection is “a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses.” Once connected by a VPC peering connection, instances in either VPC can communicate with each other just as if they were on the same network.

In modern network architectures that include multiple clouds, VPC peering offers important security and performance benefits. However, it’s important to ensure that you properly observe and manage VPC peering configurations in order to avoid potential network performance issues.

---

Kentik in brief: Kentik is a network intelligence platform that provides visibility for VPC peering by combining cloud flow logs, routing context, and synthetic performance testing. See which subnets and workloads communicate across peerings, detect unexpected cross‑environment access, validate route and security policy changes, and troubleshoot latency and packet loss along the path between VPCs.

---

How VPC Peering Works: Multi-VPC Connections

A VPC is an isolated environment within a public cloud that allows organizations to host resources in that cloud without directly exposing them to the public Internet. As such, a VPC lets you set up a private network within a public cloud. By isolating workloads on a private network, VPCs provide an added layer of security.

If all of your workloads run within a single cloud environment, you might only need one VPC/VNet to host the resources that require private connectivity.

But many organizations end up with multiple VPCs (or VNets) across accounts/projects and regions, often to separate environments (prod vs. dev), teams, or applications. That’s where network peering comes in: it provides private connectivity between two virtual networks within the same cloud provider.

For example, in AWS, a VPC peering connection links two VPCs so you can route traffic between them using private IPv4/IPv6 addresses, including across AWS accounts and even across regions, so instances can communicate as if they were on the same network.

In multi-cloud architectures, peering is typically provider-specific (AWS VPC peering, Google Cloud VPC Network Peering, Azure VNet peering). To connect networks between different cloud providers, teams usually use VPN or dedicated interconnect options rather than peering.

Hi. I'm going to show you one way that investigating with Kentik can make you more productive. Denials related to security groups and access control lists can cause incidents, but they can also create mundane requests from developers that a pain to investigate. The time it takes me to unblock these really adds up because my team is serving many, many development teams. I have a ticket here from a developer. My application server at this IP can't access this shared storage server. Fix it. A lot of times when traffic is getting denied, more than one developer is affected, so I'm going to search the whole CIDR block that this IP is in and start there. I can quickly see that I'm dealing with AWS here. And it's in US East, or US West. I'll go straight away to the Data Explorer to look at this in more detail. The Data Explorer is my main interface for querying and visualizing all the enriched flow data that's available in the Kentik Data Engine. In AWS that can be flow data from my VPCs or from my transit gateways, which give me a better ability to analyze and detect patterns across multiple VPCs so that I can find performance impacting issues that span multiple environments. I'm going to start building my query to understand what's going on, and I want to start with what's happening right now. So I'll adjust my time to look at the last fifteen minutes. I've got a few filters set up here already that correspond to the CIDR block that I searched. But I want to focus my query down, and this ticket is about denials. So I want to see whether traffic is being accepted or rejected, so I'll add firewall action. That way I can focus on what's denied by filtering out accepted traffic. So I'll grab this reject result here, and turn that into a filter. Now, I want to add a bunch more attributes to the data that we're visualizing to help me understand it more clearly so that I can see information about the application context, and some instance information to give me clues on what to zero in on. Okay. There are a bunch of different apps and instances that are associated with this rejected traffic. I know that this cloud data report AZ instance traffic is a known issue and that's not the problem here. So I'd like to filter those out. There are lots of ways to do that, but in this case I'll filter it by the network interface. So I'm going to add the network card details for this rejected traffic. Okay. Here's my iscsi service. I know that's for my storage area network, and that's what the developer is not able to access. And this service is using one ENI that's an elastic network interface. This one that's ending in ninety nine d. So I'm going to add that to my filters too. And now I've got a ton of data about what's going on. We can look at security groups now. And now I can see there's one security group that keeps coming up that's associated with this denied traffic. With the name of that security group, I can find the owner of that group and address this denied traffic with them if I need to. Another place where I can find this information is in my Kentik Map. I can find a subnet that I think is affected. And I get a shortcut here to seeing all of my denied traffic. If I have a report that a user suddenly can't access port eight four four three on a server on this subnet, I have an easy way to quickly understand the problem, and I've got the security group ID, the account ID, and the VPC ID at hand. And the same is true if an access control list is causing the issue. I don't need to dig through a bunch of spreadsheets, I don't need to look through a bunch of different VPCs in the AWS console. So this is one way that increasing productivity and reducing mean time to resolution actually happens in practice with Kentik.

Cloud Visibility: Kentik Cloud Enhancements for AWS

The Advantages of VPC Peering

VPC peering offers several important advantages.

1. Enhanced Security: Perhaps the most obvious benefit of VPC peering is security. Without VPC peering, workloads running in distinct clouds would have to communicate over the public internet. This requirement would significantly increase their exposure to potential attack or abuse. With VPC peering, however, private network communications between VPCs are never exposed to the internet.

2. Reduced Network Latency: VPC peering can also reduce network latency by eliminating the need to route traffic across the internet in order to enable communications between clouds. In this way, VPC peering may enhance network performance.

3. Decreased Costs of Network Expenses: Finally, because public cloud providers often charge lower egress fees for data that is transferred within VPC peering connections as compared to data that is transported across public internet connections, VPC peering can help reduce your cloud data egress bills.

VPC Peering Limitations and Why they Matter

While VPC peering is simple and secure, a few limitations dictate when it’s the right tool:

• Non-transitive routing: VPC peering is a one-to-one relationship and does not support transitive routing. If VPC A peers with VPC B and VPC B peers with VPC C, VPC A does not automatically gain a route to VPC C. This makes large peering “meshes” harder to operate.

• Overlapping CIDR blocks: You can’t create a peering connection if any IPv4 or IPv6 CIDR blocks overlap between the two VPCs, even if you only intend to use non-overlapping ranges. Plan address space early if you expect many VPCs.

• Edge-to-edge routing limits: Peering is designed for VPC-to-VPC traffic, not as a way to “borrow” connectivity. Resources in one VPC can’t use the other VPC’s internet gateway, NAT device, VPN, Direct Connect, or similar edge resources through a peering connection. This matters when you’re trying to centralize egress or share connectivity.

• Inter-region security group constraints: In AWS, you can’t reference a peer VPC’s security group across an inter-region peering connection. Instead, you typically use the peer VPC CIDR ranges in your rules, which can make least-privilege policy harder.

• Inter-region MTU and jumbo frame considerations: Inter-region paths can impose smaller MTU limits than same-region connectivity. If you rely on jumbo frames, validate MTU and watch for fragmentation or drops.

• Quotas and scaling pressure: AWS enforces quotas for peering connections, and large full-mesh designs can hit limits and create operational sprawl. If you’re trending toward “many VPCs, many peerings,” evaluate a hub model (Transit Gateway) or service exposure (PrivateLink).

• DNS resolution is optional, not automatic: If you expect private DNS names to resolve to private IPs across the peering link, you may need to enable DNS resolution settings on the peering connection and confirm VPC DNS attributes.

VPC Peering vs Transit Gateway vs PrivateLink

VPC peering is best for simple, direct connectivity between two VPCs (including cross-account and inter-region within AWS). But as your environment grows, peering can become harder to manage because it’s non-transitive (a peer does not automatically connect you to the peer’s peers), and large “mesh” designs require many one-to-one connections.

Use VPC peering when…

• You need straightforward, private, layer-3 connectivity between two VPCs (or a small number of VPC pairs).
• You want low operational overhead for a small topology, and you don’t need transitive routing.
• You can keep CIDR planning clean (no overlaps) and you’re comfortable managing route tables and security rules on both sides.

Use AWS Transit Gateway when…

• You need a hub-and-spoke architecture that scales to many VPCs, accounts, and regions.
• You need transitive routing (VPC A can reach VPC C through a central hub) and segmentation with route tables.
• You want a design that can also connect on-prem networks via VPN or Direct Connect through the same routing hub.

Use AWS PrivateLink when…

• You don’t want full network connectivity between VPCs, you want private access to a specific service (API, database, SaaS, internal app) with tighter exposure.
• You want to publish or consume services via private IPs inside your VPC without making entire subnets reachable.
• You want service-to-service access patterns that reduce blast radius compared to broad routing.

Practical shortcut: If your design starts to look like “everyone needs to talk to everyone,” VPC peering tends to become a route-table and governance headache. That’s a common signal to evaluate Transit Gateway (for network connectivity) or PrivateLink (for service connectivity).

VPC Peering and Network Observability

While VPC peering can help boost the security and performance of modern networks, it adds another layer of complexity to network architectures. Organizations must take steps to manage this complexity through network observability in order to ensure that issues with VPC peering configurations don’t disrupt network availability or performance.

A number of challenges could potentially arise within VPC peering, and pinpointing the source of a problem can be difficult. Manually configured routes could lead to traffic flow problems, for example, or a service degradation in one cloud provider’s network could increase latency across all VPCs that are peered with that provider’s VPCs.

To make matters more complicated, cloud providers themselves offer users relatively little ability to track and manage the performance of VPC peering connections. Each cloud provider focuses on helping customers manage the performance only of network resources running within its own cloud. AWS tooling will not help you troubleshoot problems with a peered VPC running in Azure, for example. AWS only tracks the performance of VPCs running within AWS.

This means that, if your team sets up VPC peering, the burden is on you to identify and manage any potential issues that arise. Network intelligence platforms allow you to do this by ingesting network telemetry data from multiple sources, then correlating and contextualizing that data so that you can answer questions about the state of all of your VPCs. Kentik’s network intelligence platform, for example, can be used to manage VPC communications in and between AWS, Google Cloud, and Microsoft Azure cloud environments.

In other words, by analyzing data sources such as flow logs, latency metrics and synthetic performance tests from across all of the cloud environments that host your VPCs, network observability tools make it possible to identify, understand and resolve performance issues that may arise within the context of VPC peering. You can trace a problem with peered VPC connections to the specific cloud or configuration that triggers them.

In turn, you can take action to ensure that your VPC peering connections fully deliver on the security, performance and cost benefits that VPC peering stands to offer.

To see how Kentik can help boost the security and performance of your organization with VPC peering, request a demo or sign up for a free trial today.

Frequently Asked Questions about VPC Peering

What is a VPC?

A VPC (virtual private cloud) is a logically isolated virtual network in a public cloud where you control IP ranges, subnets, routing, and network security so your workloads can communicate privately while still using cloud-managed infrastructure.

What is VPC peering?

VPC peering is a private, point-to-point connection between two VPC networks that allows traffic to route between them using private IPv4/IPv6 addresses without traversing the public internet, and it is commonly used for cross-account or inter-region connectivity within a cloud provider. Kentik supports VPC peering troubleshooting by correlating cloud flow logs with routing context and synthetic performance testing so teams can verify reachability, detect what changed, and pinpoint latency or packet loss across the peered path.

Does VPC peering support transitive routing?

No. VPC peering is non-transitive, which means a VPC only has routes to the specific VPCs it is directly peered with, not to “downstream” networks behind a peer. Kentik helps teams spot the operational impact of non-transitive designs by showing actual cross-VPC traffic patterns, highlighting unexpected dependencies, and validating whether routing changes improved or degraded the paths users and services rely on.

Can I peer VPCs with overlapping CIDR blocks?

In AWS, you can’t create a VPC peering connection if any IPv4 or IPv6 CIDR blocks overlap between the two VPCs, even if you plan to use only non-overlapping ranges. Kentik can still help you move forward by showing which subnets and services need private connectivity, so you can choose a safer design (readdressing, Transit Gateway, or service-level access via PrivateLink) based on real traffic requirements.

VPC peering vs Transit Gateway: which should I use?

VPC peering is a great fit for simple one-to-one connectivity, while Transit Gateway is typically a better fit when you need a hub-and-spoke architecture for many VPCs, accounts, or regions and you want transitive routing and centralized segmentation. Kentik helps by revealing which VPC pairs actually exchange traffic, quantifying the “who talks to whom” graph from flow logs, and validating performance before and after architecture changes with synthetic tests.

VPC peering vs PrivateLink: what’s the difference?

VPC peering provides broad layer-3 network connectivity between two VPCs, while PrivateLink is designed for private access to specific services via interface endpoints without making entire networks mutually routable. Kentik helps teams choose the right pattern by identifying which dependencies need full network connectivity versus service-only access, then monitoring the resulting paths and performance with flow analytics and synthetics.

How do I troubleshoot latency or packet loss across a VPC peering connection?

Start by confirming routes and security policies on both sides, then validate the path and performance between real sources and destinations to determine whether the issue is routing, congestion, MTU/fragmentation, or a provider/regional event. Kentik supports this by combining cloud flow logs with synthetic tests (ping/traceroute/HTTP/DNS) to show where latency or loss appears and whether it aligns with a routing or policy change.

How does VPC peering differ from internet/BGP peering?

VPC peering connects two VPC as if they were on the same network, using private IP addresses. Traditional internet peering allows for similar functionality. Internet peering is a connection between two IP networks that allows traffic to flow from sources in either of the networks to destinations in the other without allowing the traffic to travel via the internet. This sort of peering is configured using BGP (Border Gateway Protocol) which exchanges routing information between two systems. The configuration of BGP on both sides of the connection determines whether the connection is a “peering” or an “internet access/transit” type of connection. For a deeper discussion of this topic, see “What is Internet Peering?”.

Updated: February 19, 2026