All Products
Search
Document Center

Virtual Private Cloud:VPC peering connection

Last Updated:Aug 21, 2026

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.

  1. 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.

  2. Configure bidirectional routes: To enable communication between resources, add a route to the route table of each VPC that points to the peer VPC.

image

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

  1. Prerequisites:

    1. 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.

    2. 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.

  2. Create a peering connection:

    1. 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.

    2. 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.

  3. 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.
    1. 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.

    2. 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.

  4. Verify connectivity:

    • Reachability Analyzer: The analysis does not send real data packets or affect your workloads.

      1. In the Diagnose column of the target VPC peering connection, choose Diagnose > Reachability Analyzer, or click the target VPC peering connection ID to navigate to the Reachability Analyzer tab.

      2. Configure the source and destination, and specify the protocol and port number to simulate a specific access scenario and verify connectivity.

      3. The system checks route, security group, and network ACL configurations and provides a diagnosis result.

      4. 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
  1. Call CreateVpcPeerConnection to create a VPC peering connection.

  2. 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.
  3. From each account, call GetVpcPeerConnectionAttribute to query the cidr block of the other VPC.

  4. 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
Reachability Analyzer

Call the following API operations in sequence to use Reachability Analyzer to verify connectivity.

  1. Create a network analysis path

  2. Create a network reachability analysis task

  3. Get the result of a network reachability analysis task

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:

  1. Overlapping CIDR blocks.

  2. Use of non-RFC 1918 private CIDR blocks (such as 198.19.0.0/16 or 30.0.0.0/8). A VPC treats these CIDR blocks as public addresses. When an ECS instance has a public IP address, traffic to these destinations is routed through the public network by default.

  3. Conflicts with Docker network interface addresses when Docker is deployed on an ECS instance.

  1. If CIDR blocks overlap, migrate your workloads to VPCs with non-overlapping CIDR blocks and then create a new peering connection.

  2. If non-RFC 1918 private CIDR blocks are used, use an IPv4 Gateway to enable private use of public IP addresses to ensure that traffic is correctly routed to the destination VPC.

  3. Modify the Docker CIDR block.

Route configuration

On the details page of the peering connection, check the Route Entry List:

  1. A route entry that points to the peer VPC is configured for each VPC.

  2. The destination CIDR block is correctly set to the CIDR block of the peer VPC.

  3. The route entry is added to the route table for the vSwitch where your resources are deployed.

Check and correct the bidirectional route configuration.

Access rule configuration

  1. The inbound and outbound rules of the security groups for the communicating ECS instances allow traffic from the peer IP address.

  2. The peer IP address is in the allowlists of cloud services such as RDS, Redis, MongoDB, and Elasticsearch.

  3. The inbound and outbound rules of the network ACL associated with the vSwitch allow traffic from the peer IP address.

Ensure that security groups, network ACLs, and the allowlists of all cloud services allow traffic from the peer IP address.

Why CIDR block configuration can cause connectivity failure

  1. Overlapping CIDR blocks:

    If the CIDR blocks of the peered VPCs overlap and you configure the peer VPC's CIDR block as the destination, traffic matches the local system route first. As a result, the traffic is routed within the local VPC and cannot reach the peer VPC.

    1. Although you can configure a route to a non-overlapping peer vSwitch CIDR block, this approach is difficult to scale. Any new vSwitch that you create must also use a CIDR block that does not overlap with existing vSwitch CIDR blocks, which complicates network planning. We recommend that you migrate your workloads to a VPC with a non-overlapping CIDR block and create a new peering connection.

      image
    2. If the vSwitch CIDR blocks overlap, you cannot configure a route that is more specific than the system route. In this case, you must migrate your workloads to a VPC with a non-overlapping CIDR block and create a new peering connection.

      image
  2. Non-RFC 1918 private CIDR blocks:

    A VPC treats any IP address space outside of RFC 1918 (for example, 30.0.0.0/16) as a public CIDR block. If resources in the VPC have access to the internet, traffic destined for this address space is routed to the internet instead of through the peering connection. You must use an IPv4 Gateway to enable private use of public IP addresses to ensure that the traffic is correctly routed to the destination VPC.

