After creating a peering connection, you must correctly configure routes to ensure that resources in the virtual private clouds (VPCs) can communicate with each other using private IPv4 or IPv6 addresses.
Scenarios
Scenario | Configuration |
Designate the CIDR block of the peer VPC as the destination CIDR block to enable full access to resources in the connected VPCs. | |
| |
Connect VPCs using peering connections when CIDR blocks overlap | Set the non-overlapping CIDR blocks of vSwitch as the destination CIDR blocks. This enables partial access to resources in the connected VPCs. |
The route entries configured for VPC peering connections consume the custom route quotas. Consider this limit in network planning if you need to create peering connections among multiple VPCs.
Full communication among VPCs using peering connections
A VPC peering connection is a feature that connects two VPCs and supports both IPv4 and IPv6 traffic. By enabling IPv4 or IPv6 communication through VPC peering connections, you can enable private connections between VPCs in either the same or different accounts, and in either the same or different regions. You can also configure route entries to point to the CIDR block of the peer VPC to enable full access to cloud resources, which means that any resources in the connected VPCs can access those in the peer. This enables seamless communication and streamlines management.
Connect two VPCs
In this example, a peering connection (pcc-aaabbb) is created between VPC A and VPC B. Their CIDR blocks do not overlap.
VPC A is deployed for the business department, while VPC B for the finance department. You can configure routes as follows to achieve full access to all resources in the peer VPC and allow for resource sharing.
When both VPC A and VPC B are allocated an IPv6 CIDR block, the route tables can accommodate both IPv4 and IPv6 entries for the connected VPC at the same time. Depending on your requirements, you can choose either IPv4 or IPv6 communication.
Route table | Destination address | Next hop |
VPC A | 172.16.0.0/16 | pcc-aaabbb |
2408:XXXX:XXXX:3f00::/56 | pcc-aaabbb | |
VPC B | 192.168.0.0/16 | pcc-aaabbb |
2408:XXXX:XXXX:4000::/56 | pcc-aaabbb |
Connect three VPCs
In this example, peering connections are set up between each pair of VPCs. This enables interconnectivity and resource sharing among the VPCs.
Assume VPC A and VPC B are assigned an IPv6 CIDR block and VPC C is not. VPC A and B can establish IPv6 communication through the peering connection, while VPC C is unable to connect with VPC A or B over IPv6.
Route table | Destination address | Next hop |
VPC A | 172.16.0.0/16 | pcc-aaabbb |
2408:XXXX:XXXX:3f00::/56 | pcc-aaabbb | |
10.1.0.0/16 | pcc-aaaccc | |
VPC B | 192.168.0.0/16 | pcc-aaabbb |
2408:XXXX:XXXX:4000::/56 | pcc-aaabbb | |
10.1.0.0/16 | pcc-bbbccc | |
VPC C | 192.168.0.0/16 | pcc-aaaccc |
172.16.0.0/16 | pcc-bbbccc |
Connect more than three VPCs
Peering connections are created between each pair of VPCs to allow each to communicate and share resources with the others. An example of connecting five VPCs is shown below:
As illustrated in the figure, peering connections are established between each pair of the five VPCs. The number of peering connections can be calculated by the formula N*(N-1)/2. In this example, N equals 5, resulting in a total of 10 peering connections. Routes pointing to each VPC peering connection are set up for each VPC to enable inter-VPC communication. All VPCs are assigned IPv6 CIDR blocks, and the route configurations are as follows.
As the number of VPCs increases, managing VPC peering connections and route entries becomes more complex. For example, enabling communication between each pair of 10 VPCs requires 45 peering connections and configuring nine routes for each VPC. Therefore, when you need to connect more than 10 VPCs, we recommend using Cloud Enterprise Network (CEN) to simplify configuration.
Route configuration for connecting multiple VPCs
Connect multiple VPCs and a central VPC using peering connections
When you deploy services, you can plan separate VPCs for different services or branches to maintain security. These VPCs must connect to a central VPC for resource sharing. Consider the following scenarios:
Each department in a company is assigned a VPC that does not permit inter-departmental communication. However, these departments require access to central services, such as file sharing and middleware applications, which are deployed in a central VPC.
A company provides services to multiple users, with the services hosted in a dedicated service VPC. Each VPC is connected with the service VPC, while maintaining isolation from other user VPCs.
A single VPC supports a limited number of peering connections with a maximum of 10 intra-region and 20 inter-region connections.
The figure above shows a company with four branches and a central department in which all the services are deployed. The company requires each branch to access services in the central department while maintaining independence from one another. You can create VPC peering connections and configure routes for the branch VPCs to point to the peering connections. The route configuration is as follows:
Routes configurations for connecting multiple VPCs with the central VPC
Connect multiple VPCs using peering connections and transit routers
The following table compares the VPC peering connections and transit routers:
Item | Peering connection | Transit router |
Connection type | Full mesh. Each VPC is connected to every other VPC. | Hub-spoke. Each VPC is connected to the transit router. |
Route advertisement | Not supported | Supported |
Configuration complexity | High. You must set up peering connections between each pair of VPCs and configure routes to point to each peering connection. | Low. You only need to connect VPCs to a transit router and configure routes pointing to the transit router. |
Maximum number of VPCs supported | 10 | 1,000 |
Billing rules | Intra-region peering connections are free, whereas inter-region connections incur outbound data transfer fees. | Instance and data transfer fees apply. You are charged for outbound bandwidth fees for inter-region connections. |
VPC peering connections offer advantages such as low latency and no inter-region data transfer charges. However, they require point-to-point connection and route configuration, which significantly increases complexity as the number of VPCs rises. Therefore, VPC peering connections are not suitable for scenarios with many fully interconnected VPCs.
Conversely, configuring transit routers is simpler. By adopting a hub-spoke topology, you can easily connect VPCs to the transit router, which will automatically synchronize routes. Various routing policies and quality of service (QoS) mechanisms are also available to achieve sophisticated networking and access management. However, transit routers are subject to bandwidth constraints and incur higher expenses than peering connections due to data transfer fees.
Neither VPC peering connections nor transit routers alone can satisfy the demands for intricate networking, high bandwidth, and cost efficiency. You can combine the two solutions to address multifaceted requirements.
Consider a company with multiple VPCs across various regions that require not only interconnectivity, but also routing policy management and cost reduction.
To enable communication among VPCs in the same region, you can create VPC peering connections. No fees are generated, and the network latency is low.
To enable communication among VPCs in different regions, you can use a transit VPC to connect the VPCs to a transit router. Transit routers also support routing policies that help you implement fine-grained routing.
For VPCs that are deployed in different regions and require high bandwidth, you can create inter-region VPC peering connections. In this example, an inter-region VPC peering connection is created.
Connect VPCs using peering connections when CIDR blocks overlap
When the CIDR blocks of two VPCs overlap, you can configure partial resource communication as follows.
We recommend that you plan the network in advance and deploy services that need to communicate in VPCs with non-overlapping CIDR blocks to prevent address conflicts.
Configure the vSwitch CIDR block as the destination CIDR block to enable partial communication. When deploying subsequent services, you must avoid address conflicts between new and existing vSwitches.
Partial communication when CIDR blocks overlap
Non-overlapping CIDR blocks of vSwitches
When two VPCs have overlapping CIDR blocks, if you set the CIDR block of VPC B as the destination, this results in a conflict where the system route 10.2.0.0/24 and the destination 10.2.0.0/20 overlap. Traffic from VPC A to B will first match the system route, preventing it from reaching VPC B. To facilitate communication between resources across vSwitches, you mustnfigure non-overlapping CIDR blocks, such as 10.2.1.0/24, 10.2.2.0/24, and 10.2.3.0/24 as the destination for both VPCs.
Overlapping CIDR blocks of vSwitches
When the CIDR blocks of vSwitches that need to communicate overlap, communication issues may arise. For example, VPC A has a more specific route 10.2.0.0/26 than the system route 10.2.0.0/24. The system route of VPC B 10.2.0.0/26 overlaps with the destination 10.2.0.0/24. Traffic from VPC B to A will first match the system route, preventing it from reaching VPC A. Therefore, you cannot set the CIDR block of the peer vSwitch as the destination and the two VPCs cannot establish communication.
