VPC route tables

Route tables

When you create a VPC, a system route table is automatically created. By default, it is attached to all vSwitches within the VPC to control network traffic.

If different ECS instances within a VPC need to send traffic to the same destination CIDR block along different network paths, you can use a custom route table. Deploying the ECS instances on different vSwitches and attaching a dedicated custom route table to each one provides granular traffic control.

To direct inbound public traffic through a self-managed firewall, you can use a gateway route table. A gateway route table is a custom route table attached to an IPv4/IPv6 gateway. This setup directs inbound traffic to your firewall, enabling unified filtering, auditing, and security policy enforcement.

This table compares these types of route tables.

Item	System route table	Custom route table
Attached to	vSwitch	vSwitch	IPv4/IPv6 gateway
Diagram
Use cases	Attached to all new vSwitches by default to centrally control vSwitch traffic.	Attached to specific vSwitches to control their traffic paths.	Attached to an IPv4/IPv6 gateway to securely redirect inbound public traffic.
Creation method	Automatically created when you create a VPC.	Manually created. You select the vSwitch type when you create the route table.	Manually created. You select the gateway type when you create the route table.
Deletion	Cannot be deleted.	Can be deleted once detached from all associated vSwitches.	Can be deleted once detached from the IPv4/IPv6 gateway.
Quota	One system route table per VPC.	By default, you can create up to 9 custom route tables for vSwitches in a VPC. You can request a quota increase.	You can create only one route table for an IPv4/IPv6 gateway in a VPC.

You must attach each vSwitch to exactly one route table. However, you can attach a route table to multiple vSwitches.

1. Static routes

Static routes, which are automatically added by the system or manually by you, include two types:

• System routes: Routes with a Local next hop, automatically added by the system when you create a VPC and a vSwitch. These routes are used for communication between instances within the VPC or for accessing cloud services.

• Custom routes: Routes you manually add to customize traffic forwarding paths.

The following figure shows an example where two VPCs are connected through a VPC peering connection. The system route table of VPC1 contains the following static routes:

1. After you create the VPC and vSwitch, the system automatically adds system routes with Local as the next hop:

   1. Cloud service route: The destination CIDR block is 100.64.0.0/10. This route is used by instances in VPC1 to access cloud services.

   2. vSwitch route: The destination CIDR block is 10.0.0.0/24. This route enables private communication among vSwitches in VPC1.

2. After you create the VPC peering connection, you must manually add the following custom route:

   The destination CIDR block is 172.16.0.0/16 and the next hop is the VPC peering connection. This route forwards traffic destined for VPC2 to the VPC peering connection.

The route entries in the system route table of VPC2 follow the same principles as those in VPC1 and are not detailed here.

2. Dynamic routes

Dynamic routes are routes that are propagated to a VPC from other network instances. Unlike static routes, they do not require manual configuration in the VPC route table. Instead, they are automatically received and updated from a dynamic route source.

Route priority

Routes in a VPC route table are prioritized based on the following rules:

• When route entries have overlapping destination CIDR blocks:

  IPv4 and IPv6 traffic are routed independently. The system uses the longest prefix match rule to select the most specific route that matches the destination IP address. This route determines the traffic's next hop.

  Longest prefix match: When multiple route entries have destination CIDR blocks that match a packet's destination IP address, the system selects the route with the longest subnet mask (the most specific range). For example, traffic destined for 192.168.1.100 matches the 192.168.1.0/24 route instead of the 192.168.0.0/16 route.

