# VPC peering

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/vpc-peering

## Quick definition

VPC peering lets you connect two separate virtual private clouds so they can talk to each other privately over the internet without using public IP addresses. Think of it as a private bridge between two buildings in a corporate campus. The traffic never goes out to the public internet, making it more secure and faster. It is a simple way to share resources across different cloud networks.

## Simple meaning

Imagine you live in a gated community with two separate housing blocks. Each block has its own private roads, security guards, and mail system. Residents in Block A cannot walk over to Block B because there is a fence between them. Now suppose you have friends in Block B and you want to borrow their lawnmower. Without VPC peering, you would have to walk out of your block, go around the entire community, enter through the main gate, and then find your friend’s house. That is like sending data over the public internet: it works, but it is slow, less secure, and takes a longer route.

Now, let us say the community manager decides to build a private gate directly between Block A and Block B. That gate allows residents of one block to walk directly into the other block without ever leaving the community. They still have their own separate security systems, but the connection is fast, private, and direct. That is exactly what VPC peering does for cloud networks. A VPC, or Virtual Private Cloud, is like a private networking environment in the cloud. Each VPC has its own IP address range, subnets, and security rules. Normally, two VPCs are completely isolated, they cannot see or talk to each other. But by setting up a VPC peering connection, you create a direct, private link between them.

This link uses private IP addresses, not public ones. So data traveling between the peered VPCs never touches the public internet. It stays within the cloud provider’s own infrastructure. This makes the connection more secure, reduces latency, and can even save money because you are not paying for internet bandwidth. You can think of VPC peering as a dedicated tunnel between two VPCs. The tunnel does not require a separate physical device; it is all managed by the cloud provider. Once the peering is established and the route tables are updated, resources in one VPC can reach resources in the other VPC just as if they were in the same local network.

It is important to know that VPC peering is not transitive. That means if VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A cannot automatically talk to VPC C. Each pair must be directly connected. Also, the two VPCs must have non-overlapping IP address ranges. If they both use the same IP range, the peering connection will fail or cause routing conflicts. VPC peering is commonly used in cloud environments when different teams or applications need to share data, such as a web application in one VPC needing to query a database in another VPC. It is a foundational concept for cloud networking and appears frequently in certification exams from AWS, Azure, and Google Cloud.

## Technical definition

VPC peering is a one-to-one networking connection between two Virtual Private Clouds (VPCs) that enables private IPv4 or IPv6 communication between them using the cloud provider’s internal network infrastructure. In AWS, a VPC peering connection is established by creating a peering request from the requester VPC, which is then accepted by the accepter VPC. The connection is not a gateway or a VPN; it is a logical routing path that uses the cloud provider’s backbone network. Traffic between peered VPCs never traverses the public internet, which minimizes exposure to threats and reduces latency.

From a protocol standpoint, VPC peering supports all IP-based protocols, including TCP, UDP, ICMP, and others, as long as they operate over IP. The underlying data plane uses standard Ethernet framing encapsulated within the provider’s network. There is no encryption inherent to the peering link itself because it resides within the provider’s trusted infrastructure. If encryption is required, application-layer encryption like TLS or IPsec tunnels over the peering connection must be used. The peering link is highly available by default, as the provider manages the underlying physical infrastructure across multiple availability zones.

To make the peering connection functional, route tables in each VPC must be updated with routes pointing to the CIDR block of the peered VPC, using the peering connection as the target. For example, if VPC A has CIDR 10.0.0.0/16 and VPC B has CIDR 172.16.0.0/16, VPC A’s route table must have an entry like “destination: 172.16.0.0/16, target: pcx-12345678”. Similarly, VPC B must have a route for 10.0.0.0/16 pointing to the same peering connection ID. Without these routes, traffic will not flow even if the peering request is accepted.

Security groups and network ACLs still apply to traffic flowing through a VPC peering connection. A common misconception is that peering bypasses security controls; it does not. Each VPC retains its own security group rules and network ACLs. For instance, if an EC2 instance in VPC A tries to connect to an RDS database in VPC B, the security group attached to the RDS instance must allow inbound traffic from the private IP of the EC2 instance or from the CIDR range of VPC A. Similarly, the EC2 instance’s security group must allow outbound traffic to the RDS instance’s private IP or CIDR range of VPC B.

One critical constraint of VPC peering is its non-transitive nature. If VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A cannot communicate with VPC C unless a direct peering connection exists between them. This prevents accidental mesh networking and forces explicit, manageable connections. To connect multiple VPCs, you would need either a full mesh of peering connections or use a transit gateway, which is a separate AWS service that acts as a central hub.

Another technical limitation is that VPC peering does not support transitive routing across multiple accounts unless the peering is explicitly established between the accounts. Cross-account peering is supported, but the accepter must accept the request from the requester account. VPC peering does not support edge-to-edge routing. For example, if you have a VPN connection from an on-premises network to VPC A, and VPC A is peered with VPC B, the on-premises network cannot reach resources in VPC B through VPC A. This is by design to avoid complex routing loops and security holes.

