VPC peering connection

更新时间:
复制 MD 格式

By default, VPCs are isolated and cannot communicate with each other. To enable private communication between VPCs, create a VPC peering connection and configure a route in each VPC. This feature supports same-account and cross-account connections, as well as same-region and cross-region connections. Before you begin, ensure the CIDR blocks of the two VPCs do not overlap.

Workflow

A vpc peering connection connects two VPCs over a private network, allowing resources in both VPCs to communicate with each other using private IP addresses.

  1. Create a vpc peering connection: For same-account VPCs, the system automatically establishes the connection. For cross-account VPCs, the recipient account must accept the connection request.

  2. Configure bidirectional routes: To enable communication, configure a route in each VPC that points to the peer VPC.

image

For high-bandwidth, low-cost interconnection of many VPCs, use a vpc peering connection with Cloud Enterprise Network. See vpc interconnection for a comparison of the two.

Configure a peering connection

Console

  1. Prerequisites:

    1. Ensure that the CIDR blocks of the two VPCs do not overlap. If they overlap, you must migrate 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 the two VPCs.

  2. Create a peering connection:

    1. Go 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 an accepter account type and region type based on the VPCs' accounts and regions.

      • Accepter account type:

        • Same-Account: The system automatically accepts the request and establishes the connection. You can check the box to add a route for the peer VPC's CIDR block to the system route table. If this option is selected, the system automatically configures bidirectional routes.

        • Cross-Account: Use the accepter account to go to the VPC console - VPC Peering Connection page. In the top navigation bar, select the VPC's region. In the Actions column of the target 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.

        Platinum and Gold link types are supported. They provide different levels of data transfer quality and have different billing rates.

        • Platinum (99.995% service availability): Ideal 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 (99.95% service availability): Suitable for workloads less 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 account: In the Requester VPC column, click Configure route. Select the Route Tables associated with the vSwitch of the resources you want to connect. For Destination CIDR Block, enter the CIDR block of the accepter VPC.

    2. In the accepter account: In the Accepter column, click Configure route. Select the Route Tables associated with the vSwitch of the resources you want to connect. For Destination CIDR Block, enter the CIDR block of the requester VPC.

  4. Verify connectivity:

    • Reachability Analyzer: This feature analyzes connectivity without sending actual data packets, so it does not affect your services.

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

      2. Configure the source and destination. Specify a protocol and port number to simulate an access scenario and verify connectivity.

      3. The system checks the routes, security groups, and network ACLs, and then provides a diagnosis result.

      4. If the path is reachable in one direction, you must configure and analyze the reverse path to verify bidirectional connectivity.

    • Manual verification: From an ECS instance in the requester VPC, run the ping <private IP of the peer ECS instance> command.

After you create an inter-region VPC peering connection, you can click the instance ID and then Edit the Bandwidth (Mbit/s) and Link Type of the connection.
The owner of either account can delete the VPC peering connection. This action immediately interrupts private network connectivity and is irreversible. To avoid service disruptions, proceed with caution.

API

Create a peering connection
  1. Call the CreateVpcPeerConnection operation to create a VPC peering connection.

  2. If the two VPCs belong to different accounts, use the accepter account to call the AcceptVpcPeerConnection operation to accept the VPC peering connection.

    The accepter can also call the RejectVpcPeerConnection operation to reject the VPC peering connection.
  3. From each account, call the GetVpcPeerConnectionAttribute operation to query the CIDR block of the peer VPC.

  4. From each account, call the CreateRouteEntry operation to create a route entry that points to the VPC peering connection.

Modify an inter-region peering connection

Call the ModifyVpcPeerConnection operation to modify the bandwidth or link type of an inter-region VPC peering connection.

Delete a peering connection
Reachability Analyzer

To use Reachability Analyzer to verify connectivity, call the following API operations in the following order:

  1. CreateNetworkAnalysisPath

  2. StartNetworkReachableAnalysis

  3. GetNetworkReachableAnalysisResult

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                             # Bandwidth in Mbps. Configurable only for inter-region connections.
  link_type            = "Gold"                           # Link type. Configurable 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 ID of 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 ID of 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 region of the requester VPC. 
}