• When a new route entry overlaps with an existing route entry:

  Actions	Existing system route	Existing custom route	Existing dynamic route
  Create a vSwitch	The CIDR block of the vSwitch cannot overlap with that of an existing system route.	The CIDR block of the vSwitch cannot: Be identical to the destination CIDR block of an existing custom route. Contain the destination CIDR block of an existing custom route.	The CIDR block of the vSwitch cannot: Be identical to the destination CIDR block of an existing dynamic route. Contain the destination CIDR block of an existing dynamic route.
  Add a custom route	The destination CIDR block of the new custom route cannot: Be identical to the CIDR block of an existing system route. Be more specific than an existing system route for intra-VPC communication.	The destination CIDR block of a new custom route cannot be identical to that of an existing custom route. If the next hop type is router interface (to VBR), you can configure active/standby or ECMP routes. For more information, see Route to a router interface.	The destination CIDR block of a new custom route cannot be identical to that of an existing dynamic route. If the next hop of a new custom route is a VPN Gateway or a router interface, and an existing dynamic route from CEN has the same destination CIDR block, the dynamic route is withdrawn, and the custom route takes effect.
  Receive a dynamic route	Cannot be identical to the destination CIDR block of an existing system route. If a dynamic route is more specific than an existing system route, the dynamic route does not take effect: If the dynamic route source is an ECR, the route is displayed in the VPC route table with a Candidate status and is not used for forwarding. If the dynamic route source is a VPN Gateway, TR Enterprise Edition, or TR Basic Edition, the route is not propagated to the VPC route table.	A dynamic route does not take effect if its destination CIDR block is identical to that of an existing custom route. If the dynamic route source is an ECR, the route is displayed in the VPC route table with a Candidate status and is not used for forwarding. If the dynamic route source is a VPN Gateway, TR Enterprise Edition, or TR Basic Edition, the route is not propagated to the VPC route table. After the custom route is deleted, the dynamic route automatically takes effect.	Not applicable. A VPC route table supports only a single route propagation source.

Create and delete route tables

You must create a custom route table before you can associate it with a target vSwitch, an IPv4 gateway, or an IPv6 gateway.

variable "name" {
  default = "terraform-example"
}

resource "alicloud_vpc" "defaultVpc" {
  vpc_name = var.name
}


resource "alicloud_route_table" "default" {
  description      = "test-description"
  vpc_id           = alicloud_vpc.defaultVpc.id
  route_table_name = var.name
  associate_type   = "VSwitch"
}

Associate and disassociate a route table

A new custom route table is not associated with any resources by default. You must associate it with a vSwitch or an IPv4 or IPv6 gateway to activate it.

variable "name" {
  default = "terraform-example"
}

resource "alicloud_vpc" "foo" {
  cidr_block = "172.16.0.0/12"
  vpc_name   = var.name
}

data "alicloud_zones" "default" {
  available_resource_creation = "VSwitch"
}

resource "alicloud_vswitch" "foo" {
  vpc_id       = alicloud_vpc.foo.id
  cidr_block   = "172.16.0.0/21"
  zone_id      = data.alicloud_zones.default.zones[0].id
  vswitch_name = var.name
}

resource "alicloud_route_table" "foo" {
  vpc_id           = alicloud_vpc.foo.id
  route_table_name = var.name
  description      = "route_table_attachment"
}

resource "alicloud_route_table_attachment" "foo" {
  vswitch_id     = alicloud_vswitch.foo.id
  route_table_id = alicloud_route_table.foo.id
}

resource "alicloud_vpc" "example" {
  cidr_block = "172.16.0.0/12"
  vpc_name   = "terraform-example"
}

resource "alicloud_route_table" "example" {
  vpc_id           = alicloud_vpc.example.id
  route_table_name = "terraform-example"
  description      = "terraform-example"
  associate_type   = "Gateway"
}

resource "alicloud_vpc_ipv4_gateway" "example" {
  ipv4_gateway_name = "terraform-example"
  vpc_id            = alicloud_vpc.example.id
  enabled           = true
}

resource "alicloud_vpc_gateway_route_table_attachment" "example" {
  ipv4_gateway_id = alicloud_vpc_ipv4_gateway.example.id
  route_table_id  = alicloud_route_table.example.id
}

Add and delete route entries

In a route table associated with a vSwitch, you can add route entries to direct its traffic. These are known as custom route entries.

You cannot add route entries to a route table associated with an IPv4 or IPv6 gateway. However, you can change the next hop of a route entry.