In Azure, the equivalent feature is called VNet peering. It supports peering within the same region (regional VNet peering) and across regions (global VNet peering). Azure VNet peering also allows transitive peering when used with a hub-spoke topology through Azure Virtual Network Gateway. However, by default, Azure VNet peering is non-transitive, similar to AWS. In Google Cloud, the feature is called VPC Network Peering, which also supports cross-project and cross-region peering. Google Cloud peering is also non-transitive unless you use a shared VPC or a network appliance.

Performance-wise, VPC peering introduces minimal latency because traffic stays within the provider’s network and typically does not need to traverse an intermediate gateway or firewall. Bandwidth is limited only by the instance types and network capacity of the VMs involved, not by the peering connection itself. The peering link can handle up to the maximum throughput supported by the instance’s network interface.

Cost is another factor. In AWS, there is no charge for the peering connection itself, but data transfer charges apply for traffic that crosses availability zones or regions. For intra-region peering, data transfer is typically free if both VPCs are in the same region. For inter-region peering, data transfer rates apply based on the source and destination regions. In Azure, VNet peering charges apply for inbound and outbound data transfer, with different rates for same-region and cross-region peering. Google Cloud charges for egress traffic from each VPC network, but ingress is free.

To manage VPC peering at scale, cloud architects often use tools like AWS Resource Access Manager (RAM) for sharing peering connections across accounts, or Azure Virtual Network Manager for central policy management. Automation via Infrastructure as Code tools like Terraform or AWS CloudFormation is common to ensure consistent peering configurations across environments.

When troubleshooting VPC peering issues, network engineers first verify that the peering connection status is “active”. Next, they check route tables for the presence of proper routes. They also examine security group and network ACL rules to ensure traffic is not being blocked. For cross-account peering, the accepter must explicitly accept the request. DNS resolution can also be an issue: by default, the DNS hostnames of resources in one VPC are not resolvable in the peered VPC unless DNS resolution support is enabled on the peering connection.

VPC peering is a powerful, simple, and cost-effective way to connect two VPCs privately. It is a fundamental building block for multi-tier architectures, hybrid cloud setups, and microservices communication. Understanding its constraints, especially non-transitivity and route table dependencies, is essential for passing cloud networking exams and for building reliable production networks.

## Real-life example

Think of two separate office buildings located next to each other in a business park. Building A is home to the marketing team, and Building B is home to the engineering team. Each building has its own front door, its own security badge system, its own meeting rooms, and its own break room. Employees in Building A cannot just walk into Building B without going out the front door, walking around the block, and then entering through the front door of Building B. That is like two VPCs communicating through the public internet. It works, but it is inefficient and less secure.

Now, imagine the two building owners decide to build a private walkway directly connecting the first floors of both buildings. This walkway has its own door that requires a special badge. Only employees who need to collaborate can get access. Once inside the walkway, they can go back and forth between the two buildings without ever stepping outside. That private walkway is your VPC peering connection. The two buildings remain separate with their own security systems, but the direct link makes sharing resources easy.

In this analogy, the buildings are the VPCs. Each building has its own floor plan (subnets), its own room numbers (IP addresses), and its own security guards (security groups and network ACLs). The private walkway is the peering connection, which is a logical link, not a physical cable. The badges represent the routing table entries: you need the right permissions (routes) to use the walkway. If building A’s employees want to borrow a 3D printer from building B, they simply walk through the private walkway, find the printer in the engineering room, use it, and return. That is like an application server in one VPC accessing a database in another VPC.

But what if there is a third building, Building C, for the HR team? Building A is connected to Building B, and Building B is connected to Building C, but Building A is not directly connected to Building C. If someone in Building A wants to deliver a document to HR in Building C, they cannot walk through Building B because the walkway only connects pairs directly. They would have to walk out of Building A, go around, and enter Building C through its own front door. That is the non-transitivity of VPC peering. You cannot hop from one peering connection to another. This ensures that each connection is intentional and controlled.

Another insight from the analogy: if both buildings use the same room numbers (overlapping IP addresses), confusion would arise. A person looking for room 201 would not know which building they are in. That is why VPC peering requires non-overlapping CIDR blocks. Also, the walkway does not have its own security checkpoint; each building’s security team still checks everyone coming in. Similarly, each VPC’s security groups and network ACLs evaluate traffic from the peered VPC, so you must configure them properly.

In real life, if the business park expanded and needed to connect many buildings, building a walkway between every pair would become a mess. Instead, they might build a central hub building with walkways to each other building. That is analogous to a transit gateway. But for a simple two-building connection, the private walkway (VPC peering) is perfect. It is direct, simple, and cheap.

## Why it matters

VPC peering is a cornerstone of modern cloud networking because it solves the fundamental problem of resource isolation. In any cloud environment, VPCs are created as isolated enclaves by default. This isolation is great for security, it prevents one application from accidentally accessing another, but it creates a problem when you need to share data or services across teams, environments, or accounts. Without VPC peering, you would have to expose resources to the public internet, which is insecure, expensive, and introduces latency.

In practical IT environments, VPC peering is used to connect production and development VPCs so that developers can access production databases for testing. It is used to link a front-end web tier in one VPC with a back-end API tier in another VPC. It enables companies that merge or partner to connect their separate cloud infrastructures. It is also common for connecting a VPC that hosts a shared service, like an Active Directory or a logging system, to multiple other VPCs that consume that service.

