Virtual Private Cloud:VPC route table

Route tables

When you create a Virtual Private Cloud (VPC), the system automatically creates a System Route Table. By default, this route table is associated with all vSwitches in the VPC and controls traffic within the VPC.

If different Elastic Compute Service (ECS) instances in a VPC need to use different network paths to access the same destination CIDR block, you can use a Custom Route Table. By deploying the ECS instances on different vSwitches and associating a unique Custom Route Table with each vSwitch, you can achieve fine-grained traffic control.

To protect inbound Internet traffic to your VPC with a self-managed firewall, you can use a Gateway Route Table, which is a type of Custom Route Table associated with a Border Gateway. By associating the Gateway Route Table with an IPv4/IPv6 Gateway, you can direct inbound Internet traffic to a self-managed firewall for centralized filtering, auditing, and security policy management.

The following table compares the different types of route tables.

Feature	System Route Table	Custom Route Table
Associated object	vSwitch	vSwitch	IPv4/IPv6 Gateway
Diagram
Use cases	Associates with all new vSwitches by default to centrally control their traffic.	Associates with specific vSwitches to control their individual traffic flow.	Associates with an IPv4/IPv6 Gateway to securely redirect inbound Internet traffic.
Creation method	Created automatically when you create a VPC.	Created manually. Select vSwitch as the route table type.	Created manually. Select Border Gateway as the route table type.
Deletion	Cannot be deleted.	Can be deleted. You must first disassociate it from the vSwitch.	Can be deleted. You must first disassociate it from the IPv4/IPv6 Gateway.
Quota	One System Route Table per VPC.	By default, a VPC supports up to nine Custom Route Tables associated with vSwitches. You can request a quota increase.	A VPC supports only one route table associated with an IPv4/IPv6 Gateway.

Each vSwitch must be associated with exactly one Route Table. A single Route Table can be associated with multiple vSwitches.

1. Static routes

Static routes include two types:

• System Route: A route with a Next Hop of Local. The system automatically adds this type of route when you create a VPC and a vSwitch. These routes are used for communication between instances within the VPC or to access Alibaba Cloud services.

• Custom Route: A route that you manually add to customize traffic paths.

As shown in the following figure, two VPCs are connected through a VPC Peering Connection. The System Route Table of VPC1 contains the following static routes:

1. After you create a VPC and a vSwitch, the system automatically adds System Routes with the Next Hop set to Local:

   1. Alibaba Cloud service route: The Destination CIDR Block is 100.64.0.0/10. This route allows instances in VPC1 to access Alibaba Cloud services.

   2. vSwitch route: The Destination CIDR Block is 10.0.0.0/24. This route allows private communication between 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 routes in the System Route Table of VPC2 follow the same principle as those in VPC1 and are not described further.

2. Dynamic routes

Dynamic routes are routes propagated to a VPC from other network instances. Unlike static routes, you do not need to manually configure dynamic routes in the VPC Route Table. They are automatically learned and updated from dynamic route sources.

Route priority

Routes in a VPC Route Table are prioritized as follows:

• When routes with overlapping Destination CIDR Blocks exist:

  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 determines the Next Hop for traffic forwarding.

  Longest Prefix Match: When multiple routes have Destination CIDR Blocks that match a packet's destination IP address, the system uses the route with the longest subnet mask (the most specific network range). For example, traffic destined for 192.168.1.100 matches the 192.168.1.0/24 route before it matches the 192.168.0.0/16 route.

