VPC peering connections provide a fast and secure solution for creating a private network connection between two virtual private clouds (VPCs) that are inherently isolated from each other.
Overview
VPC peering connections allow private network communication between VPCs within the same or different accounts, and across the same or different regions. Once a peering connection is established, cloud resources in the VPCs can communicate using private IPv4 or IPv6 addresses.
Scenarios
Secure access: VPC peering connections enhance security by allowing resources in different VPCs to communicate over a private network. This avoids Internet exposure and protects against common network attacks.
Multi-account connections: You can enable secure communication across VPCs in a multi-account architecture. This fosters collaboration among teams and enhances resource-sharing efficiency.
Disaster recovery: Leverages cross-region peering connections for data synchronization and backup. This ensures data redundancy, disaster recovery, and business reliability.
Requester and accepter
The two VPCs in a peering connection are the requester and the accepter.
Requester: Initiates the peering request.
Accepter: Awaits the peering request.
The two roles, requester and accepter, are solely for establishing a peering connection. After the peering connection is created, both VPCs can send and receive data as though they were part of the same network.
Status of a VPC peering connection
A VPC peering connection begins when the requester sends a connection request to the accepter and undergoes multiple phases, with each stage corresponding to a different status.
When the requester and accepter VPCs are both in the same Alibaba Cloud account, the peering connection request is automatically initiated and accepted, thus activating the connection upon establishment.
Status description
Billing
Intra-region connections: No fees are charged, regardless of whether they belong to the same or different accounts.
Inter-region connections: Data transfer fees are charged by Cloud Data Transfer (CDT) based on the outbound traffic.
Inter-region scenarios provide two types of connection, Platinum and Gold, each providing distinct service quality.
Link type | Service availability | Applicable scenarios |
Platinum | 99.995% | Businesses that are highly sensitive to jitters and latency and require high connection quality, such as securities trading, online voice, video conferencing, and real-time gaming. |
Gold | 99.95% | Businesses that are not sensitive to connection quality, such as data synchronization and file transfer. |
Billing example for inter-region connections
As shown in the image, Customer 1 created VPC1 in China (Hohhot), and Customer 2 set up VPC2 in China (Guangzhou). Consequently, an inter-region, cross-account peering connection between the two VPCs is established. According to outbound traffic billing rules, Customer 1 is billed for traffic sent to VPC2, and Customer 2 is billed for traffic sent to VPC1.
200 GB of data is transferred from VPC1 and 100 GB from VPC2 through the peering connection. When the link type is Gold, the inter-region traffic fees incurred for data transfer between China (Hohhot) and China (Guangzhou) is 0.072 USD/GB, customers are charged in the following ways:
Customer 1: USD 0.072/GB × 200 GB = USD 14.4
Customer 2: USD 0.072/GB × 100 GB = USD 7.2
Work with VPC peering connections
To establish a VPC peering connection for secure, private communication between two VPCs, you can follow the steps below. For more information, see Use VPC peering connection for private communication.
When using VPC peering connections to connect VPCs, ensure that you plan the network in advance to avoid overlapping CIDR blocks of the VPCs and vSwitches at both ends.
Create a VPC peering connection.
The requester sends a peering connection request to the accepter.
Activate the peering connection.
For a same-account VPC peering connection, the system automatically accepts the request and establishes a connection, without any action needed from the accepter.
For a cross-account VPC peering connection, the accepter can either accept or reject the request. The VPC peering connection is activated only when the request is accepted.
Configure routes at both ends of the peering connection for VPCs to communicate over a private network.
Select one of the following methods based on your needs:
Use the CIDR block of the peer VPC as the destination to grant full access to resources. Elastic Compute Service (ECS) instances can communicate with all resources in the vSwitches of the peer VPC, which simplifies management.
For enhanced security, use the CIDR block of the vSwitch in the peer VPC as the destination and limit the bandwidth of peering connection traffic.
ImportantIf the CIDR blocks of the two VPCs overlap:
If vSwitch CIDR blocks do not overlap, you can set the non-overlapping CIDR block of peer vSwitch as the destination. Ensure you avoid CIDR block conflict when deploying subsequent services.
Configuring the destination address to point to the peer VPC may cause routing issues. The system route will override the route established by the peering connection. This means that any traffic intended for the peer VPC will be misrouted internally within the requester VPC and will not reach the accepter.
If vSwitch CIDR blocks overlap, you cannot use the CIDR block of the peer vSwitch as the destination, because it is not possible to configure more specific routes than the system route.
Troubleshooting
Use CloudMonitor to collect metrics such as traffic bandwidth and packet loss for inter-region VPC peering connections. You can create alert rules to monitor the instance status in real-time, ensuring business stability.
For access issues with a VPC peering connection, use Network Intelligence Service (NIS) for bidirectional path analysis to diagnose configuration errors.
NoteNIS currently does not support simultaneous bidirectional path analysis. You can verify connectivity using Reverse Path Analysis.
Unreachable: Check the route configuration and ensure that the route table has an entry whose destination is the CIDR block of the peer VPC and the next hop is the VPC peering connection.
The request matches security group deny rules or is denied by default: Ensure the security group of the ECS instance in the VPC permits traffic from the peer VPC. Modify the inbound or outbound rules as necessary.
The request matches network ACL deny rules or is denied by default: Check if the network ACLs of vSwitches permit traffic from the peer VPC. Modify the inbound or outbound rules as necessary.
Limits
Feature limits
Only one VPC peering connection can be created between two VPCs at a time.
VPC peering connections do not support routing propagation. After establishing a VPC peering connection, you must manually configure route entries for both the requester and accepter to enable connectivity.
Assume that three VPCs are created, VPC1, VPC2, and VPC3. A peering connection is established between VPC1 and VPC2 and another between VPC2 and VPC3. Because VPC2 cannot function as a transit router, you must create a peering connection between VPC1 and VPC3, and configure route entries to connect them.
In a multi-account shared VPC scenario, the resource owner can create, modify, or delete a VPC peering connection. However, the principal does not have the permission to manage it.
Supported regions
Area | Region |
Asia Pacific | China (Hangzhou), China (Shanghai), China (Nanjing - Local Region), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Shenzhen), China (Heyuan), China (Guangzhou), China (Chengdu), China (Hong Kong), China (Wuhan - Local Region), China (Fuzhou - Local Region), Japan (Tokyo), South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), and Thailand (Bangkok). |
Europe & Americas | Germany (Frankfurt), UK (London), US (Silicon Valley), and US (Virginia). |
Middle East | UAE (Dubai) and SAU (Riyadh - Partner Region). Important The SAU (Riyadh - Partner Region) region is operated by a partner. |
Quotas
Name/ID | Description | Default value | Adjustable |
vpc_quota_cross_region_peer_num_per_vpc | Maximum number of inter-region VPC peering connections for each VPC | 20 | You can increase the quota by performing the following operations:
|
vpc_quota_intra_region_peer_num_per_vpc | Maximum number of intra-region VPC peering connections for each VPC | 10 | |
vpc_quota_peer_num | Maximum number of VPC peering connections that can be created by each account in each region | 20 | |
vpc_quota_peer_cross_border_bandwidth | Maximum bandwidth for cross-border VPC peering connections | 1,024 Mbps | |
vpc_quota_peer_cross_region_bandwidth | Maximum bandwidth for inter-region VPC peering connections | 1,024 Mbps | |
N/A | Default maximum bandwidth for intra-region connections | -1 Mbps, which indicates unlimited bandwidth | N/A |