From a cost perspective, VPC peering can significantly reduce data transfer costs compared to sending traffic over the internet or through a VPN. Since the traffic stays within the provider’s network, it is often free or cheap, especially within the same region. This makes it an attractive choice for high-volume data exchange between services.

Security is another major reason VPC peering matters. Because the connection uses private IP addresses, the traffic is not exposed to the public internet. This dramatically reduces the attack surface. All existing security controls, like security groups and network ACLs, continue to apply. You can implement a least-privilege model by crafting specific rules for peered traffic.

However, VPC peering also introduces complexity. You have to manage route tables across multiple VPCs, ensure IP ranges do not overlap, and remember that peering is not transitive. If you are managing dozens of VPCs, a full mesh of peering connections becomes unmanageable. That is why understanding VPC peering is critical before moving to more advanced solutions like transit gateways or shared VPCs. For IT professionals, especially those pursuing cloud certifications, mastering VPC peering is a non-negotiable skill. It shows up in exam questions about connectivity, security, and architecture. It also appears in job interviews for cloud engineer roles. Knowing VPC peering means you understand how cloud networks are really built: not as a single flat network, but as a carefully connected set of isolated environments.

## Why it matters in exams

VPC peering is a high-priority topic across multiple cloud certification exams. In the AWS Certified Cloud Practitioner exam, it appears as a fundamental concept for understanding how AWS networking works. Questions typically ask about the purpose of VPC peering, its benefits over internet-based communication, and basic constraints like non-transitivity. In the AWS Developer Associate exam, you might see questions about how to enable cross-VPC communication for microservices or how DNS resolution works between peered VPCs. The AWS Solutions Architect Associate exam treats VPC peering as a core networking topic. Expect scenario-based questions where you must decide between VPC peering, a VPN, or a transit gateway for connecting VPCs. You also need to know how to configure route tables and security groups for peering.

For the Microsoft Azure exams, AZ-104 and Azure Fundamentals, the equivalent is VNet peering. Questions cover regional vs. global VNet peering, differences from VPN gateways, and how to force traffic through a firewall appliance using a hub-spoke topology. The Google Cloud exams, Associate Cloud Engineer, Cloud Digital Leader, and Professional Cloud Architect, cover VPC Network Peering. Expect questions on shared VPC vs. peering, and how to connect projects across organizations.

In network-specific certifications like CompTIA Network+ and Cisco CCNA, VPC peering is not directly tested because these exams focus on on-premises networking. However, the underlying concepts of route tables, CIDR, and protocol independence are foundational. Questions about private IP addressing, routing, and network segmentation will indirectly test your understanding of how cloud networking works, which includes VPC peering.

For CompTIA Security+, VPC peering relates to network segmentation and secure communication. You might see a question about how to securely connect two virtual networks without exposing traffic to the internet. The correct answer would often be VPC peering or a private connection, as opposed to using public IPs.

When studying for these exams, pay attention to the following specific topics: the on-premises to VPC connectivity is not supported via VPC peering alone. Also, know that VPC peering does not support transitive routing, you must explicitly set up route tables, security groups must allow the traffic, and DNS resolution must be enabled if needed. Many exam questions test these constraints. For example, a question might ask: “A company has VPC A peered with VPC B. VPC B is peered with VPC C. Can an instance in VPC A communicate with an instance in VPC C?” The answer is no, unless a direct peering connection exists. This non-transitivity trap is a favorite among exam writers.

Another common exam pattern involves troubleshooting. You might be given a scenario where a peering connection is active, but instances cannot communicate. The expected answer will involve checking route tables or security groups. For AWS exams, also remember that the peering connection must be in the “accepted” state, and that you cannot peer VPCs with overlapping CIDR blocks.

In the Google Cloud exam, remember that VPC Network Peering allows up to 25 peering connections per VPC, and peering with a VPC in another project requires careful IAM permissions. In Azure, note that VNet peering has an option called “Allow gateway transit” which is used in hub-spoke designs, but that is different from standard VPC peering.

Finally, exam questions often present cost as a factor. VPC peering is usually cheaper than VPN or Direct Connect, but it has limitations. If the scenario requires connecting more than a few VPCs, a transit gateway might be the better answer. Knowing when to use VPC peering versus alternative solutions is a high-level skill that distinguishes passing candidates from failing ones.

## How it appears in exam questions

Exam questions about VPC peering come in several typical patterns. The first is the scenario-based design question. The question describes a company with multiple VPCs and asks which networking solution should be used. For example: “A company has a web application in VPC A and a database in VPC B. They need a low-latency, private connection between the two. What should they use?” The answer is VPC peering. The distractor options often include an internet gateway, NAT gateway, VPN, or AWS Direct Connect. The key differentiator is that VPC peering is the simplest direct private connection for two VPCs in the same region.