# The region of the accepter VPC. This can be the same as the requester region.
variable "accepting_region" {
  default = "cn-beijing"
}

# The ID of the accepter account.
variable "accepting_uid" {
  default = "1234******"
}

# The AccessKey ID of the accepter account.
variable "access_key_id" {
  description = "The AccessKey ID to manage your infrastructure"
}
# The AccessKey secret of the accepter account.
variable "access_key_secret" {
  description = "The AccessKey Secret to manage 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 region of the accepter VPC.
  accepting_vpc_id     = var.accepting_vpc_id # The ID of the accepter VPC.
  bandwidth            = 1024                 # Bandwidth in Mbps. Configurable only for inter-region connections.
  link_type            = "Gold"               # Link type. Configurable 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 ID of 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 ID of 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
}

Troubleshooting network connectivity

Use Reachability Analyzer to verify network connectivity.

Check item

Description

Solution

Peering connection status

Verify that the target peering connection has a Status of Activated.

If the status is Pending Acceptance, contact the owner of the accepter account to accept the connection request.

CIDR block configuration

Check 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 as public CIDR blocks. If an ECS instance has a public IP address, traffic to these CIDR blocks is routed to the public internet by default.

  3. Conflicts with Docker network adapter addresses if Docker is deployed on an ECS instance.

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

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

  3. Modify the Docker CIDR block.

Route configuration

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

  1. Verify that each VPC has a route entry pointing to the peer VPC.

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

  3. Confirm the route entry is in the route table for the vSwitch that contains your resources.

Check and correct the bidirectional route configuration.

Access rule configuration

  1. The security group rules for the connected ECS instances allow traffic from the peer IP address range.

  2. The allowlist of the RDS instance includes the peer IP address range.

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

Ensure that security groups, network ACLs, and the RDS allowlist all permit traffic from the peer IP address range.

Connectivity failures from CIDR block conflicts

  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. This routes traffic within the local VPC, preventing it from reaching the peer VPC.

    1. If the vSwitch CIDR blocks do not overlap, you can configure the peer vSwitch's CIDR block as the destination. However, this approach is difficult to scale because new vSwitches must also use non-overlapping CIDR blocks, which complicates network planning. Migrate workloads to a VPC with a non-overlapping CIDR block and create a new peering connection.

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

  2. Use of non-RFC 1918 private CIDR blocks:

    A VPC treats IP address spaces outside of RFC 1918 (such as 198.19.0.0/16 and 30.0.0.0/16) as public CIDR blocks. If an ECS instance in the VPC has a public IP address or can access the internet through a NAT Gateway, traffic destined for these CIDR blocks is routed to the public internet instead of the destination VPC. To fix this, use an IPv4 Gateway to enable private use of public IP addresses in the VPC. This lets you add the destination public CIDR block as a private route, which ensures traffic is correctly routed to the destination VPC through the peering connection.

Configuration examples

Connect three VPCs

When you configure routes for a VPC Peering Connection, you can:

  • Set the destination CIDR block to the entire CIDR block of the peer VPC. This allows all instances to communicate with each other and simplifies route management.

  • Configure more granular routes by setting the destination CIDR block to a peer vSwitch's CIDR block or a specific instance's IP address. This enhances security, but you must manually update the route table when new instances need to communicate.

For example, VPC1 has routes that point to the vSwitch 3 CIDR block in VPC2 and to ECS04 in VPC3. As a result, resources in VPC1 can only communicate with resources in the vSwitch 3 CIDR block and with ECS04 over the private network. VPC2 and VPC3 have routes that point to the entire CIDR blocks of their peer VPCs, which allows all their resources to communicate with each other.

image

Connect VPCs in a hub-and-spoke topology

In a hub-and-spoke topology, spoke VPCs can access services in the hub VPC but cannot communicate directly with each other. Use cases for this model include:

  • Departmental isolation: VPCs for different business departments cannot communicate with each other, but they must access shared services in the hub VPC.

  • Multi-tenant isolation: A service is deployed in a dedicated VPC and provided to multiple tenants. Each tenant's VPC can communicate with the service VPC, but the tenant VPCs cannot communicate with each other.

image

Restrict unauthorized cross-account connections