• When the Destination CIDR Block of a new route overlaps with that of an existing route:

  Actions	Existing system route	Existing custom route	Existing dynamic route
  Create a vSwitch	The CIDR block of the vSwitch cannot overlap with 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.	The Destination CIDR Block of the 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 equal-cost multi-path (ECMP) routes. For more information, see Route to a router interface.	When you add a Custom Route, its Destination CIDR Block cannot be identical to that of an existing Dynamic Route. If the Next Hop of the new Custom Route is a VPN Gateway or 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 have the same Destination CIDR Block as an existing System Route. If it is more specific than an existing System Route, the dynamic route does not take effect: If the route source is an ECR, the dynamic route is displayed in the VPC Route Table but does not take effect. If the route source is a VPN Gateway, Enterprise Edition Transit Router (TR), or Basic Edition Transit Router (TR), the dynamic route is not propagated to the VPC Route Table.	If it has the same Destination CIDR Block as an existing Custom Route, the dynamic route does not take effect. If the route source is an ECR, the dynamic route is displayed in the VPC Route Table but does not take effect. If the route source is a VPN Gateway, Enterprise Edition Transit Router (TR), or Basic Edition Transit Router (TR), the dynamic route is not propagated to the VPC Route Table. After the Custom Route is deleted, the dynamic route automatically takes effect.	Not supported. The current VPC Route Table has only one route propagation source.

Create and delete route tables

Create a Custom Route Table before you associate it with a vSwitch or an IPv4/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 unassociate route tables

By default, a new Custom Route Table is not associated with any resource. You must associate it with a vSwitch or an IPv4/IPv6 Gateway for it to take effect.

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 a route entry

You can add a Custom Route to a Route Table for a VSwitch to control its traffic path.

You cannot add a Route Entry to a Route Table that is associated with an IPv4 or IPv6 gateway, but you can change the next hop of a Route Entry.

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

Change the next hop

You can change the Next Hop of a Route Entry to change the traffic path for the Destination CIDR Block.

• System Route: You can change the Next Hop of a System Route only if it is in a custom Route Table (including a gateway Route Table). After the change, the Route Entry becomes a Custom Route. If you delete this Custom Route, the original System Route is restored.

• Custom Route: You can change the Next Hop of a Custom Route in both system and custom Route Tables.

For information about the supported types for Destination CIDR Block and Next Hop, see System routes vs. custom routes.

Publish and withdraw a static route

Route Entries in a Route Table can be published to an Express Connect Router (ECR) or a Transit Router (TR). Combined with Dynamic Route Receiving, this feature simplifies your route configuration.

• Publish static routes to an Express Connect Router (ECR): After a static route is published to an ECR, the ECR dynamically propagates the route to an on-premises data center. If no Route Conflict exists, all on-premises data centers associated with the ECR can learn this route.

  ECR route publishing

  How it works

  • After a Virtual Private Cloud is associated with an ECR, the System Routes of the Virtual Private Cloud are published to the ECR by default.

  • After you publish a static route to an ECR:

    • The ECR propagates the route to its associated Virtual Border Router (VBR). If BGP is enabled on the VBR, the route is then propagated to the on-premises data center.

    • The ECR does not propagate the route to other Virtual Private Cloud networks associated with it.

  • If a published static route conflicts with an existing route, you can view the Route Entry on the Routes tab of the ECR. The status of the Route Entry is displayed as Conflicting and the route does not become Active.

  Limitations

  • Route Entries that are configured in a custom Virtual Private Cloud Route Table cannot be published to an ECR.

  • A Route Entry whose Destination CIDR Block is a prefix list cannot be published to an ECR.

  • Active/standby routes and Equal-Cost Multi-Path (ECMP) routes whose Next Hop is a router interface (to VBR) cannot be published to an ECR. After a Virtual Private Cloud route is published to an ECR, you can no longer configure ECMP or active/standby routes for that Route Entry.

  • After a Virtual Private Cloud route is published to an ECR, if you modify the Route Entry, you can set the Next Hop only to a type that supports publishing, as described in the following table.

  • The following table lists the default advertisement status for different types of Route Entries and indicates whether Publish and Withdraw operations are supported.

    Route entry advertisement status

    Route type	Route entry instance	Published by default	Publish supported	Withdraw supported
    VPC System Route	VPC	Yes	Yes	Supported only in the Malaysia (Kuala Lumpur) region.
    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	Not supported	Not supported
    Route Entry to a Transit Router	VPC	No	Not supported	Not supported
    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 (ENI)	VPC	No	Yes	Yes
    Route Entry to a High-Availability Virtual IP (HaVip)	VPC	No	Yes	Yes
    Route Entry to a router interface (to VBR)	VPC	No	Not supported	Not supported
    Route Entry to a router interface (to VPC)	VPC	No	Not supported	Not supported
    Route Entry to an Express Connect Router	VPC	No	Not supported	Not supported
    Route Entry to a Gateway Load Balancer endpoint	VPC	No	Yes	Yes

  Use case

  An enterprise has an on-premises data center and a Virtual Private Cloud in the China (Hangzhou) region. The enterprise wants to establish stable communication between the Virtual Private Cloud and the data center, and ensure that services deployed in the data center can access the internet.

  The enterprise can connect the Virtual Private Cloud and a VBR to an ECR, create a NAT Gateway with an EIP attached, and then publish routes to the ECR. If no Route Conflict exists, the on-premises data center can learn the route to the NAT Gateway through BGP. This allows the data center to access the internet.

  