resource "alicloud_route_entry" "foo" {
  route_table_id        = "rt-12345xxxx" # Enter the route table ID. 
  destination_cidrblock = "172.16.1.1/32"
  nexthop_type          = "Instance" # Enter the next hop type. 
  nexthop_id            = "i-12345xxxx" # Enter the next hop instance ID. 
}

Change the next hop

You can change the next hop of a route entry to redirect traffic for its destination CIDR block.

• system route entry: You can change the next hop of a system route entry only when it is in a custom route table (including a gateway route table). This change converts it into a custom route entry. Deleting this custom route entry reverts it to a system route entry.

• custom route entry: You can change the next hop of a custom route entry in both system and custom route tables.

For supported destination CIDR block and next hop types, see Comparison between system and custom route entries.

resource "alicloud_route_entry" "foo" {
  route_table_id        = "rt-12345xxxx" # Enter the route table ID. 
  destination_cidrblock = "172.16.1.1/32"
  nexthop_type          = "Instance" # Change the next hop type.
  nexthop_id            = "i-12345xxxx" # Enter the next hop instance ID. 
}

Publish and withdraw static routes

You can propagate routes from a route table to an ECR or a TR. This, combined with dynamic route receiving, simplifies your routing configuration.

• Publish static routes to an ECR: When you publish a static route to an ECR, the ECR dynamically propagates it to your on-premises data center. If no route conflicts exist, all on-premises data centers associated with the ECR can learn the route.

  Principles, limitations, and examples

  How it works

  • When you associate a VPC with an ECR, its system route entries are published to the ECR by default.

  • After a static route is published to an ECR:

    • The ECR propagates the route to its associated VBR. If BGP is enabled on the VBR, the VBR then propagates the route to the on-premises data center.

    • The ECR does not propagate the route to other VPCs associated with it.

  • If a published static route entry conflicts with an existing route entry, you can view the route entry on the Route Entries tab of the ECR. Its status is displayed as Conflicting and it will not become Active.

  Limitations

  • You cannot publish route entries from a custom route table of a VPC to an ECR.

  • You cannot publish route entries to an ECR if their destination CIDR block is a prefix list.

  • ECMP routes and active/standby routes whose next hop is a router interface (to a VBR) cannot be published to an ECR. After a VPC route is published to an ECR, you can no longer configure ECMP routes or active/standby routes for it.

  • After a VPC route is published to an ECR, if you want to modify the published route, you can set its next hop only to a route type that supports the publish operation (see the following table).

  • The following table lists the default publishing status for various types of route entries in a VPC and indicates whether they support publish and withdraw operations in an ECR.

    Table

    Route type	Owning instance	Published by default	Publish support	Withdraw support
    VPC system route entry	VPC	Yes	Yes	Supported only in Malaysia (Kuala Lumpur)
    Route entry to an IPv4 gateway	VPC	No	Yes	Yes
    Route entry to an IPv6 gateway	VPC	No	Yes	Yes
    Route entry to a NAT Gateway	VPC	No	Yes	Yes
    Route entry to a VPC peering connection	VPC	No	No	No
    Route entry to a TR	VPC	No	No	No
    Route entry to a VPN Gateway	VPC	No	Yes	Yes
    Route entry to an ECS instance	VPC	No	Yes	Yes
    Route entry to an elastic network interface	VPC	No	Yes	Yes
    Route entry to a high-availability virtual IP	VPC	No	Yes	Yes
    Route entry to a router interface (to a VBR)	VPC	No	No	No
    Route entry to a router interface (to a VPC)	VPC	No	No	No
    Route entry to an ECR	VPC	No	No	No
    Route entry to a Gateway Load Balancer endpoint	VPC	No	Yes	Yes

  Example scenario

  An enterprise with a VPC in the China (Hangzhou) region and an on-premises data center wants to establish stable cloud-to-on-premises connectivity and allow services deployed in the on-premises data center to access the Internet.

  The enterprise can connect the VPC and a VBR to an ECR. After creating a NAT Gateway and associating an EIP with it, the enterprise can publish the route. If no route conflicts exist, the on-premises data center associated with the ECR learns the route to the NAT Gateway through BGP, enabling it to access the Internet.

  

