Virtual Private Cloud:VPC peering connections

Overview

VPC peering connections allow private network communication between VPCs within the same or different accounts, and across the same or different regions. Once a peering connection is established, cloud resources in the VPCs can communicate using private IPv4 or IPv6 addresses.

Scenarios

• Secure access: VPC peering connections enhance security by allowing resources in different VPCs to communicate over a private network. This avoids Internet exposure and protects against common network attacks.

• Multi-account connections: You can enable secure communication across VPCs in a multi-account architecture. This fosters collaboration among teams and enhances resource-sharing efficiency.

• Disaster recovery: Leverages cross-region peering connections for data synchronization and backup. This ensures data redundancy, disaster recovery, and business reliability.

Requester and accepter

• The two VPCs in a peering connection are the requester and the accepter.

  Requester: Initiates the peering request.

  Accepter: Awaits the peering request.

• The two roles, requester and accepter, are solely for establishing a peering connection. After the peering connection is created, both VPCs can send and receive data as though they were part of the same network.

Status of a VPC peering connection

A VPC peering connection begins when the requester sends a connection request to the accepter and undergoes multiple phases, with each stage corresponding to a different status.

When the requester and accepter VPCs are both in the same Alibaba Cloud account, the peering connection request is automatically initiated and accepted, thus activating the connection upon establishment.

Billing

Intra-region connections: No fees are charged, regardless of whether they belong to the same or different accounts.

Inter-region connections: Data transfer fees are charged by Cloud Data Transfer (CDT) based on the outbound traffic.

Billing example for inter-region connections

As shown in the image, Customer 1 created VPC1 in China (Hohhot), and Customer 2 set up VPC2 in China (Guangzhou). Consequently, an inter-region, cross-account peering connection between the two VPCs is established. According to outbound traffic billing rules, Customer 1 is billed for traffic sent to VPC2, and Customer 2 is billed for traffic sent to VPC1.

Work with VPC peering connections

To establish a VPC peering connection for secure, private communication between two VPCs, you can follow the steps below. For more information, see Use VPC peering connection for private communication.

1. Create a VPC peering connection.

   1. The requester sends a peering connection request to the accepter.

   2. Activate the peering connection.

      • For a same-account VPC peering connection, the system automatically accepts the request and establishes a connection, without any action needed from the accepter.

      • For a cross-account VPC peering connection, the accepter can either accept or reject the request. The VPC peering connection is activated only when the request is accepted.

2. Configure routes at both ends of the peering connection for VPCs to communicate over a private network.

   Select one of the following methods based on your needs:

   • Use the CIDR block of the peer VPC as the destination to grant full access to resources. Elastic Compute Service (ECS) instances can communicate with all resources in the vSwitches of the peer VPC, which simplifies management.

   • For enhanced security, use the CIDR block of the vSwitch in the peer VPC as the destination and limit the bandwidth of peering connection traffic.

   Important

   If the CIDR blocks of the two VPCs overlap:

   • If vSwitch CIDR blocks do not overlap, you can set the non-overlapping CIDR block of peer vSwitch as the destination. Ensure you avoid CIDR block conflict when deploying subsequent services.

     Configuring the destination address to point to the peer VPC may cause routing issues. The system route will override the route established by the peering connection. This means that any traffic intended for the peer VPC will be misrouted internally within the requester VPC and will not reach the accepter.

   • If vSwitch CIDR blocks overlap, you cannot use the CIDR block of the peer vSwitch as the destination, because it is not possible to configure more specific routes than the system route.

   Route configurations example

   After the peering connection has been created and its status has changed to Activated, you must add routes at both ends of the connection to direct traffic and enable network communication.

   

   In this scenario, set the CIDR block of the peer VPC as the destination to enable full access among resources in the connected VPCs.

   Route table	Destination address	Next hop
   VPC1	192.168.0.0/16	pcc-aaabbb
   	2408:XXXX:XXXX:4000::/56	pcc-aaabbb
   VPC2	172.16.0.0/12	pcc-aaabbb
   	2408:XXXX:XXXX:3f00::/56	pcc-aaabbb

Troubleshooting

• Use CloudMonitor to collect metrics such as traffic bandwidth and packet loss for inter-region VPC peering connections. You can create alert rules to monitor the instance status in real-time, ensuring business stability.

• For access issues with a VPC peering connection, use Network Intelligence Service (NIS) for bidirectional path analysis to diagnose configuration errors.

  Note

  NIS currently does not support simultaneous bidirectional path analysis. You can verify connectivity using Reverse Path Analysis.

  • Unreachable: Check the route configuration and ensure that the route table has an entry whose destination is the CIDR block of the peer VPC and the next hop is the VPC peering connection.

  • The request matches security group deny rules or is denied by default: Ensure the security group of the ECS instance in the VPC permits traffic from the peer VPC. Modify the inbound or outbound rules as necessary.

  • The request matches network ACL deny rules or is denied by default: Check if the network ACLs of vSwitches permit traffic from the peer VPC. Modify the inbound or outbound rules as necessary.