• Publish static routes to a Transit Router (TR): After a static route is published to a Transit Router, if no Route Conflict exists and route synchronization is enabled for the TR, all network instances connected to the TR learn this route.

If your Virtual Private Cloud is connected to both an ECR and a TR, publishing Route Entries to the ECR and to the TR are independent of each other.

Enable and disable dynamic route receiving

By default, all Route Tables receive dynamic routes. If you require a purely static routing configuration, you can disable Dynamic Route Receiving for a specific Route Table to manage your routing configurations as needed.

1. You can disable Dynamic Route Receiving if the dynamic route source is Route Propagation-Type ECR, or no dynamic routes are propagated to the Virtual Private Cloud. If no dynamic routes are propagated to the Virtual Private Cloud, Dynamic Route Source is not displayed on the Route Entry List > Dynamic Route tab of the Route Table details page.

   You cannot disable Dynamic Route Receiving in the following cases: The Virtual Private Cloud is connected to a Basic Edition TR. The Virtual Private Cloud is connected to an Enterprise Edition TR and route synchronization is enabled for the Virtual Private Cloud on the TR. The Virtual Private Cloud is associated with a VPN Gateway and automatic BGP route propagation is enabled for the VPN Gateway.

2. Impact of disabling the feature:

   • The Virtual Private Cloud Route Table no longer receives routes propagated from other network instances. If dynamic routes exist in the Route Table, the system deletes them. Proceed with caution.

   • The Virtual Private Cloud cannot be connected to a Basic Edition TR. A TR connected to this Virtual Private Cloud cannot enable route synchronization for the Virtual Private Cloud. You cannot enable automatic BGP route propagation for a VPN Gateway associated with this Virtual Private Cloud.

3. Impact of re-enabling the feature after it is disabled:

   After you re-enable the feature, the system updates the dynamic routes in the Virtual Private Cloud Route Table based on the routes propagated from the dynamic route source.

   For example, assume that an ECR has four dynamic routes. If you disable this feature, the dynamic routes are cleared from the Virtual Private Cloud Route Table. If two more Route Entries are added to the ECR and you then re-enable this feature, the Virtual Private Cloud Route Table receives six dynamic routes 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 # Modify this parameter to enable or disable Dynamic Route Receiving. 
}

Using a self-managed firewall

You can deploy a self-managed firewall on an ECS Instance in a Virtual Private Cloud (VPC) and use a Gateway Route Table to redirect traffic that enters the VPC to the firewall for filtering.

GWLB high-availability architecture

You can use a Gateway Load Balancer (GWLB) to distribute traffic among different security devices to improve the security and availability of your applications.

Route to an IPv4 Gateway