• Publish static routes to a TR: When a static route is published to a TR, all connected network instances can learn the route, provided there are no route conflicts and route synchronization is enabled for the TR.

If your VPC is connected to both an ECR and a TR, publishing routes to the ECR and publishing routes to the TR are independent actions that do not affect each other.

Enable or disable dynamic route receiving

By default, all route tables receive dynamic route entries. If you want to use a static-only routing configuration, you can disable dynamic route receiving for each route table. This provides the flexibility to plan and manage your route configurations as needed.

1. You can disable this feature in the following cases: The dynamic route entry source is Route Propagation-Type ECR, or no dynamic routes are propagated to the VPC. If no dynamic routes are propagated, the Source of Dynamic Route Entry field is not displayed on the Route Entry List > Dynamic Route Entries tab of the route table details page.

   You cannot disable dynamic route receiving in the following scenarios: The VPC is connected to a Basic Edition TR. The VPC is connected to an Enterprise Edition TR and route synchronization is enabled for the VPC on the TR. The VPC is associated with a VPN Gateway and automatic route propagation is enabled for the VPN Gateway.

2. Impacts of disabling the feature:

   • The VPC route table stops receiving routes propagated from other network instances. All existing dynamic route entries in the route table are deleted. Proceed with caution.

   • You cannot connect the VPC to a Basic Edition TR. A TR connected to this VPC cannot have route synchronization enabled for the VPC. A VPN Gateway associated with this VPC cannot have automatic route propagation enabled.

3. Impacts of re-enabling the feature:

   After you re-enable the feature, the VPC route table is updated with the routes currently propagated from the dynamic route source.

   For example, assume an ECR has four dynamic route entries. If you disable this feature, the dynamic route entries are cleared from the VPC route table. If two more route entries are added to the ECR and you then re-enable the feature, the VPC route table receives six dynamic route entries from the ECR.

variable "name" {
  default = "terraform-example"
}

resource "alicloud_vpc" "defaultVpc" {
  vpc_name = var.name
}

resource "alicloud_route_table" "default" {
  description      = "test-description"
  vpc_id           = alicloud_vpc.defaultVpc.id
  route_table_name = var.name
  associate_type   = "VSwitch"
  route_propagation_enable = true # Set this parameter to true to enable or false to disable dynamic route receiving. 
}

Use a self-managed firewall

You can deploy a self-managed firewall on an ECS instance in your VPC and use a gateway route table to redirect traffic entering the VPC to the firewall for filtering.

GWLB high-availability architecture

You can use a Gateway Load Balancer (GWLB) to distribute traffic across multiple security devices to enhance application security and availability.

Route to an IPv4 gateway

You can use an IPv4 gateway as a unified ingress and egress point for internet traffic to and from your VPC. Combining an IPv4 gateway with a custom route table enables centralized traffic control, unified security policies, and auditing, which reduces the security risks of decentralized access.

Route to an IPv6 gateway

After you enable IPv6 for a VPC, the system automatically adds the following route to the system route table:

• The destination CIDR block is ::/0, and the next hop is the IPv6 gateway.

This route directs default IPv6 traffic to the IPv6 gateway. After you enable internet bandwidth for an IPv6 address, vSwitches associated with the system route table can communicate with the internet.

For an IPv6-enabled vSwitch that is associated with a custom route table, you must manually add the preceding route to the custom route table to enable IPv6 internet access.

For a custom route with an IPv6 gateway instance as its next hop, the destination CIDR block can be set only to ::/0.

Route to a NAT Gateway

If many servers in your VPC need to access the internet and consume a large number of public IP addresses, you can use the SNAT feature of an Internet NAT gateway. SNAT allows multiple ECS instances to share Elastic IP Addresses (EIPs) for internet access. This conserves public IP resources and enhances security by preventing the private IP addresses of the ECS instances from being exposed.