By default, a RAM user with vpc:CreateVpcPeerConnection and vpc:AcceptVpcPeerConnection permissions can create a VPC peering connection with any account. To prevent unauthorized data leaks, use a RAM custom policy to restrict connections to accounts within your organization or to specific peer accounts. These policies use global condition keys, such as acs:TargetRDId and acs:TargetRDPath, to restrict the peer accounts that a RAM user can connect to.

Condition keys

During authorization, RAM uses the AcceptingAliUid parameter (when you create a peering connection) or the RequestingAliUid parameter (when you accept a peering connection) to look up the Resource Directory of the peer account. RAM then injects the following condition keys into the authorization context for evaluation by the Condition block in your custom policy.

Condition key

Type

Description

Use case

acs:TargetRDId

String

The Resource Directory ID of the peer account, for example, rd-xxxxxx.

Restricts connections to accounts that belong to a specified Resource Directory.

acs:TargetRDPath

String

The resource directory path of the peer account, in the format {RDId}/{RootFolderId}/{FolderId}/{AccountId}. Wildcards are supported.

Restricts connections to accounts that are located in a specified folder. This is useful for implementing tiered governance.

Note:
These condition keys are injected only for vpc:CreateVpcPeerConnection and vpc:AcceptVpcPeerConnection actions. Other operations on VPC peering connections, such as querying, modifying, or deleting, are not affected.
If a request is denied by the policy, the API returns the error code Forbidden.NoPermission. The NoPermissionType field in the error details is set to ExplicitDeny. You can trace the denied request using its RequestId in ActionTrail.

Choose a restriction policy

Replace placeholders, such as the Resource Directory ID, resource directory path, or account ID, with the actual values from your organization. You can find your Resource Directory ID and resource directory path in the Resource Management console.

Resource Directory ID

This policy restricts VPC peering connections to accounts within a 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"]
        }
      }
    }
  ]
}

Resource directory path

This policy restricts VPC peering connections to accounts under a specified folder path. This restriction is useful for implementing fine-grained, tiered governance. Replace the example path 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 in to the RAM console. In the left-side navigation pane, choose Permissions > Policies.

  2. Click Create Policy. On the JSON Editor tab, paste the chosen policy document, and then replace the placeholder values such as the Resource Directory ID or resource directory path.

  3. Click OK, enter a Policy Name, and then click OK.

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

API

  1. Call the CreatePolicy operation to create a custom policy. Pass the chosen policy document 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 an inter-region peering connection, you can monitor key metrics such as traffic, bandwidth, and packet loss. By creating threshold-based alert rules with CloudMonitor, you can monitor the connection in real time to quickly detect and resolve network issues.

Monitoring metrics are not available for intra-region peering connections.

Metrics

Metric

Description

Inbound traffic

The traffic sent from the requester to the accepter of a VPC peering connection within a statistical period.

Outbound traffic

The traffic sent from the accepter to the requester of a VPC peering connection within a statistical period.

Inbound bandwidth

The bandwidth for traffic flowing from the requester to the accepter of a VPC peering connection.

Outbound bandwidth

The bandwidth for traffic flowing from the accepter to the requester of a VPC peering connection.

Outbound packets dropped due to throttling

The number of outbound data packets dropped by the VPC peering connection instance due to bandwidth throttling.

Console

Peering connection monitoring

  1. Go to VPC Console - VPC Peering Connections. At the top of the page, select the region where the VPC is located.

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

CloudMonitor alerts

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

  2. Configure thresholds for each alert level for the VPC peering connection metrics. When a metric crosses its threshold, the specified Alert Contact Group receives a notification. You can also view the alert timeline by clicking Alert History in the Actions column of the alert rule.

  3. In the Actions column of the target alert rule, you can Modify, Disable, or Delete the rule.

API

Terraform

Refer to CloudMonitor metrics for peering connections to configure threshold-based alert rules.
Resources: alicloud_cms_alarm_contact, alicloud_cms_alarm_contact_group, alicloud_cms_alarm
# The ID of the VPC 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] # Specifies the 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 connections are supported.

  • Non-cross-border: Connects two regions within 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. You must first complete cross-border compliance certification. Submit your information on the China Unicom Cross-border Cloud Private Line Application page to apply for the required cross-border business qualification.

