Virtual Private Cloud:VPC peering connections

Overview

A VPC peering connection is a networking solution that allows two VPCs to interconnect, thus supporting both IPv4 and IPv6 traffic. This connection enables private network communication between VPCs within the same account or across different accounts, in the same region, or across different regions.

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 such as DDoS attacks.

• Multi-account connections: Organizations can enable secure communication across VPCs. This fosters collaboration among teams and enhances resource-sharing efficiency.

• Disaster recovery: Leverage cross-regional VPC peering connections for data synchronization and backup. This ensures data redundancy, disaster recovery, and business stability.

Requester and accepter

• The two VPCs in a peering connection are the requester and the accepter. The requester initiates the peering request, while the accepter awaits the incoming request. These roles are solely for establishing the connection. After a VPC peering connection is established, both the requester and accepter can send and receive data as if they were in the same network.

• For a same-account VPC peering connection, the system automatically accepts the request from the requester and establishes a connection. The accepter does not need to accept the request.

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

• Requester and accepter VPCs can be located in either the same or different regions.

Status of a VPC peering connection

The status of a VPC peering connection changes throughout the connection process.

Status	Description
Creating	The status after the requester sends a connection request.
Peer Accepting	The status when the connection is waiting to be accepted by the accepter.
Updating	The status after the accepter accepts the connection request.
Activated	The status after the VPC peering connection is activated.
Rejected	The status after the accepter rejects the connection request.
Expired	The status after the connection request remains pending for more than seven days.
Deleting	The status when the VPC peering connection is being deleted.
Deleted	The status after the VPC peering connection is deleted.

Work with VPC peering connections

Create VPC peering connections

To create a peering connection between two VPCs for a simple and secure private network, follow the steps below. For more details, see Use VPC peering connection for private communication.

Before you connect VPCs, plan the network appropriately and ensure that the CIDR blocks do not overlap.

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

2. The accepter accepts the request and activates the peering connection.

   Note

   When the accepter account is Same Account, the system automatically creates the connection after a request is initiated, without any action from the accepter.

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

Configure routes

When configuring routes for a VPC peering connection, 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.

Example

Configuration example

After the VPC peering connection has been created and its status has changed to Activated, routes must be added at both ends of the connection to direct traffic and enable private network interconnectivity.

In this scenario, configure routes at both ends to point to the CIDR block of the peer VPC. For more examples, see Examples of VPC peering connections.

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 instance, 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 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.

Billing

VPC peering connections can be created in four scenarios: same-region same-account, same-region cross-account, inter-region same-account, and inter-region cross-account. There is no charge for connections in the same region, whereas inter-region connections incur data transfer fees, which are calculated based on outbound traffic and billed by Cloud Data Transfer (CDT). For more information, see Cross-region data transfers.

Billing examples 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.

When 200 GB of data is transferred from VPC1 and 100 GB from VPC2 through the peering connection, and the inter-region traffic fees incurred for data transfer between China (Hohhot) and China (Guangzhou) is 0.6 RMB/GB, the two customers are charged in the following ways:

Customer 1: CNY 0.6/GB × 200 GB = CNY 120

Customer 2: CNY 0.6/GB × 100 GB = CNY 60

Limits