When you use a NAT Gateway, you must add a custom route that points to the Internet NAT gateway to the VPC route table to enable internet access.

• If the vSwitch to which the ECS instance belongs is associated with a custom route table, you must manually add a route where the destination CIDR block is 0.0.0.0/0 and the next hop is the Internet NAT gateway.

• If the vSwitch to which the ECS instance belongs is associated with the system route table:

  • If no route with the destination CIDR block 0.0.0.0/0 exists in the system route table, the system automatically adds a route that points to the Internet NAT gateway.

  • If a route with the destination CIDR block 0.0.0.0/0 already exists in the system route table, you must replace the existing route with a new one that points to the Internet NAT gateway.

Route to a VPC peering connection

VPCs are isolated from each other by default. You can use a VPC peering connection to enable private communication between two VPCs, even if they belong to different accounts or are in different regions. Once a peering connection is established, cloud resources in the VPCs can access each other by using private IPv4 or IPv6 addresses.

Route to a transit router

When you use Cloud Enterprise Network (CEN) to connect VPCs, you must add routes that point to the transit router to the VPC route tables. You can add the routes in one of the following ways:

• When you create a VPC connection, select Automatically add routes to all of the VPC's route tables to point to the transit router.

  After you enable this feature, the system automatically adds three routes with the destination CIDR blocks 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 to all route tables of the VPC. The next hop for these routes is the VPC connection. These routes direct IPv4 traffic from the VPC to the transit router.

• After you enable route learning in the transit router, you can either enable route propagation for each VPC or manually add a route to the peer VPC in each VPC route table.

The following figure shows an example where route learning is enabled in the transit router and a route is manually added to the VPC route table. For this route, the destination CIDR block is the CIDR block of the peer VPC, and the next hop is the transit router.

Route to a VPN Gateway

You can use a VPN Gateway to establish an encrypted tunnel, creating a secure and reliable network connection between your on-premises data center and your VPC.

To use a VPN Gateway, add a route to the VPC route table with the destination CIDR block set to your on-premises data center's CIDR block and the next hop set to the VPN Gateway. This allows the VPC to access the on-premises data center over an IPsec-VPN connection.

Route to an ECS instance or ENI

To inspect, analyze, and protect traffic between two vSwitches in a VPC, you can insert a third-party security device, such as a firewall or a Web Application Firewall (WAF), into the traffic path by adjusting the route tables.

To do so, associate each of the two vSwitches with a separate custom route table and change the next hop of the system routes for the corresponding CIDR blocks to the firewall's ECS instance or its elastic network interface (ENI):

Route to a router interface

You can use the Express Connect VBR-to-VPC connection feature to connect an on-premises data center to your cloud network.

When you use this feature, you must configure a route for the VPC with the destination CIDR block set to the CIDR block of the on-premises data center and the next hop type set to router interface (to VBR). This allows the VPC to access the on-premises data center through a Virtual Border Router (VBR). This next hop type supports equal-cost multi-path (ECMP) and active/standby mode, which requires health checks.

The following figure shows an active/standby deployment.

Route to an Express Connect Router

You can use an Express Connect Router (ECR) to connect an on-premises data center to your cloud network.

• By default, a VPC accepts dynamic routes from the ECR. The destination CIDR block of these routes is the CIDR block of the on-premises data center, and their next hop is the ECR. These routes enable communication between the VPC and the on-premises data center.

• If dynamic route advertisement is disabled for the VPC route table, you must manually add a route to the table with the destination CIDR block set to the CIDR block of the on-premises data center and the next hop set to the Express Connect Router. This enables communication between the VPC and the on-premises data center.

Route to a Gateway Load Balancer endpoint

Gateway Load Balancer endpoints are supported only in these regions. For specific use cases, see Use a gateway route table - GWLB high-availability architecture.

Public cloud regions

Alibaba Finance Cloud regions

Alibaba Gov Cloud regions

Quotas

Usage notes

Billing

The VPC route table feature is free of charge.