Why can't I select the destination VPC?

Ensure that the selected region and account match the Region and Owner of the destination VPC.

The requester's region appears at the top of the page, and the current account is the requester. You configure the accepter's account and region when you create the peering connection.

Missing CDT permission error for RAM users

A RAM user has the AliyunVPCFullAccess permission, but receives an error indicating that the cdt:GetCdtServiceStatus permission is missing when creating a VPC peering connection. This is because VPC peering connections rely on the Cloud Data Transfer (CDT) service. Creating a peering connection requires calling APIs related to CDT, so VPC permissions alone are not sufficient.

You must grant the RAM user one of the following additional permissions:

  • AliyunCDTFullAccess: Grants full access to the CDT service.

  • AliyunCDTReadOnlyAccess: Grants read-only access to the CDT service. This permission is sufficient if the user only needs to create peering connections and does not need to manage CDT resources.

Communication failure for ECS instances with Docker

If the routing and security group settings are correct, this issue is typically caused by a conflict between the Docker network interface address and the destination CIDR block. You can run theip addr command to check for conflicts.

If a conflict exists, follow these steps to modify the Docker CIDR block to resolve the conflict with the destination CIDR block.

  • Stopping the Docker service or modifying the Docker CIDR block interrupts business services. Perform this operation during off-peak hours.

  • When you modify the Docker CIDR block, ensure that the new CIDR block is compatible with the network settings of all existing containers and applications to avoid potential connectivity issues.

  1. Run thesudo systemctl stop docker command to stop the Docker service.

  2. Run thesudo vim /etc/docker/daemon.json command to edit the Docker configuration file. Add the following content to the file and save it:

    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 thesudo systemctl start docker command to start the Docker service and ensure that the changes take effect.

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.

    • The two VPCs are in different types of regions, such as a public cloud region, a Finance Cloud region, or an Alibaba Gov Cloud region.

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

    image
  • If a VPC is shared across multiple accounts, only the resource owner can create, modify, or delete a vpc peering connection. Resource users do not have these permissions.

Billing

Intra-region vpc peering connections are free of charge, regardless of whether the VPCs belong to the same account 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 the selected link type. Two link types, Platinum and Gold, are available to provide different levels of data transfer quality.

  • The billing cycle is hourly. If you switch the link type within a billing cycle, the rate for the higher service level applies to the entire cycle.

In this example of an inter-region, cross-account vpc peering connection between VPC1 and VPC2, the link type is Gold and the data transfer fee from China (Hohhot) to China (Guangzhou) is CNY 0.48 per GB. For outbound traffic of 200 GB from VPC1 and 100 GB from VPC2, the fees are calculated as follows:

Fee for Account A: CNY 0.48/GB × 200 GB = CNY 96

Fee for Account B: CNY 0.48/GB × 100 GB = CNY 48

image

VPC peering connection state machine

After a requester initiates a vpc peering connection, it transitions through several states.

When you create a vpc peering connection between VPCs in the same account, the system automatically accepts the request, and the connection becomes Activated.
image

State descriptions

State

Description

Creating

The connection request has been initiated by the requester.

Accepting

The connection request is pending acceptance by the accepter.

Updating

The connection is being provisioned after the request has been accepted.

Activated

The connection is established and active.

Rejected

The connection request has been rejected by the accepter.

Expired

The connection request expired because the accepter did not accept or reject it within seven days.

Deleting

The requester or the accepter is deleting the connection.

Deleted

The connection is deleted.

Supported regions

Supported public cloud regions

Area

Regions

Asia Pacific - China

China (Hangzhou), China (Shanghai), China (Nanjing) - Local Region (being decommissioned), 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 (being decommissioned)

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), and US (Virginia)

Middle East

UAE (Dubai) and Saudi Arabia (Riyadh) - partner-operated

Supported Finance Cloud regions

Area

Regions

Asia Pacific

China (Shenzhen) Finance, China (Shanghai) Finance, and China (Beijing) Finance (invitation-only beta)

Supported Alibaba Gov Cloud regions

Area

Regions

Asia Pacific

China (Beijing) GovCloud 1

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 inter-region bandwidth.

1,024 Mbps