You can use an IPv4 Gateway as a unified ingress and egress point for traffic between your Virtual Private Cloud (VPC) and the internet. When used with a custom route table, an IPv4 Gateway enables centralized control of internet access traffic. This setup helps you implement uniform security policies and simplifies auditing, reducing the security risks of distributed access points.

Route to an IPv6 Gateway

After you enable IPv6 for a Virtual Private Cloud (VPC), the system automatically adds a 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 public bandwidth for an IPv6 address, vSwitches associated with the system route table can communicate with the internet.

For an IPv6-enabled vSwitch 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 where the next hop is an IPv6 Gateway, the destination CIDR block must be ::/0.

Route to an Internet NAT Gateway

If you have many servers that initiate connections to the internet, you can use the source network address translation (SNAT) feature of an Internet NAT Gateway. This lets multiple ECS instances in your Virtual Private Cloud (VPC) to share Elastic IP addresses (EIPs) for internet access. This setup saves public IP resources and reduces security risks by not exposing their private IP addresses.

To enable internet access through an Internet NAT Gateway, you must add a custom route to the VPC route table that directs traffic to the gateway.

• If the VSwitch of an ECS instance is associated with a custom route table, you must manually configure a route entry where the Destination CIDR Block is 0.0.0.0/0 and the Next Hop is the Internet NAT Gateway.

• If the ECS instance's vSwitch 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 pointing 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 first delete the existing route and then add a new route pointing to the Internet NAT Gateway.

Route to a VPC Peering Connection

VPCs are isolated from each other, but you can use a VPC Peering Connection to enable private communication between two VPCs in the same or different accounts and regions. After a peering connection is established between two VPCs, cloud resources deployed 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 do this in one of the following ways:

• When you create a VPC connection, select Automatically Create Route That Points to Transit Router and Add to All Route Tables of Current VPC.

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

• After you enable route learning on the Transit Router, you can either enable route synchronization for each VPC or manually add a route in each VPC route table that points to the peer VPC.

The following figure shows an example where a route is manually added to the VPC route table after route learning is enabled on the Transit Router. The route's destination CIDR block is the CIDR block of the peer VPC, and its next hop is the Transit Router.

Route to a VPN Gateway

Use a VPN Gateway to establish a secure and reliable encrypted tunnel between an on-premises data center and your VPC.

When you use a VPN Gateway, you must add a route to the VPC. In this route, set the Destination CIDR block to the CIDR block of the on-premises data center and set the next hop to the VPN Gateway. This lets the VPC access the on-premises data center through an IPsec-VPN connection.

Route to an ECS instance or ENI

When two vSwitches in a VPC need to communicate, you can adjust the route tables to insert a third-party security device, such as a firewall or a Web Application Firewall (WAF), into the traffic path to inspect, analyze, and protect traffic.

To configure this, associate each communicating vSwitch with a separate custom route table. Then, change the next hop of the system route for the corresponding CIDR block to the ECS instance or Elastic Network Interface (ENI) of the firewall.

Route to a router interface

The VBR-to-VPC connection feature of Express Connect lets you connect your on-premises data center to your VPC.

When you use this feature, you must add a route to the VPC. In this route, set the destination CIDR block to the CIDR block of the on-premises data center and set the next hop type to router interface (to VBR). This allows the VPC to access the on-premises data center through the Virtual Border Router (VBR). This next hop type supports Equal-Cost Multi-Path (ECMP) and active/standby modes. You must use these modes with health check:

The following figure shows the active/standby mode:

Route to an Express Connect Router

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

• By default, a VPC accepts dynamic routes from an ECR. For these routes, the destination CIDR block is the CIDR block of the on-premises data center and the next hop is the ECR. This configuration enables communication between the VPC and the on-premises data center.

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

Route to a Gateway Load Balancer endpoint

The Gateway Load Balancer endpoint next hop type is available only in these regions. For specific use cases, see Use a gateway route table - GWLB high-availability architecture.

Quotas

Limits

Billing

Route Tables are a free feature of VPC.