VPC peering connection is a simple and fast solution for creating a private network connection when the number of VPCs is limited.
Introduction
A VPC peering connection is a network connection solution for two VPCs and supports IPv4 or IPv6. By facilitating the transfer of IPv4 or IPv6 traffic, the feature allows for private network connectivity between two VPCs in the same or different accounts, and in the same or different regions.
Requester and accepter
The two VPCs in a peering connection are the requester and the accepter. The requester initiates the peering request, while the accepter awaits the incoming request. These roles are solely for establishing the connection. After a VPC peering connection is established, both the requester and the accepter can send and receive data as if they were in the same network.
For a same-account VPC peering connection, the system automatically accepts the request from the requester and establishes a connection. The accepter does not need to accept the connection request.
For a cross-account VPC peering connection, the accepter can accept or reject the request. The VPC peering connection is activated only if the request is accepted.
Requester and accepter VPCs can be located in the same or different regions.
Status of a VPC peering connection
To establish a VPC peering connection, the requester sends a connection request to the accepter. After the request is accepted, the VPC peering connection is established.
For the same-account peering connection, the system automatically initiates and accepts the request, after which the peering connection is activated.
The following table describes the status of a VPC peering connection in different stages.
Status | Description |
Creating | The status after the requester sends a connection request. |
Peer Accepting | The status when the connection is waiting to be accepted by the accepter. |
Updating | The status after the accepter accepts the connection request. |
Activated | The status after the VPC peering connection is activated. |
Rejected | The status after the accepter rejects the connection request. |
Expired | The status after the connection request remains pending for more than seven days. |
Deleting | The status when the VPC peering connection is being deleted. |
Deleted | The status after the VPC peering connection is deleted. |
Billing
VPC peering incurs no charges if the two VPCs are in the same region. Otherwise, you are charged for outbound data transfer across regions. The fees are managed by Cloud Data Transfer (CDT). For more information, see Billing overview.
The Service-Level Agreement (SLA) guarantees a minimum availability of 99.95% for cross-region VPC peering.
Billing examples for peer connections across regions and accounts
As described in the preceding image, Customer 1 created VPC1 in China (Hohhot), and Customer 2 set up VPC2 in China (Guangzhou). A 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.
When 200 GB of data is transferred from VPC1 and 100 GB from VPC2 through the peering connection and the inter-region traffic fee incurred for data transfer between China (Hohhot) and China (Guangzhou) is 0.6 RMB/GB, the two customers are charged in the following ways:
Customer 1: CNY 0.6/GB × 200 GB = CNY 120
Customer 2: CNY 0.6/GB × 100 GB = CNY 60
Limits
Feature limits
VPC peering does not support routing propagation. After establishing a VPC peering connection, you must manually configure route entries for both the requester and accepter VPCs 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. In such a case, as VPC2 cannot function as a transit router, you need to create a peering connection between VPC1 and VPC3 and configure route entries to connect the two VPCs.
Before you create VPC peering connections, make sure that the CIDR blocks to be connected do not overlap with each other.
You cannot create VPC peering connections for shared VPCs.
Supported regions
Area | Regions |
Asia Pacific | Regions including 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), Hong Kong (China), China (Wuhan - Local Region), China (Fuzhou - Local Region), Japan (Tokyo), South Korea (Seoul), Singapore, Australia (Sydney) Closing down, Malaysia (Kuala Lumpur), Indonesia (Jakarta), and Philippines (Manila), and Thailand (Bangkok). |
Europe & America | 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. |
Quota
Name/ID | Description | Default value | Adjustable |
vpc_quota_cross_region_peer_num_per_vpc | Maximum number of inter-region VPC peering connections supported by 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 supported by each VPC | 10 | |
vpc_quota_peer_num | Maximum number of VPC peering connections supported by each Alibaba Cloud account in each region | 20 | |
vpc_quota_peer_cross_border_bandwidth | Maximum bandwidth supported by cross-border connections | 1024 Mbps | |
vpc_quota_peer_cross_region_bandwidth | Maximum bandwidth supported by inter-region connections | 1024 Mbps | |
N/A | Default maximum bandwidth for intra-region connections | -1 Mbit/s, which indicates unlimited bandwidth | No |