By default, VPCs are isolated from one another. To enable private network communication between them, you can create a peering connection and configure routes for both VPCs. Peering connections support same-account, cross-account, same-region, and cross-region connections. The CIDR blocks of the two VPCs must not overlap.
How it works
A VPC peering connection connects two VPCs over a private network, allowing resources in both VPCs to communicate using private IP addresses.
Create a VPC peering connection: For same-account VPCs, the system automatically accepts the request and establishes the connection. For cross-account VPCs, the owner of the receiving VPC must accept the connection request.
Configure bidirectional routes: To enable communication between resources, add a route to the route table of each VPC that points to the peer VPC.
To connect many VPCs with high bandwidth at a low cost, use VPC peering connections with Cloud Enterprise Network (CEN). For a comparison of the two, see VPC interconnection.
Configure a VPC peering connection
Console
Prerequisites:
Ensure that the CIDR blocks of the two VPCs do not overlap. If they overlap, you must migrate your workloads to VPCs with non-overlapping CIDR blocks.
If you are using a VPC peering connection for the first time, ensure that Cloud Data Transfer (CDT) is enabled for the accounts that own both VPCs.
Create a peering connection:
Navigate to the VPC Console - VPC Peering Connection page. In the top navigation bar, select the VPC's region, and then click Create VPC Peering Connection.
On the creation page, select the accepter account type and region type based on the accounts and regions of the two VPCs.
Accepter account type:
Same-Account: The system automatically accepts the request and establishes the connection. You can select the option to add a route for the peer VPC's cidr block to the VPC system route table. This action automatically configures bidirectional routes.
Cross-Account: The owner of the accepter account must navigate to the VPC Console - VPC Peering Connection page. Select the region where the accepter VPC is located. In the Actions column for the target VPC peering connection, click Accept.
The accepter can also Deny or Delete the connection request. For the complete workflow, see VPC peering connection states.
If the region type is Inter-Region, you must configure the Link Type and Accepter Region.
The Platinum and Gold link types are available. They provide different levels of data transfer quality and have different billing unit prices.
Platinum (Service Level Agreement: 99.995% availability): Suitable for workloads that are sensitive to network jitter and latency and require high link quality, such as securities trading, online voice calls, video conferencing, and real-time gaming.
Gold (Service Level Agreement: 99.95% availability): Suitable for workloads that are not sensitive to link quality, such as data synchronization and file transfers.
Configure bidirectional routes:
To enable communication over IPv6 addresses, you must configure route entries that point to the IPv6 cidr block of the peer VPC.
In the requester's account: In the Requester VPC column, click Configure route. Select the Route Tables for the vSwitch that contains the communicating resources. Set the Destination CIDR Block to the cidr block of the accepter VPC.
In the accepter's account: In the Accepter column, click Configure route. Select the Route Tables for the vSwitch that contains the communicating resources. Set the Destination CIDR Block to the cidr block of the requester VPC.
Verify connectivity:
Reachability Analyzer: The analysis does not send real data packets or affect your workloads.
In the Diagnose column of the target VPC peering connection, choose , or click the target VPC peering connection ID to navigate to the Reachability Analyzer tab.
Configure the source and destination, and specify the protocol and port number to simulate a specific access scenario and verify connectivity.
The system checks route, security group, and network ACL configurations and provides a diagnosis result.
If a one-way path is reachable, you must also configure and analyze the reverse path to verify bidirectional connectivity.
Manual test: From an ECS instance within the requester VPC, run the command
ping <private IP of an ECS instance in the peer VPC>.
Before using Reachability Analyzer, ensure that Network Intelligence Service (NIS) is activated. The system automatically creates the service-linked role AliyunServiceRoleForNis when you use this feature for the first time.
After you create an inter-region VPC peering connection, you can click its instance ID to Edit the Bandwidth (Mbit/s) and Link Type.
Either account can delete the VPC peering connection. Deletion immediately interrupts private communication and is irreversible. Before you proceed, ensure this action does not impact your workloads.
API
Create peering connection
Call CreateVpcPeerConnection to create a VPC peering connection.
If the two VPCs belong to different accounts, the owner of the accepter account must call AcceptVpcPeerConnection to accept the VPC peering connection.
The accepter can also call RejectVpcPeerConnection to reject the VPC peering connection.
From each account, call GetVpcPeerConnectionAttribute to query the cidr block of the other VPC.
From each account, call CreateRouteEntry to create route entries that point to the peering connection.
Modify inter-region peering connection
Call ModifyVpcPeerConnection to modify the bandwidth or link type of an inter-region VPC peering connection.
Delete peering connection
Call DeleteRouteEntry to delete the route entries that point to the peering connection.
Call DeleteVpcPeerConnection to delete the VPC peering connection.
Reachability Analyzer
Call the following API operations in sequence to use Reachability Analyzer to verify connectivity.
Terraform
Same-account peering connection
Resources: alicloud_vpc_peer_connection, alicloud_route_entry
Data Sources: alicloud_account
# The account that owns the VPC.
data "alicloud_account" "default" {}
provider "alicloud" {
alias = "local"
region = "cn-hangzhou" # The region of the requester VPC.
}
provider "alicloud" {
alias = "accepting"
region = "cn-beijing" # The region of the accepter VPC. This can be the same as the requester region.
}
# The ID of the requester VPC.
variable "local_vpc_id" {
default = "vpc-bp1c******"
}
# The ID of the accepter VPC.
variable "accepting_vpc_id" {
default = "vpc-2zev******"
}
# Create a VPC peering connection.
resource "alicloud_vpc_peer_connection" "example_peer_connection" {
provider = alicloud.local
peer_connection_name = "example_peer_connection_name"
vpc_id = var.local_vpc_id # The ID of the requester VPC.
accepting_ali_uid = data.alicloud_account.default.id # The ID of the accepter account.
accepting_region_id = "cn-beijing" # The region of the accepter VPC.
accepting_vpc_id = var.accepting_vpc_id # The ID of the accepter VPC.
bandwidth = 1024 # The bandwidth in Mbps. You can configure this parameter only for inter-region connections.
link_type = "Gold" # The link type. You can configure this parameter only for inter-region connections.
}
# Configure a route for the requester VPC.
resource "alicloud_route_entry" "example_local_route" {
provider = alicloud.local
route_table_id = "vtb-bp1a******" # The route table associated with the vSwitch of the requester instance.
destination_cidrblock = "172.16.0.0/12" # The cidr block of the accepter VPC.
nexthop_type = "VpcPeer" # The next hop is a VPC peering connection.
nexthop_id = alicloud_vpc_peer_connection.example_peer_connection.id
}
# Configure a route for the accepter VPC.
resource "alicloud_route_entry" "example_acceptor_route" {
provider = alicloud.accepting
route_table_id = "vtb-2ze1******" # The route table associated with the vSwitch of the accepter instance.
destination_cidrblock = "10.0.0.0/8" # The cidr block of the requester VPC.
nexthop_type = "VpcPeer" # The next hop is a VPC peering connection.
nexthop_id = alicloud_vpc_peer_connection.example_peer_connection.id
}
Cross-account peering connection
Resources: alicloud_vpc_peer_connection, alicloud_vpc_peer_connection_accepter, alicloud_route_entry
provider "alicloud" {
alias = "local"
region = "cn-hangzhou" # The requester region.
}
# The accepter region. This can be the same as the requester region.
variable "accepting_region" {
default = "cn-beijing"
}
# The accepter account.
variable "accepting_uid" {
default = "1234******"
}
# The AccessKey ID of the accepter account.
variable "access_key_id" {
description = "The AccessKey ID for operating your infrastructure"
}
# The AccessKey secret of the accepter account.
variable "access_key_secret" {
description = "The AccessKey Secret for managing your infrastructure"
}
provider "alicloud" {
alias = "acceptor"
region = var.accepting_region
access_key = var.access_key_id
secret_key = var.access_key_secret
}
# The ID of the requester VPC.
variable "local_vpc_id" {
default = "vpc-2ze0******"
}
# The ID of the accepter VPC.
variable "accepting_vpc_id" {
default = "vpc-wz9e******"
}
# Create a VPC peering connection.
resource "alicloud_vpc_peer_connection" "example_peer_connection" {
provider = alicloud.local
peer_connection_name = "example_peer_connection_name"
vpc_id = var.local_vpc_id # The ID of the requester VPC.
accepting_ali_uid = var.accepting_uid # The ID of the accepter account.
accepting_region_id = var.accepting_region # The accepter region.
accepting_vpc_id = var.accepting_vpc_id # The ID of the accepter VPC.
bandwidth = 1024 # The bandwidth in Mbps. You can configure this parameter only for inter-region connections.
link_type = "Gold" # The link type. You can configure this parameter only for inter-region connections.
}
# The accepter accepts the peering connection request.
resource "alicloud_vpc_peer_connection_accepter" "example_peer_connection_accepter" {
provider = alicloud.acceptor
instance_id = alicloud_vpc_peer_connection.example_peer_connection.id
}
# Configure a route for the requester VPC.
resource "alicloud_route_entry" "example_local_route" {
provider = alicloud.local
route_table_id = "vtb-2zel******" # The route table associated with the vSwitch of the requester instance.
destination_cidrblock = "192.168.0.0/24" # The cidr block of the accepter VPC.
nexthop_type = "VpcPeer" # The next hop is a VPC peering connection.
nexthop_id = alicloud_vpc_peer_connection.example_peer_connection.id
}
# Configure a route for the accepter VPC.
resource "alicloud_route_entry" "example_acceptor_route" {
provider = alicloud.acceptor
route_table_id = "vtb-wz95******" # The route table associated with the vSwitch of the accepter instance.
destination_cidrblock = "172.16.0.0/12" # The cidr block of the requester VPC.
nexthop_type = "VpcPeer" # The next hop is a VPC peering connection.
nexthop_id = alicloud_vpc_peer_connection.example_peer_connection.id
}
Troubleshoot network connectivity
We recommend using Reachability Analyzer to verify network connectivity.
Check item | Description | Solution |
Peering connection status | Verify that the target peering connection Status is Activated. | If the status is Accepting, contact the accepter to accept the connection request. |
CIDR block configuration | Check the CIDR blocks of the requester and accepter VPCs for the following issues:
|
|
Route configuration | On the details page of the peering connection, check the Route Entry List:
| Check and correct the bidirectional route configuration. |
Access rule configuration |
| Ensure that security groups, network ACLs, and the allowlists of all cloud services allow traffic from the peer IP address. |
Configuration examples
Connect three VPCs
When configuring routes for VPC peering, you have the following options:
Set the destination CIDR block to the peer VPC's CIDR block. This allows all instances in both VPCs to communicate with each other and simplifies management.
Configure more specific routes by setting the destination CIDR block to a vSwitch's CIDR block in the peer VPC or the IP address of a specific instance. This enhances security but requires you to manually update the route table when new instances need to communicate.
For example, routes in VPC1 point to the CIDR block of vSwitch 3 in VPC2 and the ECS instance ECS04 in VPC3. Therefore, resources in VPC1 can only communicate privately with resources in vSwitch 3 and ECS04. In contrast, routes in VPC2 and VPC3 point to their peer VPCs' CIDR blocks, allowing full communication between their resources.
Migrate from CEN to a VPC peering connection
Switch private network communication between two VPCs from Cloud Enterprise Network (CEN) to a VPC peering connection. Use this example when only pairwise connectivity between the two VPCs is required and you want a simpler topology at a lower cost. In a cross-account scenario, each account performs the operations for its own VPC.
Prerequisites
The CIDR blocks of the two VPCs do not overlap.
You have confirmed that the two VPCs currently communicate through CEN, and you have recorded the existing route entries of both VPCs so that you can restore them.
Procedure
Create the VPC peering connection. On the VPC Console - VPC Peering Connection page, the requester clicks Create VPC Peering Connection and enters the peer account ID and the peer VPC information. For a cross-account connection, the accepter account clicks Accept for the connection request. Continue only after the connection is established.
Remove the route entries that point to CEN. On the VPC Console - Route Tables page, open the Route Tables of both VPCs and locate the route entries whose next hop is Transit Router (CEN Enterprise Edition) or whose type is CEN (CEN Basic Edition). Route entries that you added manually can be deleted directly. Route entries that CEN advertises to the VPC automatically cannot be deleted on this page; they are withdrawn after you detach the network instance connection of the VPC on the CEN side.
Add the route entries that point to the VPC peering connection. In the route table of each VPC, click Add Route Entry, set Destination CIDR Block to the CIDR block of the peer VPC (you can also narrow it to a vSwitch CIDR block or the IP address of a specific instance in the peer VPC), set Next Hop Type to VPC Peering Connection, and select the peering connection instance that you created.
Verify the result. In the Route Entry List of both VPCs, confirm that the new route entries pointing to the peering connection are available and that no route entry still points to CEN, and then verify private network communication between resources in the two VPCs.
Service interruption assessment
Private network communication between the two VPCs is interrupted from the moment the CEN route entries are removed until the new route entries take effect. The duration depends on how long the route switchover takes, so perform the operation during off-peak hours.
Create and accept the peering connection before you switch the route entries, so that only the route switchover falls inside the interruption window.
Keep the original CEN configuration until you have verified the switchover, so that you can restore the original route entries and roll back quickly.
Connect multiple VPCs to a central VPC
For example, branch VPCs can access services deployed in the central VPC, but the branch VPCs cannot communicate with each other. Typical scenarios include:
Multi-department isolation: VPCs for different business departments cannot communicate with each other but must access shared services in the central VPC.
Multi-user isolation: Services are deployed in a dedicated VPC for multiple users. The VPC of each user can communicate with the service VPC, but the VPCs of different users cannot communicate with each other.
Restrict unauthorized cross-account connections
By default, a RAM user with the vpc:CreateVpcPeerConnection and vpc:AcceptVpcPeerConnection permissions can establish a VPC peering connection with any account. To restrict RAM users to connecting only with accounts within your organization or with specified peer accounts and prevent sensitive data from leaking through unauthorized cross-account network channels, use global Condition Keys such as acs:TargetRDId and acs:TargetRDPath in RAM custom policies to constrain which peer accounts are allowed.
Condition Key
During authorization, RAM looks up the resource directory of the peer account based on AcceptingAliUid (when creating a peering connection) or RequestingAliUid (when accepting a peering connection), and injects the following Condition Keys into the authorization context for matching against conditions in your custom policy.
Condition Key | Type | Description | Use case |
| String | The resource directory ID to which the peer account belongs, for example, | Require that the peer account belongs to a specified resource directory. |
| String | The resource directory path to which the peer account belongs, in the format | Require that the peer account is under a specified folder in the resource directory, enabling hierarchical governance. |
Usage constraints:
Onlyvpc:CreateVpcPeerConnectionandvpc:AcceptVpcPeerConnectioninject the above Condition Keys. Other operations on peering connections, such as query, modify, and delete, are not affected.
When a request is denied by the policy, the error codeForbidden.NoPermissionis returned withNoPermissionTypeset toExplicitDeny. You can use the RequestId to trace the policy match in ActionTrail.
Select a restriction policy
When configuring policies, replace the resource directory ID, path, or account ID in the examples with the actual values for your organization. You can find the resource directory ID and path in the Resource Management console.
By resource directory ID
Allow RAM users to create VPC peering connections only with accounts in the specified resource directory. Replace rd-xxxxxx with your resource directory ID.
{
"Version": "1",
"Statement": [
{
"Effect": "Deny",
"Action": [
"vpc:CreateVpcPeerConnection",
"vpc:AcceptVpcPeerConnection"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"acs:TargetRDId": ["rd-xxxxxx"]
}
}
}
]
}By resource directory path
Allow RAM users to create VPC peering connections only with accounts under a specified folder path. This is suitable for fine-grained hierarchical governance. Replace the path in the example with your actual path.
{
"Version": "1",
"Statement": [
{
"Effect": "Deny",
"Action": [
"vpc:CreateVpcPeerConnection",
"vpc:AcceptVpcPeerConnection"
],
"Resource": "*",
"Condition": {
"StringNotLike": {
"acs:TargetRDPath": ["rd-xxxxxx/r-xxxxxx/fd-xxxxxx/*"]
}
}
}
]
}Create and attach the policy
Console
Log on to the RAM console. In the left-side navigation pane, choose Permissions > Policies.
Click Create Policy. On the JSON Editor tab, paste the policy from the scheme you selected above. Replace the resource directory ID, path, or account ID with your actual values.
Click OK, enter the Policy Name, and click OK.
Attach the policy to the target RAM user, user group, or role.
API
Call CreatePolicy to create a custom policy. Pass the policy from the scheme you selected above as the
PolicyDocumentparameter.Call AttachPolicyToUser, AttachPolicyToGroup, or AttachPolicyToRole to attach the policy to the target RAM user, user group, or role.
Monitoring and O&M
For inter-region peering connections, you can monitor metrics such as traffic, bandwidth, and packet loss. Use CloudMonitor to create threshold-based alert rules to monitor the connection status in real time and promptly address network congestion or failures.
Metrics are not available for intra-region peering connections.
Console
Peering connection monitoring
Go to the VPC Console - VPC Peering Connections page. In the top navigation bar, select the region where the VPC is located.
In the Monitor column of the target inter-region VPC peering connection instance, click the
icon to view metrics such as traffic, bandwidth, and packet loss.
CloudMonitor alerts
Go to the CloudMonitor Console - Alert Rules page and click Create Alert Rule.
Configure thresholds for each alert level for the VPC peering connection metrics. When a metric reaches its threshold, the Alert Contact Group receives notifications. You can also click Alert History in the Actions column of an alert rule to view its alert timeline.
From the Actions column for an alert rule, you can Modify, Disable, or Delete it.
API
Call PutResourceMetricRules to set threshold-based alert rules for VPC peering connection metrics. For a list of supported metrics, see CloudMonitor metrics for peering connections.
Call EnableMetricRules to enable one or more alert rules.
Call DisableMetricRules to disable one or more alert rules.
Call DeleteMetricRules to delete one or more alert rules.
Terraform
To configure threshold-based alert rules, see the list of available metrics in CloudMonitor metrics for peering connections.
Resources: alicloud_cms_alarm_contact, alicloud_cms_alarm_contact_group, alicloud_cms_alarm
# The ID of the peering connection instance to monitor
variable "vpc_peer_id" {
default = "pcc-28cv******"
}
# Create an alert contact
resource "alicloud_cms_alarm_contact" "example_cms_alarm_contact" {
alarm_contact_name = "example_cms_alarm_contact_name"
describe = "example_vpc_peer_alarm"
channels_mail = "xxx@xxx.com" # Replace with your email address
lifecycle {
ignore_changes = [channels_mail]
}
}
# Create an alert contact group
resource "alicloud_cms_alarm_contact_group" "example_cms_alarm_contact_group" {
alarm_contact_group_name = "example_cms_alarm_contact_group"
contacts = [alicloud_cms_alarm_contact.example_cms_alarm_contact.id] # Alert contact
}
# Create an alert rule
resource "alicloud_cms_alarm" "example_cms_alarm" {
name = "example_cms_alarm_name"
project = "acs_vpcpeer" # The data namespace of the cloud service
metric = "IntranetRX" # The metric name
period = 60 # The statistical period
contact_groups = [alicloud_cms_alarm_contact_group.example_cms_alarm_contact_group.alarm_contact_group_name]
effective_interval = "06:00-20:00" # The effective period
metric_dimensions = <<EOF
[
{
"instanceId": "${var.vpc_peer_id}"
}
]
EOF
escalations_critical { # Defines the critical-level alert
statistics = "Sum" # The statistical method for the alert
comparison_operator = ">=" # The comparison operator for the threshold
threshold = 104857600 # The threshold
times = 2 # The number of consecutive periods the threshold must be met to trigger the alert
}
}FAQ
Are cross-border peering connections supported?
Yes. Both non-cross-border and cross-border connectivity are supported.
Non-cross-border: Connects two regions in the Chinese mainland, or two regions outside the Chinese mainland.
Cross-border: Connects a region in the Chinese mainland to a region outside the Chinese mainland.Ensure that your account has completed business identity verification.
Cannot select the target VPC
Ensure that the selected region and account match the Region and Owner of the target VPC.
The requester region is displayed at the top of the page, and the current account is the requester. You specify the accepter account and region when you create the peering connection.
ECS with Docker communication failure
If your routing and security group configurations are correct, the issue is likely a conflict between the CIDR block of the Docker network interface and the destination CIDR block. Run ip addr to check whether the Docker network interface address conflicts with the destination CIDR block.
If a conflict exists, follow these steps to modify the Docker CIDR block.
Stopping the Docker service or modifying its CIDR block interrupts your workloads. We recommend that you perform this operation during off-peak hours.
When you modify the Docker CIDR block, ensure that it is compatible with the networking settings of any existing containers and applications to avoid potential connectivity issues.
Run
sudo systemctl stop dockerto stop the Docker service.Run
sudo vim /etc/docker/daemon.jsonto edit the Docker configuration file. Add the following content to the file and save your changes:The Docker configuration file is typically located at
/etc/docker/daemon.jsonor/etc/docker/daemon.conf. The exact filename may vary.{ "bip":"new Docker CIDR block" }Run
sudo systemctl start dockerto start the Docker service and apply the changes.
RAM user receives a CDT permission error when creating a VPC peering connection
A RAM user has been granted the AliyunVPCFullAccess permission but receives an error indicating that the cdt:GetCdtServiceStatus permission is missing when creating a VPC peering connection. This occurs because VPC peering connections depend on the Cloud Data Transfer (CDT) service and require calls to CDT-related APIs. VPC permissions alone are insufficient.
Grant the RAM user one of the following permissions:
AliyunCDTFullAccess: Full access to CDT.AliyunCDTReadOnlyAccess: Read-only access to CDT. This is suitable if the RAM user only needs to create peering connections and does not need to manage CDT resources.
Does a VPC peering connection affect public network access?
No. A VPC peering connection only adds private route entries and does not modify the default route. Public network traffic continues to be forwarded through existing NAT gateways, Elastic IP addresses, and other public routes.
More information
Limitations
You cannot create a VPC peering connection in the following scenarios:
The two VPCs belong to accounts on different Alibaba Cloud sites, for example, an account on the Alibaba Cloud China site and an account on the Alibaba Cloud International site.
A VPC peering connection does not support transitive routing.
For example, if VPC 1 is connected to VPC 2 and VPC 3 through separate VPC peering connections, VPC 2 and VPC 3 cannot communicate with each other through VPC 1.
To enable communication between VPC 2 and VPC 3, you must create a separate peering connection between them and configure bidirectional routes.
When a VPC is shared across multiple accounts, only the resource owner can create, modify, or delete a VPC peering connection. Resource users cannot perform these actions.
Billing
Intra-region VPC peering connections are free of charge, regardless of whether the VPCs belong to the same or different accounts.
For inter-region VPC peering connections, Cloud Data Transfer (CDT) charges a data transfer fee based on outbound traffic.
The unit price is determined by the region pair and link type. Platinum and Gold link types are available, which offer different service levels.
The billing cycle is hourly. If you switch the link type within a billing cycle, the rate for the higher service level applies for that entire cycle.
As shown in the figure, an inter-region, cross-account VPC peering connection is established between VPC1 and VPC2. If the outbound traffic from VPC1 and VPC2 is 200 GB and 100 GB respectively, the link type is Gold, and the data transfer fee from China (Hohhot) to China (Guangzhou) is USD 0.072/GB, the fees are calculated based on the outbound traffic billing rule:
Fee for Account A: USD 0.072/GB × 200 GB = USD 14.4
Fee for Account B: USD 0.072/GB × 100 GB = USD 7.2
VPC peering connection lifecycle
After a requester sends a creation request, a VPC peering connection transitions through several states.
If you create a same-account VPC peering connection, the system automatically initiates and accepts the request, and the connection becomes Activated.
States
Supported regions
Area | Regions |
Asia Pacific - China | China (Hangzhou), China (Shanghai), China (Nanjing - Local Region, Closing Down), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Shenzhen), China (Heyuan), China (Guangzhou), China (Chengdu), China (Zhongwei), China (Hong Kong), China (Wuhan - Local Region), and China (Fuzhou - Local Region - Closing Down) |
Asia Pacific - Other | Japan (Tokyo), South Korea (Seoul), Singapore (Singapore), Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok), and Malaysia (Johor Bahru) |
Europe & Americas | Germany (Frankfurt), UK (London), US (Silicon Valley), US (Virginia), and Brazil (São Paulo) |
Middle East | UAE (Dubai) and Saudi Arabia (Riyadh - Partner Region) |
Quotas
Quota name | Description | Default quota | Actions |
vpc_quota_cross_region_peer_num_per_vpc | The number of inter-region VPC peering connections per VPC. | 20 | To request a quota increase, go to the Quota Management page or Quota Center. |
vpc_quota_intra_region_peer_num_per_vpc | The number of intra-region VPC peering connections per VPC. | 10 | |
vpc_quota_peer_num | The number of VPC peering connections per Alibaba Cloud account per region. | 20 | |
vpc_quota_peer_cross_border_bandwidth | The maximum cross-border bandwidth. | 1,024 Mbps | |
vpc_quota_peer_cross_region_bandwidth | The maximum cross-region bandwidth. | 1,024 Mbps |