The second pattern is the configuration question. These questions test your knowledge of the steps to set up peering. For instance: “After establishing a VPC peering connection between VPC A and VPC B, instances in VPC A cannot reach instances in VPC B. What is the most likely cause?” The correct answer is that the route tables in each VPC do not have the proper routes pointing to the peering connection. Another common configuration issue is that security groups or network ACLs are blocking traffic. These questions force you to think about the entire data path: peering request accepted, routes added, and security rules adjusted.

The third pattern is the constraint or limitation question. These directly test the non-transitive nature of VPC peering. An example: “Company X has three VPCs. VPC-A is peered with VPC-B, and VPC-B is peered with VPC-C. An application in VPC-A needs to access a database in VPC-C. What must the solutions architect do?” The correct answer is to create a direct peering connection between VPC-A and VPC-C, or use a transit gateway. A common wrong answer is that it will work because VPC-B acts as a router. The exam expects you to know that VPC peering does not support transitive routing.

The fourth pattern is the hybrid or cross-account question. For example: “A company has a VPC in Account A and a VPC in Account B. How can they enable private communication?” The answer is to create a cross-account VPC peering connection, with Account A as the requester and Account B as the accepter. The question might also ask about IAM permissions needed for the accepter to accept the request. In Azure, the equivalent would be cross-subscription VNet peering.

The fifth pattern is the troubleshooting question. You might get a verbose scenario describing a peering connection that appears active, but pings fail. The question asks for the root cause. Potential answers include: missing routes, security group blocking ICMP, DNS resolution not enabled, or overlapping IP ranges. These questions test your ability to systematically isolate networking issues.

Finally, the exam may present a question about cost. For instance: “A company wants to minimize data transfer costs between two VPCs in the same AWS region. Which solution is most cost-effective?” VPC peering is typically cheaper than using a NAT instance or a VPN. However, if the VPCs are in different regions, data transfer charges apply for VPC peering, and a VPN might be comparable. The correct answer depends on the specific details given.

In the Google Cloud Associate Cloud Engineer exam, a typical question might be: “You have two projects, each with a VPC network. You need to enable private communication between VM instances in these networks. What should you do?” The answer is to set up VPC Network Peering between the two networks. The question might also ask about the requirement that CIDR ranges not overlap.

By studying these question patterns, you can prepare yourself to recognize what the exam is really asking, even when the wording is convoluted. Always map the scenario back to the core attributes of VPC peering: direct, private, one-to-one, non-transitive, requires route tables and security group configuration, and works only with non-overlapping IP ranges.

## Example scenario

Imagine you are a solutions architect at a medium-sized e-commerce company. The company has two separate VPCs in the same AWS region. The first VPC, called “Web-VPC”, hosts the public-facing website on EC2 instances behind an Application Load Balancer. The second VPC, called “DB-VPC”, hosts a managed MySQL database that stores customer orders and product inventory. Currently, the website in Web-VPC connects to the database using its public IP address, which means traffic goes out to the internet and back in to DB-VPC. This is slow, insecure, and costs extra for internet data transfer.

Your task is to implement a private, low-latency connection between the two VPCs. You decide to set up a VPC peering connection. First, you verify that the IP address ranges do not overlap. Web-VPC uses 10.0.0.0/16 and DB-VPC uses 172.16.0.0/16, no conflict. You create a peering request from Web-VPC to DB-VPC. The DB-VPC owner (or an automated script) accepts the request. The peering status changes to “active”.

Next, you update the route table in Web-VPC. You add a route with destination 172.16.0.0/16 and target the peering connection ID. Similarly, you update the route table in DB-VPC with a route for destination 10.0.0.0/16 pointing to the same peering connection. Without these routes, the instances in each VPC have no idea how to reach the other network.

Then, you adjust security groups. The EC2 instances in Web-VPC need outbound rules to allow traffic to the database port (3306 for MySQL) to the CIDR range of DB-VPC. The security group for the RDS database in DB-VPC needs an inbound rule that allows traffic from the CIDR range of Web-VPC on port 3306. You also ensure that network ACLs in both VPCs allow the traffic in both directions.

After the configuration, you test by deploying a small application instance in Web-VPC that tries to connect to the database using the private IP address of the RDS instance. The connection succeeds, and you verify that the data path never leaves AWS’s internal network. The latency drops from 20ms (over internet) to under 2ms. You also note that the cost for data transfer is reduced because intra-region VPC peering data transfer is free in AWS.

Later, the company adds a third VPC for analytics, but you decide to use a transit gateway instead of multiple peering connections to keep the architecture manageable. This scenario shows the typical lifecycle of VPC peering: assessment, setup, route configuration, security tuning, and validation. It also illustrates why VPC peering is often the first choice for simple two-VPC connections.

## VPC Peering Fundamentals and Use Cases

VPC peering is a networking connection between two Virtual Private Clouds (VPCs) that enables you to route traffic between them using private IPv4 or IPv6 addresses. This connection is not a gateway or a VPN connection and does not rely on a separate physical hardware appliance. Instead, it uses the existing infrastructure of the cloud provider to create a direct, low-latency, and high-bandwidth link between VPCs. In AWS, for example, instances in peered VPCs can communicate as if they are within the same network, with no intermediate hops. This is critical for scenarios such as multi-tier application architectures, where you might have a web tier in one VPC and a database tier in another, allowing for strict security boundaries while maintaining high performance.