Multiple route table troubleshooting

When multiple route tables exist in the same VPC, note the following:

  • Route entries must be added to the route table associated with the vSwitch where the ECS instance is deployed, not just the system route table.

  • If a vSwitch is associated with a custom route table, route entries in the system route table do not take effect for that vSwitch.

If you create a custom route table and associate a vSwitch with it, but only add a route entry pointing to the peering connection in the system route table without adding it to the custom route table, ECS instances in that vSwitch cannot reach the peer VPC.

Troubleshooting steps:

  1. Go to the VPC Console - Route Tables page. Find the custom route table associated with the vSwitch and click its route table ID.

  2. On the Custom Route tab, check whether a route entry pointing to the peering connection exists for the destination CIDR block. If not, click Add Route Entry, enter the peer vSwitch CIDR block, set Next Hop Type to VPC Peering Connection, and select the corresponding peering connection instance.

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.

image

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

image

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

acs:TargetRDId

String

The resource directory ID to which the peer account belongs, for example, rd-xxxxxx.

Require that the peer account belongs to a specified resource directory.

acs:TargetRDPath

String

The resource directory path to which the peer account belongs, in the format {RDId}/{RootFolderId}/{FolderId}/{AccountId}. Wildcard matching is supported.

Require that the peer account is under a specified folder in the resource directory, enabling hierarchical governance.

Usage constraints:
Only vpc:CreateVpcPeerConnection and vpc:AcceptVpcPeerConnection inject 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 code Forbidden.NoPermission is returned with NoPermissionType set to ExplicitDeny. 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

  1. Log on to the RAM console. In the left-side navigation pane, choose Permissions > Policies.

  2. 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.

  3. Click OK, enter the Policy Name, and click OK.

  4. Attach the policy to the target RAM user, user group, or role.

API

  1. Call CreatePolicy to create a custom policy. Pass the policy from the scheme you selected above as the PolicyDocument parameter.

  2. 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.

Metrics

Metric

Description

Inbound traffic

Traffic sent from the requester to the accepter within a statistical period.

Outbound traffic

Traffic sent from the accepter to the requester within a statistical period.

Inbound bandwidth

Bandwidth for traffic from the requester to the accepter.

Outbound bandwidth

Bandwidth for traffic from the accepter to the requester.

Outbound packets dropped due to throttling

Rate of data packets dropped due to outbound bandwidth throttling on the peering connection instance.

Console

Peering connection monitoring

  1. Go to the VPC Console - VPC Peering Connections page. In the top navigation bar, select the region where the VPC is located.

  2. In the Monitor column of the target inter-region VPC peering connection instance, click the icon icon to view metrics such as traffic, bandwidth, and packet loss.

CloudMonitor alerts

  1. Go to the CloudMonitor Console - Alert Rules page and click Create Alert Rule.

  2. 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.

  3. From the Actions column for an alert rule, you can Modify, Disable, or Delete it.

API

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.

  1. Run sudo systemctl stop docker to stop the Docker service.

  2. Run sudo vim /etc/docker/daemon.json to 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.json or /etc/docker/daemon.conf. The exact filename may vary.
    {
        "bip":"new Docker CIDR block"
    }
  3. Run sudo systemctl start docker to 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.

    image
  • 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

image

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.
image

States

State

Description

Creating

The requester has initiated the VPC peering connection request.

Accepting

Waiting for the accepter to accept the VPC peering connection request.

Updating

The connection is being configured after the request is accepted.

Activated

The VPC peering connection is successfully established. Communication between the VPCs is enabled.

Rejected

The accepter has rejected the VPC peering connection request.

Expired

The request expires if the accepter does not respond within seven days.

Deleting

The connection is being deleted at the request of one of the parties.

Deleted

The VPC peering connection has been successfully deleted.

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