All Products
Search

This Product

    Cloud Enterprise Network:Migrate VPCs using peering connections to Cloud Enterprise Network

    Document Center

    Cloud Enterprise Network:Migrate VPCs using peering connections to Cloud Enterprise Network

    Last Updated:Jun 20, 2026

    When you use peering connections to link VPCs, routing configuration becomes complex and difficult to maintain as the number of VPCs grows. Migrate your VPCs from peering connections to Cloud Enterprise Network (CEN) to enable automatic route propagation, simplify network configuration, and improve the extensibility of your network architecture.

    Migration Guide

    The core of migration is to redirect inter-VPC traffic from peering connections to the transit router by configuring route entries. This process has three steps:

    1. Create a Cloud Enterprise Network instance: Use the scenario-based creation method. It performs the following actions:

      1. Automatically creates a transit router (referred to as TR below) in the region where your VPC resides.

      2. Automatically creates a VPC connection to attach each VPC to the TR. In cross-region scenarios, it also automatically creates inter-region connections between TRs.

      3. Automatically enables route learning (the TR automatically learns system route entries from VPCs) and route synchronization (the TR propagates its route table entries to VPCs).

      Note

      In regions where the TR supports multiple zones, each VPC must have at least two vSwitches in different zones. If this condition is not met, first create vSwitches.

    2. Configure route entries: After confirming that route entries in both the TR and VPC route tables are active, delete the route entries associated with peering connections.

      1. If your VPC route table contains routes pointing to ECS instances, VPN gateway instances, HAVIPs, or similar resources, publish these routes to the TR in the CEN console based on your connectivity requirements. For details, see Publish routes to transit router.

      2. Check the TR route table to confirm it contains routes to each VPC.

      3. Check each VPC route table to ensure that a route entry to TR exists. In the Cloud Enterprise Network console, go to the Network Instance Route Table tab and verify that the Status of each VPC route is displayed as Rejected.

        1. If no route conflicts exist, delete the route entries whose next hop is the peering connection to achieve smooth migration.

        2. If route conflicts occur, choose one of the following options:

          • Transient disconnection migration: Delete the route entries whose next hop is the peering connection directly. This may cause transient traffic disruption lasting several minutes, proportional to the number of route entries in the TR.

          • Smooth migration: Add more specific routes so that routes pointing to the TR become active in the VPC route table before deleting the peering connection routes.

            For example, if the VPC route table contains both “Destination CIDR block 10.0.0.0/24, next hop peering connection” and “Destination CIDR block 10.0.0.0/24, next hop TR,” follow these steps for smooth migration:

            1. Add two more specific split routes:

              • “Destination CIDR block 10.0.0.0/25, next hop peering connection”

              • “Destination CIDR block 10.0.0.128/25, next hop peering connection”

            2. Delete the route entry: “Destination CIDR block 10.0.0.0/24, next hop peering connection.”

            3. Wait for the synchronized route entry to take effect: “Destination CIDR block 10.0.0.0/24, next hop TR.”

            4. Delete the two specific route entries: “Destination CIDR block 10.0.0.0/25, next hop peering connection” and “Destination CIDR block 10.0.0.128/25, next hop peering connection.”

    3. Validate: Confirm that VPCs can still communicate. If successful, delete the peering connection.

    Scenario Example

    As shown above, assume two VPCs are already connected via a peering connection and you plan to migrate them to Cloud Enterprise Network.

    Each VPC contains one vSwitch, and each vSwitch hosts one ECS instance. The two ECS instances can ping each other.

    The resource planning is as follows:

    Configuration item

    VPC1

    VPC2

    Region

    China (Hangzhou)

    China (Hangzhou)

    CIDR block

    10.0.0.0/16

    172.16.0.0/16

    vSwitch

    Name: vSwitch1

    Zone: J

    CIDR block: 10.0.0.0/24

    Name: vSwitch1

    Zone: J

    CIDR block: 172.16.0.0/24

    ECS

    Name: ECS1

    IP address: 10.0.0.1

    OS: Alibaba Cloud Linux

    Name: ECS2

    IP address: 172.16.0.1

    OS: Alibaba Cloud Linux

    Custom route entry

    Destination CIDR block 172.16.0.0/16, next hop peering connection

    Destination CIDR block 10.0.0.0/16, next hop peering connection

    Preparations

    During smooth migration, network connectivity between the two VPCs remains uninterrupted.

    Before starting, log on to ECS1 and run the command ping 172.16.0.1 to access ECS2. Keep this command running to monitor network connectivity in real time.

    If your ECS runs Windows, add the -t parameter to keep the ping command running continuously: ping -t 172.16.0.1.

    Procedure

    Step 1: Create a Cloud Enterprise Network instance

    1. Create one additional vSwitch in each VPC. Select zone K for both, name them vSwitch2, and assign CIDR blocks 10.0.1.0/24 and 172.16.1.0/24 respectively. This satisfies the requirement that TR VPC connections must select at least two vSwitches in different zones.

    2. Log on to the Cloud Enterprise Network console. Click Create CEN Instance. On the dialog that appears, select the Create Scenario-specific CEN (Recommended) tab, choose the scenario VPC Interconnection, then click Create.

    3. On the Create CEN Instance > Configure Networking Settings page, configure the following:

      • Region: Select China (Hangzhou).

      • Zone: Select Zone J and Zone K.

      • VPC:

        • Select VPC VPC 1 and choose its two vSwitches.

        • Click Add VPC, select VPC2 as the VPC, and choose its two vSwitches.

      • Click Next.

    4. On the Confirm Networking Settings and Fees page, wait a few minutes while the system generates a configuration preview. Review the resources that will be automatically created and their associated costs. After confirming everything is correct, click Start Deployment.

    5. On the Start Deployment page, the system displays Deploying. Deployment takes about 5–10 minutes. Wait patiently. When complete, the system shows Network Deployed. Click View CEN Instance to see the automatically created resources. You will see a CEN instance named “create_by_cadt” and a TR named “cn-hangzhou” automatically created within it.

    6. Click the TR instance ID “cn-hangzhou” to view the two automatically created intra-region connections, indicating that VPC1 and VPC2 are now attached to the TR.

    Step 2: Configure route entries

    1. If your VPC route tables contain routes pointing to ECS instances, VPN gateway instances, HAVIPs, or similar resources, publish these routes to the TR in the CEN console based on your connectivity needs. This example does not include such routes, so no publishing is needed.

    2. Check the TR route table: Click the TR instance ID “cn-hangzhou” and switch to the Route Table tab. You will see the TR has learned routes to VPC1 and VPC2:

      Route entries include the following: Destination CIDR blocks 10.0.0.0/24 and 10.0.1.0/24 with next hop VPC1, and destination CIDR blocks 172.16.0.0/24 and 172.16.1.0/24 with next hop VPC2.

    3. Check VPC route tables

      1. Check VPC1’s route table: Switch to the Network Instance Route Table tab, select VPC1 under Networks, and view its route table directly.

        You will see that the TR has synchronized its automatically learned routes to VPC1’s route table with no conflicts (Status is Ready):

        The routes 172.16.0.0/24 and 172.16.1.0/24 have route type Cloud Enterprise Network, next hop China (Hangzhou), and type VPC, indicating they were automatically learned from the peer VPC and synchronized to VPC1’s route table.

      2. Check VPC2’s route table using the same steps as for VPC1.

      3. Since neither VPC route table shows route conflicts, delete the route entries whose next hop is the peering connection to complete smooth migration.

        Log on to the VPC console. In the navigation pane on the left, click VPC Peering Connection. At the top, select region China (Hangzhou). Click the target VPC Peering Connection ID and switch to the Route Entry List tab. For each route entry, click Delete in the Actions column.

      Handling conflicts

      Assume that before migration, VPC1’s route table contained a custom route entry “Destination CIDR block 172.16.0.0/24, next hop peering connection.” In this case, a route conflict occurs during route table validation.

      Using the Network Instance Route Table tab to view VPC1’s route table, VPC1 prioritizes the existing peering connection route and marks the newly synchronized TR route as conflicting.

      You can choose:

      • Transient disconnection migration: Delete the route entries whose next hop is the peering connection directly. This may cause transient traffic disruption lasting several minutes, proportional to the number of route entries in the TR.

      • Smooth migration: Add more specific routes so that routes pointing to the TR become active before deleting the peering connection routes.

        Log on to the VPC console. In the navigation pane on the left, click Route Table. Click the Instance ID for VPC1’s route table. Under the Route Entry List > Custom Route tab:

        1. Add two more specific split routes:

          • Destination CIDR block 172.16.0.0/25, next hop peering connection

          • Destination CIDR block 172.16.0.128/25, next hop peering connection

        2. Delete the route entry: “Destination CIDR block 172.16.0.0/24, next hop peering connection.”

        3. Wait for the synchronized route entry to take effect: “Destination CIDR block 172.16.0.0/24, next hop TR.”

        4. Delete the two specific route entries: “Destination CIDR block 172.16.0.0/25, next hop peering connection” and “Destination CIDR block 172.16.0.128/25, next hop peering connection.”

    Step 3: Validate

    1. Observe the ping command started during preparations. If it continues to receive acknowledgements, traffic has been successfully redirected to the transit router.

    2. Delete the peering connection: Log on to the VPC console. In the navigation pane on the left, click VPC Peering Connection. At the top, select region China (Hangzhou). Find the target peering connection and click Delete in the Actions column.

    How to roll back

    1. Follow Use VPC peering connections to enable private connectivity between VPCs to reestablish the peering connection between VPCs. Add route entries in each VPC route table with “Destination CIDR block set to the peer VPC’s CIDR block, next hop set to the peering connection,” and ensure these routes become active. If a route conflict occurs (for example, the system reports “This CIDR block already exists in this route table”), resolve it by adding more specific routes.

    2. Follow Delete a Cloud Enterprise Network instance to delete VPC connections (in cross-region scenarios, also delete inter-region connections between TRs), then delete the TR instance and the CEN instance.

    References

    What are the differences between Cloud Enterprise Network and VPC peering connections?

    Cloud Enterprise Network billing

    How transit routers work