VPC peering can be established between VPCs within the same account or across different accounts, and within the same region or across different regions (known as inter-region VPC peering). In AWS, inter-region peering is supported, and traffic remains on the global AWS backbone, never traversing the public internet. This is a major advantage for global applications that need secure, low-latency communication across geographic boundaries. In Azure, the equivalent is VNet peering, which supports peering within the same region and globally, with traffic staying on the Microsoft backbone. Google Cloud uses VPC Network Peering, which is similar and supports both intra- and inter-region peering.

The use cases are numerous. Enterprises often use VPC peering to share resources such as directory services, DNS servers, or monitoring tools across different VPCs that belong to different business units. It is also used to connect development, testing, and production environments in a controlled manner. Another common pattern is when an organization needs to centralize egress traffic through a single VPC that has a NAT gateway or internet gateway, thereby avoiding the cost and complexity of multiple internet gateways. In cloud practitioner and associate-level exams, the most frequent scenario involves understanding that VPC peering does not support transitive routing. That is, if VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A cannot directly communicate with VPC C unless there is a separate peering connection. This is a deliberate design to prevent accidental routing loops and to maintain network isolation.

Security considerations are paramount. Peering connections do not automatically grant access to all resources; you must configure route tables to direct traffic to the peering connection and adjust security groups and network ACLs accordingly. In multi-account setups, the owner of each VPC must accept the peering request. Overlapping CIDR blocks cannot be peered because the routing becomes ambiguous. This is a common exam trick: you cannot peer VPCs that have overlapping IP address ranges. Understanding these constraints is essential for designing scalable and secure multi-VPC architectures.

## VPC Peering Routing and Transitive Peering Limitations

Routing in VPC peering is a critical concept that is heavily tested in cloud exams. When you create a peering connection, the underlying infrastructure does not automatically propagate routes. You must explicitly add routes in the route tables of each subnet that needs to communicate across the peering connection. For instance, in AWS, you add a route in the subnet route table of VPC A with destination as the CIDR block of VPC B, and target as the peering connection ID (pcx-xxxxxxxx). Similarly, you must do the reverse in VPC B's route tables. If you fail to configure routes in both directions, traffic will be dropped. This is a common mistake in real-world deployments and exam scenarios.

The most important exam trap is the lack of transitive routing. Suppose you have three VPCs: A, B, and C. You establish peering between A and B, and between B and C. Even though B can communicate with both A and C, no traffic can flow directly from A to C. To enable A-to-C communication, you must create a separate peering connection between A and C. This is by design-cloud providers intentionally avoid transitive peering to prevent complex routing loops and to enforce security boundaries. In AWS, there is no such thing as a transitive peering route. In Azure, VNet peering also does not support transitive routing. In Google Cloud, you can use shared VPC or Network Connectivity Center for more complex topologies, but standard VPC peering is non-transitive.

Another routing nuance is the handling of private IP addresses versus public IPs. When instances in peered VPCs communicate, they use private IP addresses, which means traffic stays within the cloud provider's network. This is more secure and often cheaper than sending traffic over the internet. However, if you have overlapping CIDR blocks, the routing becomes impossible because the destination IP is ambiguous. Therefore, careful IP address planning is essential before setting up peering. Exams often present a scenario where an administrator tries to peer two VPCs with overlapping ranges, and the correct answer is that the peering request fails or the connection is rejected.

Route propagation from VPN or Direct Connect does not automatically extend to peered VPCs either. If you have a VPC with a VPN connection to an on-premises network, and you peer that VPC with another VPC, the on-premises routes are not automatically added to the peered VPC's route table. You must manually add static routes or use a central transit VPC (or in AWS, transit gateway) to handle such hybrid connectivity. This concept is frequently tested in the AWS Solutions Architect Associate exam, where you need to decide between VPC peering and transit gateway for multi-VPC architectures with complex routing requirements.

## VPC Peering Security Groups and Network ACLs

Security is a top concern when connecting VPCs, and VPC peering introduces specific considerations for security groups and network access control lists (ACLs). In AWS, security groups act as virtual firewalls for instances, and they can reference security groups from peer VPCs as a source or destination. This is a powerful feature: you can create a security group rule that allows traffic from a security group in a different VPC, provided the VPCs are peered. For example, if you have a web server in VPC A and a database server in VPC B, you can configure the database security group to allow inbound traffic from the security group attached to the web server instances. This ensures that only the intended instances can connect, even if the IP addresses change. This cross-account security group referencing works only if the VPCs are peered and the security groups are in the same region (for AWS) or within the same Azure region for VNet peering.

Network ACLs are stateless and operate at the subnet level. They also support referencing CIDR blocks, but not security group IDs. When you peer VPCs, you must ensure that both network ACLs and security groups allow the necessary traffic. A common exam scenario involves an administrator who configures the security groups correctly but forgets to update the outbound network ACL rules. Since network ACLs are stateless, you need to separately allow outbound traffic from the source subnet and inbound traffic on the destination subnet. This is a frequent source of connectivity issues in practice.

Another security nuance is the default behavior of security groups. By default, a security group denies all inbound traffic. When you add a rule to allow traffic from a peered VPC, you must specify the correct protocol and port. For example, to allow MySQL (port 3306) from a peer VPC, you would add an inbound rule with type MySQL/Aurora, source being the CIDR block of the peer VPC or the security group ID of the peer's instances. In exam questions, you might be asked whether the security group rule should reference the CIDR block or the security group ID. The answer depends on whether you want to allow any instance within the peer VPC or only specific instances. Using the security group ID is more fine-grained and secure.

In Azure, the equivalent is network security groups (NSGs) and application security groups. Azure VNet peering requires that NSG rules be updated to allow traffic between peered virtual networks. Similarly, in Google Cloud, firewall rules are applied at the VPC level, and they can be targeted to specific service accounts or tags. When using VPC peering in Google Cloud, you must create firewall rules that allow ingress and egress from the peer network's IP ranges. Understanding these details is critical for security-related exam questions, especially in the AWS Security Specialty and Azure Security Engineer exams.

## VPC Peering Cost, Multi-Region, and Hybrid Scenarios

Cost is a significant factor when designing VPC peering architectures, and exam questions often test your ability to estimate and explain billing implications. In AWS, data transfer between peered VPCs within the same region is free; you only pay for standard data transfer charges for traffic that goes through NAT gateways, VPN connections, or internet gateways. This makes intra-region peering very cost-effective for connecting VPCs. However, inter-region VPC peering incurs data transfer charges on both sides. Traffic from US East (N. Virginia) to US West (Oregon) is billed per gigabyte, similar to inter-region data transfer costs. In Azure, VNet peering within the same region is also free, but global VNet peering has ingress and egress charges. Google Cloud charges for inter-region peering based on the source and destination regions.

For hybrid scenarios where you need to connect on-premises data centers to multiple VPCs, VPC peering is often used in conjunction with AWS Direct Connect or Azure ExpressRoute. A common architecture is to have a central VPC (a transit VPC) that connects to on-premises via VPN or Direct Connect, and then peer other VPCs to this central VPC. This allows all spoke VPCs to access on-premises resources. However, this architecture leads to the transitive routing limitation: spoke VPCs cannot communicate with each other through the transit VPC. To solve this, you can use a transit gateway (AWS) or a hub-and-spoke topology with route tables (Azure) or using Google's Network Connectivity Center. Exams love to ask: "Which service should you use to enable transitive routing between multiple VPCs and an on-premises network?" The answer is often AWS Transit Gateway or Azure Virtual WAN, not VPC peering.

Another cost consideration is the use of NAT gateways. If you have multiple VPCs that need outbound internet access, you might peer them to a single VPC that has a NAT gateway. However, this means all traffic from spoke VPCs to the internet goes through the NAT gateway, incurring NAT gateway processing fees and data transfer costs. The alternative is to give each VPC its own NAT gateway, which increases management overhead but may reduce latency. In exams, you should recognize that VPC peering can reduce costs by consolidating shared services such as internet egress, but it introduces complexity in routing and security.

Finally, when designing for high availability, VPC peering can be used to replicate data across regions. For example, you can peer a VPC in us-east-1 with a VPC in eu-west-2 for disaster recovery. However, because the peering connection is a single point of failure (one peering connection per pair of VPCs), you must ensure redundancy at the application layer. Cloud providers offer multiple peering connections if needed, but each is a separate resource. In AWS, you can have multiple peering connections from the same VPC to different VPCs without issues. The key takeaway is that VPC peering is a powerful cost-effective tool for intra-region connectivity, but for complex multi-region or transitive scenarios, you need to consider additional services and their associated costs.

## Common mistakes

- **Mistake:** Assuming VPC peering is transitive.
  - Why it is wrong: VPC peering is strictly one-to-one. If VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A cannot reach VPC C through VPC B. This is a fundamental design limitation.
  - Fix: Always remember that each pair of VPCs that need to communicate must have a direct peering connection, or you must use a transit gateway for hub-and-spoke connectivity.
- **Mistake:** Forgetting to update route tables after accepting a peering connection.
  - Why it is wrong: Even if the peering connection is active, traffic will not flow because the VPCs do not know how to reach each other without explicit routes in their route tables.
  - Fix: Immediately after the peering connection is in the active state, add a route in each VPC’s route table that points to the other VPC’s CIDR block, with the peering connection as the target.
- **Mistake:** Overlooking security group and network ACL rules.
  - Why it is wrong: VPC peering does not bypass security controls. The security groups and network ACLs in each VPC still evaluate traffic. If they do not allow the traffic, the connection will fail.
  - Fix: Always configure inbound and outbound security group rules and network ACL rules to permit the desired traffic between the CIDR ranges of the peered VPCs.
- **Mistake:** Peering VPCs with overlapping CIDR blocks.
  - Why it is wrong: If two VPCs use the same or overlapping private IP ranges, routing becomes ambiguous. The route tables cannot distinguish which VPC a packet should go to, and the peering connection request will be rejected or cause unpredictable behavior.
  - Fix: Before creating a peering connection, verify that the CIDR blocks of the VPCs do not overlap. If they do, you must either re-create one VPC with a different CIDR or use a different connectivity method like a VPN with NAT.
- **Mistake:** Trying to use VPC peering to connect to an on-premises network.
  - Why it is wrong: VPC peering only connects two VPCs within the same cloud provider. It does not support connecting a VPC to an on-premises data center or to a non-VPC network.
  - Fix: For on-premises connectivity, use a VPN connection, AWS Direct Connect, or Azure ExpressRoute. VPC peering is not designed for hybrid cloud scenarios.
- **Mistake:** Assuming DNS hostnames will be automatically resolvable across peered VPCs.
  - Why it is wrong: By default, DNS resolution for the peered VPC is disabled. If you try to use a private DNS name from one VPC in the other VPC, the lookup will fail unless you enable DNS resolution support on the peering connection.
  - Fix: When setting up the peering connection, enable the “Allow DNS resolution from requester VPC” option. Also ensure that the VPCs have DNS hostnames and DNS resolution enabled at the VPC level.
- **Mistake:** Expecting VPC peering to work across different cloud providers.
  - Why it is wrong: VPC peering is a cloud-provider-specific feature. You cannot peer an AWS VPC with an Azure VNet directly. They are different platforms with incompatible networking stacks.
  - Fix: For multi-cloud connectivity, use a VPN gateway or a third-party SD-WAN solution to create a secure tunnel between the two clouds. VPC peering only works within the same provider.

## Exam trap

{"trap":"A question states that three VPCs are peered in a chain: VPC-A to VPC-B, and VPC-B to VPC-C. It then asks whether an instance in VPC-A can communicate with an instance in VPC-C. Many learners choose “Yes, because VPC-B will route the traffic.”","why_learners_choose_it":"Learners often apply real-world networking intuition where routers forward traffic between networks. They assume B will forward packets between A and C, especially if B has routes to both.","how_to_avoid_it":"Remember that VPC peering is non-transitive. The exam explicitly tests this. VPC-B will not forward traffic between A and C unless it is specifically configured to do so via a transit gateway or a third-party appliance. The correct answer is always “No, a direct peering connection is needed.”"}

## Commonly confused with

- **VPC peering vs VPC peering vs. Transit Gateway:** VPC peering is a direct one-to-one connection between two VPCs. A transit gateway acts as a central hub that can connect multiple VPCs, VPNs, and Direct Connect together, and it supports transitive routing. Use VPC peering for simple point-to-point needs, and transit gateway when you need to connect many VPCs in a star topology. (Example: You have two VPCs: use VPC peering. You have ten VPCs: use a transit gateway to avoid a messy web of individual peering connections.)
- **VPC peering vs VPC peering vs. VPN:** VPC peering is a private connection between VPCs within the same cloud provider. A VPN is an encrypted tunnel that goes over the public internet and can connect a VPC to an on-premises network or to a VPC in another cloud provider. VPN adds encryption overhead and typically higher latency. (Example: Connecting two VPCs in AWS: VPC peering is simpler and cheaper. Connecting an on-premises data center to an AWS VPC: you need a VPN.)
- **VPC peering vs VPC peering vs. AWS PrivateLink:** VPC peering enables full network connectivity between VPCs. PrivateLink allows you to expose a specific service in one VPC to other VPCs without making the entire network reachable. PrivateLink is more secure but more complex, and it is used for service consumption rather than general networking. (Example: You want a database in VPC-A to be accessible from VPC-B, but you do not want VPC-B to have any other access to VPC-A. Use PrivateLink. For shared applications where full access is needed, use VPC peering.)
- **VPC peering vs VPC peering vs. Shared VPC (GCP) / VNet Injection (Azure):** VPC peering is a connection between two independent VPCs. In Google Cloud, Shared VPC allows a host project to share its VPC with other service projects, effectively putting resources from multiple projects into the same network. Azure VNet injection allows you to integrate a managed service into your own VNet, which is different from peering. (Example: You need to give a developer team access to a central network without creating a separate VPC for them. Google Shared VPC lets you attach their resources to the same VPC. With AWS, you would use VPC peering or transit gateway.)
- **VPC peering vs VPC peering vs. VPC Endpoints (Gateway or Interface):** VPC endpoints allow a VPC to access public AWS services like S3 or DynamoDB privately without a public gateway. VPC peering is for connecting two VPCs. Endpoints are for accessing specific services, while peering is for general network connectivity between VPCs. (Example: To access S3 from a private subnet, use a VPC endpoint. To connect a web server VPC to a database VPC, use VPC peering.)

## Commands

```
aws ec2 create-vpc-peering-connection --vpc-id vpc-0abcd1234 --peer-vpc-id vpc-0efgh5678 --peer-region eu-west-1
```
Creates a VPC peering connection between a local VPC and a VPC in a different region (inter-region peering). This is used for connecting VPCs across AWS regions.

*Exam note: Often tested in AWS Solutions Architect exams for global multi-VPC architectures. Remember that the --peer-region parameter is required for cross-region peering.*

```
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-12345678
```
Accepts a pending VPC peering connection request from another account or region. Required for cross-account or cross-region peering after the request is initiated.

*Exam note: Exams emphasize that the owner of the peer VPC must accept the peering request. Without acceptance, the connection stays in 'pending-acceptance' state.*

```
az network vnet peering create --name peer1 --resource-group my-rg --vnet-name vnet-a --remote-vnet /subscriptions/.../vnet-b --allow-vnet-access
```
Creates a VNet peering in Azure between two virtual networks. The --allow-vnet-access flag must be set to enable communication.

*Exam note: Azure exams test that peering must be configured on both sides (initiate and accept) and that the remote VNet ID is required. Also, overlapping address spaces cause failure.*

```
gcloud compute networks peerings create my-peering --network vpc-a --peer-network vpc-b --peer-project my-project
```
Creates a VPC peering in Google Cloud between two networks, possibly in different projects. The peer network must exist in the same or different project.

*Exam note: Google Cloud exams highlight that VPC peering is non-transitive and that you must configure firewall rules separately to allow traffic.*

```
aws ec2 create-route --route-table-id rtb-12345678 --destination-cidr-block 10.0.2.0/24 --vpc-peering-connection-id pcx-12345678
```
Adds a route to a route table to send traffic destined for the peer VPC's CIDR block through the peering connection.

*Exam note: A common exam task: you must add routes in both directions. Forgetting this leads to connectivity issues. Tests your understanding of route propagation.*

```
aws ec2 modify-vpc-peering-connection-options --vpc-peering-connection-id pcx-12345678 --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true
```
Enables DNS resolution for the peer VPC, allowing instances to resolve private DNS hostnames from the remote VPC.

*Exam note: Setting AllowDnsResolutionFromRemoteVpc is critical for cross-VPC communication using DNS names. Often a hidden prerequisite in exam scenarios.*

```
aws ec2 describe-vpc-peering-connections --filters Name=status-code,Values=active
```
Lists all active VPC peering connections. Useful for operational checks and troubleshooting.

*Exam note: Exams test the different states: 'pending-acceptance', 'active', 'failed', 'expired', 'deleted'. Knowing how to filter helps in isolation troubleshooting.*

## Troubleshooting clues

- **Peering connection stuck in 'pending-acceptance'** — symptom: The VPC peering connection shows status 'pending-acceptance' for an extended period and no traffic flows.. The owner of the peer VPC has not yet accepted the peering request. In cross-account or cross-region scenarios, acceptance is required explicitly. (Exam clue: Exam questions often present a situation where a peering request is not working because the administrator forgot to accept it from the other account.)
- **No network connectivity between instances in peered VPCs** — symptom: Instances in VPC A cannot ping or connect to instances in VPC B, even though the peering connection is 'active'.. Most likely, route tables in both VPCs are missing the appropriate routes pointing to the peering connection for the destination CIDR blocks. Also, security groups or network ACLs might be blocking traffic. (Exam clue: Classic exam trick: The peering is active but no routes added. Students must check route tables first.)
- **Overlapping CIDR blocks cause peering failure** — symptom: When attempting to create a VPC peering connection, the request fails with an error stating that the VPCs have overlapping CIDR blocks.. VPC peering does not support overlapping IP addresses because routing would be ambiguous. The two VPCs must have non-overlapping CIDR ranges. (Exam clue: Frequent exam scenario: An administrator tries to peer two VPCs that both use 10.0.0.0/16. The correct answer is that peering is not possible.)
- **Inter-region peering latency or throughput issues** — symptom: Traffic between peered VPCs in different regions has higher latency than expected or drops intermittently.. Inter-region traffic uses the global backbone, but distance and regional load can affect performance. Unlike intra-region, inter-region peering has data transfer costs and may be subject to bandwidth limits. (Exam clue: Exams may test that inter-region peering is not recommended for real-time sensitive applications without proper testing.)
- **DNS resolution fails across peered VPCs** — symptom: Instances in one VPC cannot resolve the private DNS names of instances in the peer VPC, even though the peering is active.. DNS resolution must be explicitly enabled for the peering connection. In AWS, you need to set 'AllowDnsResolutionFromRemoteVpc' to true on both sides. Also, the VPC DNS settings must be enabled. (Exam clue: Often overlooked in exam labs: DNS resolution is not automatic. Enabling DNS resolution for peering is a separate step.)
- **Transitive routing not working** — symptom: VPC A can communicate with VPC B, and VPC B with VPC C, but VPC A cannot reach VPC C directly.. VPC peering does not support transitive routing. Traffic from A to C must go through a direct peering connection or a transit gateway. (Exam clue: Extremely common exam scenario: The 'hub and spoke' design with VPC peering fails because you cannot route through an intermediate VPC.)
- **Security group referencing from peer VPC not working** — symptom: A security group in VPC A references a security group from VPC B in its inbound rule, but traffic is still blocked.. Security group referencing across peered VPCs works only if the peering connection is active and both VPCs are in the same region (for AWS). Also, the referenced security group must exist and be in the peer VPC. (Exam clue: Tested in advanced networking exams: cross-account security group references require the peering to be active and the security groups to be in the same region.)

---

Practice questions and the full interactive page: https://courseiva.com/glossary/vpc-peering