A route table in a virtual private cloud (VPC) determines the path that network traffic takes from an instance to a destination. By configuring routes, you can direct network traffic along specified paths.
Features
Route tables
When you create a VPC, the system automatically creates a system route table. This route table is attached to all vSwitches in the VPC by default and controls the 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. You can deploy the ECS instances on different vSwitches and attach a separate custom route table to each vSwitch. This provides fine-grained traffic shaping.
To protect inbound Internet traffic to your VPC with a self-managed firewall, you can use a gateway route table, which is a custom route table attached to a border gateway. You can attach the gateway route table to an IPv4 or IPv6 gateway to direct inbound Internet traffic to your self-managed firewall. This allows for unified traffic filtering, auditing, and security policy management.
The following table describes the differences between the route table types.
Comparison Criteria | Custom route table | Custom Route Table | |
Attached object | vSwitch | vSwitch | IPv4 or IPv6 gateway |
Diagram |  |  |  |
Scenarios | Attached to all new vSwitches by default to centrally control vSwitch traffic | Attached to specific vSwitches to control the traffic paths of the target vSwitches | Attached to an IPv4 or IPv6 gateway for secure inbound Internet traffic redirection |
Creation method | Automatically created by the system when you create a VPC | Manually created. Select the vSwitch type when you create the route table. | Manually created. Select the border gateway type when you create the route table. |
Deletable | Cannot be deleted. | Can be deleted. You must first detach it from the vSwitch. | Can be deleted. You must first detach it from the IPv4 or IPv6 gateway. |
Quota | One system route table per VPC. | By default, you can create nine custom route tables attached to vSwitches in a VPC. You can request a quota increase. | You can create only one route table attached to an IPv4 or IPv6 gateway in a VPC. |
Each vSwitch must be attached to a route table, and can be attached to only one route table. One route table can be attached to multiple vSwitches.
Routes
Each item in a route table is a route. Each route includes:
Destination CIDR block: The range of IP addresses to which network traffic is routed.
Next hop: The destination of the network traffic, such as an elastic network interface (ENI) or a VPC peering connection.
Routes are classified into two types:
1. Static routes: Routes that are automatically or manually added by the system.
2. Dynamic routes: Routes that are propagated to a VPC from other network instances such as transit routers (TRs) and VPN Gateways.
1. Static routes
Static routes are routes that are automatically added by the system or manually added by you. They include two types:
System routes: Routes with the next hop set to
Local. They are 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 Alibaba Cloud services.Custom routes: Routes 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:
After you create the VPC and vSwitch, the system automatically adds system routes with the next hop set to
Local:Cloud service route: The destination CIDR block is
100.64.0.0/10. This route allows instances in VPC1 to access Alibaba Cloud services.vSwitch CIDR block route: The destination CIDR block is
10.0.0.0/24. This route allows private communication between vSwitches in VPC1.
After you create a VPC peering connection, you must manually add the following custom route:
The destination CIDR block is
172.16.0.0/16and the next hop is thepeering connection. This route forwards traffic destined forVPC2to the peering connection.
The routes in the system route table of VPC2 work on the same principle as those in VPC1 and are not described here.
Comparison between system routes and custom routes
Item | System route | Custom route |
Definition | A route with a next hop of | A route that you manually add. |
IPv4 route | The system automatically adds the following routes to all route tables in the VPC:
| You can manually add routes with the following parameters:
|
IPv6 route | If IPv6 is enabled for the VPC, the system automatically adds the following route to all route tables that are associated with a vSwitch in the VPC:
| If IPv6 is enabled for the VPC, you can add routes with the following parameters:
|
Can the next hop be changed? |
| If a custom route is created by changing the next hop of a system route, the next hop of this custom route can be changed only to Local, an ECS instance, an ENI, or a Gateway Load Balancer endpoint. |
Can be manually created | You cannot manually create or delete system routes. | Can be manually created and deleted. |
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 received and updated from dynamic route sources.
2.1 Dynamic route sources
Network instances that automatically propagate routes to a VPC include Enterprise Edition transit routers (TRs), Basic Edition TRs, VPN Gateways, and Express Connect Routers (ECRs). You can view the source and details of dynamic routes on the tab of the route table details page in the console.
The details of routes received from an Enterprise Edition TR are displayed on the tab.
2.2 Enable or disable dynamic route receiving
By default, all route tables are enabled to receive dynamic routes. If you need a purely static routing configuration, you can disable dynamic route receiving for each route table. This lets you plan your business route tables as needed and easily manage route configurations.
2.3 Limits on dynamic routes
A VPC route table can receive dynamic routes from only one dynamic route source at a time.
For example, after a VPC is associated with an ECR, if you connect the VPC to an Enterprise Edition TR, enabling route synchronization for the VPC on the TR will fail. After you create a VPN Gateway and enable automatic BGP route propagation, BGP routes learned by the VPN Gateway are automatically propagated to the system route table of the VPC. In this case, you cannot associate the VPC with an ECR.
If a received dynamic route overlaps with an existing route in the route table, see Route priorities to determine which route takes effect.
Only route tables attached to vSwitches can receive dynamic routes. Gateway route tables do not support dynamic routes.
Route priorities
Routes in a VPC route table are prioritized based on the following rules:
If routes with overlapping destination CIDR blocks exist:
IPv4 and IPv6 traffic routing are independent of each other. 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 in a route table have destination CIDR blocks that can cover the destination IP address, the route with the longest subnet mask is chosen to determine the traffic forwarding path.
When the destination CIDR block of a new route overlaps with that of an existing route:
Operation
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:
Is identical to the destination CIDR block of an existing custom route.
Contains the destination CIDR block of an existing custom route.
The following restrictions apply to a vSwitch CIDR block:
Is the same as the destination CIDR block of an existing dynamic route.
Contains the destination CIDR block of an existing dynamic route.
Add a custom route
The destination CIDR block of the new custom route must not:
Is the same as the CIDR block of an existing system route.
Is more specific than an existing system route.
The destination CIDR block of the new custom route cannot be the same as 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 the same as that of an existing dynamic route.
If the next hop of the new custom route is a VPN Gateway or a router interface, and there is an existing dynamic route from CEN with the same destination CIDR block, the dynamic route is withdrawn and the custom route takes effect.
Receive a dynamic route
When a dynamic route is received:
It 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 is not propagated.
When dynamic routes are received from an ECR: If a custom route with the same destination CIDR block exists, the custom route takes precedence.
The dynamic route is visible in the VPC route table but does not take effect until the custom route is deleted.
When dynamic routes are received from a VPN Gateway, Enterprise Edition TR, or Basic Edition TR: If a custom route with the same destination CIDR block exists, the custom route takes precedence.
In this case, the dynamic route is not propagated to the VPC route table. It is propagated and takes effect only after the custom route is deleted.
Not supported. The current VPC route table has only one route propagation source.
For example, a VPC system route table contains the following routes:
Destination CIDR block | Next hop type | Next hop | Route type |
| - | - | System |
| ECS instance |
| Custom |
| ECS instance |
| Custom |
When the destination IP address of the traffic is different, the traffic is forwarded according to different routes.
Destination IP address of the traffic | Route matching |
| Only |
| Only |
|
The subnet mask of |
Manage route tables
When you create a VPC, the system automatically creates a system route table and attaches it to all vSwitches by default to centrally control the traffic of all vSwitches.
To control the traffic of a specific vSwitch in the VPC separately, you must first create a custom route table of the vSwitch type and then attach it to the target vSwitch.
To control traffic from the Internet to the VPC, you must create a custom route table of the border gateway type and then attach it to an IPv4 or IPv6 gateway.
Create and delete route tables
You must first create a custom route table before you can attach it to a target vSwitch or an IPv4 or IPv6 gateway.
Console
Create a route table
Go to the Route Tables page in the VPC console and click Create Route Table.
Select the target VPC, enter a Name, and select an object type to attach:
VSwitch: After you attach this route table to a vSwitch, you can control the traffic path of the specific vSwitch.
Border Gateway: After you attach this route table to an IPv4 or IPv6 gateway, you can control the path of traffic from the Internet to the VPC.
After you create a custom route table, the system automatically adds the following system routes to it:
vSwitch CIDR block route: A route whose destination CIDR block is the CIDR block of any vSwitch in the VPC to which the route table belongs. This route is used for communication between instances in the vSwitch.
Cloud service route: A route whose destination CIDR block is
100.64.0.0/10. This route is used by instances in the VPC to access Alibaba Cloud services.
Delete a route table
In the Actions column of the target route table or on its details page, click Delete. Before you delete the route table, make sure that it is detached and that all its custom routes are deleted.
Only custom route tables can be deleted. System route tables cannot be deleted.
API
Call the CreateRouteTable operation to create a route table.
Call the DeleteRouteTable operation to delete a custom route table.
Terraform
Resources: alicloud_route_table
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" }Attach and detach route tables
A newly created custom route table is not attached to any resource by default. You must attach it to a vSwitch or an IPv4 or IPv6 gateway for the route table to take effect.
Console
Attach a route table
Go to the Route Tables page in the VPC console. In the Attached Resources column of the target route table, click Attach Now:
If the route table is to be attached to a vSwitch: Click Attach VSwitch. In the dialog box that appears, select the target vSwitch.
After a vSwitch is attached to a custom route table, it is automatically detached from the system route table.
If the route table is to be attached to a Border Gateway: Click Attach Border Gateway. In the dialog box that appears, select the target IPv4 Gateway or IPv6 Gateway.
For a tutorial on how to use a route table attached to a border gateway, see Use a gateway route table to control traffic to a VPC.
Detach a route table
Go to the details page of the target route table:
If the route table is attached to a vSwitch: On the tab, select the vSwitches to detach and click Detach. After detachment, the vSwitch is re-attached to the system route table.
If the route table is attached to a Border Gateway: On the tab, click Detach in the Actions column of the target IPv4 or IPv6 gateway.
Before you detach a route table, fully assess the business impact of the route changes to avoid service disruptions.
API
Call the AssociateRouteTable operation to attach a route table to a vSwitch.
Call the AssociateRouteTableWithGateway operation to attach a route table to an IPv4 or IPv6 gateway.
Before you detach a route table, fully assess the business impact of the route changes to avoid service disruptions.
Call the UnassociateRouteTable operation to detach a route table from a vSwitch.
Call the DissociateRouteTableFromGateway operation to detach a route table from an IPv4 or IPv6 gateway.
Terraform
Attach a route table to a vSwitch
Resources: alicloud_route_table_attachment
Data Sources: alicloud_zones
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 }Attach a route table to an IPv4/IPv6 gateway
Resources: alicloud_vpc_gateway_route_table_attachment
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 }Manage routes
Add and delete routes
For a route table attached to a vSwitch, you can manually add routes to control the traffic path of the vSwitch. Manually added routes are classified as custom routes.
In a gateway route table, you cannot add routes, but you can change the next hop of a route.
Console
Add a route
Go to the details page of the target route table. On the tab, click Add Route Entry.
In the Create Route dialog box, configure the Destination CIDR Block and Next Hop Type. For more information about typical scenarios for different next hop types, see Configuration examples.
If an error occurs when you add the route, check whether the configuration meets the route priority requirements.
Delete a route
In the Actions column of the target route, click Delete.
Before you delete a route, fully assess the business impact to avoid service disruptions.
API
Call the CreateRouteEntry operation to add a single route. Call the CreateRouteEntries operation to add routes in a batch.
Before you delete a route, fully assess the business impact to avoid service disruptions.
Call the DeleteRouteEntry operation to delete a single custom route. Call the DeleteRouteEntries operation to delete custom routes in a batch.
Terraform
Resources: alicloud_route_entry
resource "alicloud_route_entry" "foo" { route_table_id = "rt-12345xxxx" # Specify the route table ID. destination_cidrblock = "172.11.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 of a route
You can change the next hop of a route to alter the traffic path for the destination CIDR block.
System routes: You can change the next hop only for system routes in a custom route table (including a gateway route table). After the change, the route type becomes custom. If you delete the route, it reverts to a system route.
Custom routes: You can change the next hop for custom routes in both system and custom route tables without any route table type restrictions.
For more information about the supported types for Destination CIDR block and Next hop, see Comparison between system routes and custom routes.
Before you change the next hop of a route, fully assess the business impact to avoid service disruptions.
Console
In the Actions column of the target route, click Edit. In the dialog box that appears, click the drop-down list for Next Hop Type and select the target next hop.
For more information about typical scenarios for different next hop types, see Configuration examples.
API
Call the ModifyRouteEntry operation to change the next hop of a route in a route table attached to a vSwitch.
Call the UpdateGatewayRouteTableEntryAttribute operation to change the next hop of a route in a route table attached to an IPv4 or IPv6 gateway.
Terraform
Resources: alicloud_route_entry
resource "alicloud_route_entry" "foo" { route_table_id = "rt-12345xxxx" # Specify the route table ID. destination_cidrblock = "172.11.1.1/32" nexthop_type = "Instance" # Change the next hop type. nexthop_id = "i-12345xxxx" # Specify the next hop instance ID. }Publish and withdraw static routes
Routes from a route table can be propagated to an Express Connect Router (ECR) or a transit router (TR). When combined with dynamic route receiving, this simplifies route configuration.
Publish static routes to an ECR: After a static route is published to an ECR, it can be dynamically propagated from the ECR on the cloud to a data center. If there are no route conflicts, all data centers associated with the ECR can learn this route.
How it works
After a VPC is associated with an ECR, the system routes of the VPC are published to the ECR by default.
After a static route is published 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 data center.
The ECR does not propagate the route to other VPCs associated with it.
If a published static route has a route conflict, you can view the target route on the Routes tab of the ECR. Its status is displayed as Conflict and it will not Take Effect.
Limits
Routes in a custom route table cannot be published to an ECR.
Routes whose destination CIDR block is a prefix list cannot be published to an ECR.
Active/standby routes and ECMP routes whose next hop is a router interface (to VBR) cannot be published to an ECR. After a VPC route is published to an ECR, you can no longer configure ECMP or active/standby routes.
After a VPC route is published to an ECR, if you want to modify the published route, the next hop of the target route can only be set to a route type that supports the publish operation (see the table below).
The following table lists the default publish status of various types of routes in a VPC instance and whether they support publish and withdraw operations.
Example
An enterprise has a data center and a VPC in the China (Hangzhou) region. The enterprise wants to establish stable communication between the cloud and the data center, and ensure that services deployed in the data center can communicate with the Internet.
The enterprise can connect the VPC and a VBR to an ECR, create an Internet NAT gateway with an EIP attached, and then use the feature of publishing routes to the ECR. If there are no route conflicts, the data center associated with the ECR can learn the route to the NAT Gateway through BGP, thus enabling the data center to access the Internet.
Publish static routes to a transit router (TR): After a static route is published to a TR, if there are no route conflicts and route synchronization is enabled for the TR, all network instances connected to the TR can learn this route.
If your VPC is connected to both an ECR and a TR, the actions of publishing VPC routes to the ECR and to the TR are independent and do not affect each other.
Console
Publish a static route
In the VPC Route Publish Status column of the target route, click Publish.
The VPC Route Publish Status column is displayed for a route in the console only after the VPC is connected to a TR or an ECR.
Withdraw a published static route
In the VPC Route Publish Status column of the target route, click Withdraw.
The VPC Route Publish Status column is displayed for a route in the console only after the VPC is connected to a TR or an ECR.
API
For ECR:
Call the PublishVpcRouteEntries operation to publish static routes to an ECR.
Call the WithdrawVpcPublishedRouteEntries operation to withdraw routes that have been published to an ECR.
For TR:
Call the PublishRouteEntries operation to publish static routes to a TR.
Call the WithdrawPublishedRouteEntries operation to withdraw routes that have been published to a TR.
Tab body
Enable or disable dynamic route receiving
By default, all route tables are enabled to receive dynamic routes. If you need a purely static routing configuration, you can disable dynamic route receiving for a route table. This lets you plan your business route tables as needed and easily manage route configurations.
Cases where disabling is supported: The source of dynamic routes is Route Propagation - Type ECR, or no dynamic routes are propagated to the VPC. When no dynamic routes are propagated to the VPC, the Dynamic Route Source is not displayed on the Route Entry List > Dynamic Routes tab of the route table details page.
Disabling is not supported in the following cases: 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 BGP route propagation is enabled for the VPN Gateway.
Effects of disabling:
The VPC route table no longer receives routes propagated from other network instances. If dynamic routes already exist in the route table, they will all be deleted. Proceed with caution.
The VPC cannot be connected to a Basic Edition TR. A TR connected to this VPC cannot enable route synchronization for the VPC. A VPN Gateway associated with this VPC cannot enable automatic BGP route propagation.
Effects of re-enabling after disabling:
After re-enabling, the dynamic routes in the VPC route table are based on the routes currently propagated from the dynamic route source.
For example, if an ECR has four dynamic routes, disabling this switch will clear the dynamic routes from the VPC route table. If two more routes are added to the ECR and you re-enable this switch, the VPC route table will receive six dynamic routes from the ECR.
Console
Go to the Basic Information page of the target route table. Use the Accept Propagated Routes switch to enable or disable dynamic route receiving.
Before you enable or disable dynamic route receiving, fully assess the business impact of the route changes to avoid service disruptions.
API
Call the ModifyRouteTableAttributes operation and modify the RoutePropagationEnable parameter to enable or disable dynamic route receiving.
Before you enable or disable dynamic route receiving, fully assess the business impact of the route changes to avoid service disruptions.
Terraform
Before you enable or disable dynamic route receiving, fully assess the business impact of the route changes to avoid service disruptions.
Resources: alicloud_route_table
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. }Use a gateway route table
A gateway route table lets you direct inbound Internet traffic to security devices for deep inspection and filtering. This helps prevent malicious attacks and unauthorized access, which enhances security. You can also combine a gateway route table with a custom route table to redirect outbound traffic to security devices, which provides comprehensive security for both inbound and outbound traffic.
To use this feature, you must first create a gateway route table and attach it to an IPv4 gateway. Then, you can change the next hop of the system route that corresponds to the vSwitch CIDR block in the route table to one of the following:
ECS Instance or Elastic Network Interface: Used to securely redirect Internet traffic to a specific ECS instance or ENI.
Gateway Load Balancer Endpoint: Used to redirect Internet traffic to third-party security devices in a Gateway Load Balancer (GWLB) scenario.
Only these regions support changing the next hop to a Gateway Load Balancer Endpoint.
Use a self-managed firewall
You can set up a self-managed firewall on an ECS instance in a 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 to different security devices, which improves the security and availability of your applications.
Configuration examples
Different next hop types correspond to different scenarios:
Route to an IPv4 gateway
You can use an IPv4 gateway as a unified entry and exit point between your enterprise VPC and the Internet. When combined with a custom route table, this allows for centralized control of Internet access traffic, which facilitates the implementation of unified security policies and auditing, and reduces security risks from scattered access points.
Route to an IPv6 gateway
After you enable IPv6 for a VPC, the system automatically adds a custom 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 IPv6 Internet bandwidth for an IPv6 address, the vSwitch attached to the system route table can communicate with the Internet.
For a vSwitch with IPv6 enabled that is attached to a custom route table, to communicate with the Internet over IPv6, you must manually add the above route to the custom route table.
For a custom route whose next hop is an IPv6 gateway instance, the destination CIDR block can only be set to ::/0.
Route to a NAT Gateway
If many servers need to actively access the Internet and require many public IP resources, you can use the SNAT feature of an Internet NAT gateway. This allows multiple ECS instances in a VPC to share EIPs for Internet access, which saves public IP resources. Additionally, these ECS instances can access the Internet without exposing their private IP addresses, which reduces security risks.
When using a NAT Gateway, you need to add a custom route to the VPC route table that points to the Internet NAT gateway to enable Internet access.
When the vSwitch to which the ECS instance belongs is attached to a custom route table: You must manually configure a route with the Destination CIDR Block set to
0.0.0.0/0and the Next Hop set to the Internet NAT gateway.When the vSwitch to which the ECS instance belongs is attached to the system route table:
If no route with the destination CIDR block
0.0.0.0/0exists in the system route table, the system automatically configures a route pointing to the Internet NAT gateway.If a route with the destination CIDR block
0.0.0.0/0already exists in the system route table, you must delete the existing route and then add a 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, whether they are in the same account or different accounts, and in the same region or different regions. After a peering connection is established between two VPCs, the Alibaba Cloud resources deployed within them can access each other 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 creating a VPC connection, select Automatically Configure Routes That Point To The Transit Router For All Route Tables Of The VPC.
After you enable this feature, the system automatically configures three routes in all route tables of the VPC instance with destination CIDR blocks 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. The next hop for all of them will point to the VPC connection, directing IPv4 traffic from the VPC instance to the transit router.
After you enable route learning in 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, after route learning is enabled in the transit router, a route is manually added to the VPC route table with the destination CIDR block set to the peer VPC's CIDR block and the next hop set to the transit router.
Route to a VPN Gateway
By establishing an encrypted tunnel through a VPN Gateway, you can create a secure and reliable network connection between your on-premises data center and your VPC.
When using a VPN Gateway, you need to configure a route for the VPC with the Destination CIDR Block set to the data center's CIDR block and the Next Hop set to the VPN Gateway. This allows the VPC to access the data center through an IPsec-VPN connection.
Route to an ECS instance or an elastic network interface
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 WAF) into the traffic path for traffic inspection, analysis, and protection.
To configure this, you can attach each of the communicating vSwitches to a separate custom route table. Then, you can change the next hop of the system route for the corresponding CIDR block to the ECS instance of the firewall or the firewall's elastic network interface (ENI).
Route to a router interface
Using the VBR-to-VPC connection feature of Express Connect, you can connect your on-premises data center to your cloud network.
The VBR-to-VPC connection feature is not enabled by default. To use it, you must contact your business manager to apply.
When using this feature, you need to configure a route for the VPC with the destination CIDR block set to the data center's CIDR block and the next hop type set to Router Interface (to VBR). This allows the VPC to access the data center through the VBR. This type supports ECMP and Active/standby modes, which must be used with health checks:
Active/Standby Mode: Only two instances are supported as next hops. The weight of the active route's next hop is 100, and the weight of the backup route's next hop is 0. If the active route fails its health check, the backup route takes effect.
ECMP: You can select 2 to 16 instances as next hops. The weight for each instance must be the same, within a valid range of 0 to 255. The system distributes traffic evenly among the next hop instances.
The following figure shows the active/standby mode:
Route to an Express Connect Router
Using an Express Connect Router (ECR) with Express Connect, you can connect your on-premises data center to your cloud network.
By default, the VPC receives dynamic routes from the ECR. The destination CIDR block is the data center's CIDR block, and the next hop is the Express Connect Router, which enables communication between the VPC on the cloud and the data center.
If dynamic route receiving is disabled for the VPC route table, you must manually configure a route in the VPC route table with the Destination CIDR Block set to the data center's CIDR block and the Next Hop set to the Express Connect Router. This enables communication between the VPC on the cloud and the data center.
Route to a Gateway Load Balancer endpoint
Only these regions support Gateway Load Balancer Endpoints. For specific use cases, see Use a gateway route table - GWLB high availability architecture.
More information
Area | Regions that support custom route tables |
Asia Pacific - China | China (Hangzhou), China (Shanghai), China (Nanjing - Local Region - Closing Down), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Shenzhen), China (Heyuan), China (Guangzhou), China (Chengdu), China (Hong Kong), China (Wuhan - Local Region), China (Fuzhou - Local Region - Closing Down) |
Asia Pacific - Others | Japan (Tokyo), South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok) |
Europe & Americas | Germany (Frankfurt), UK (London), US (Silicon Valley), US (Virginia), Mexico |
Middle East | UAE (Dubai), SAU (Riyadh - Partner Region) Important The SAU (Riyadh - Partner Region) region is operated by a partner. |
Quotas
Quota name | Description | Default limit | Increase quota |
vpc_quota_route_tables_num | The number of custom route tables that can be created in a VPC. | 9 | Go to the Quota Management page or Quota Center to request a quota increase. |
vpc_quota_route_entrys_num | The maximum number of custom route entries per route table (excluding dynamically propagated route entries) | 200 | |
vpc_quota_dynamic_route_entrys_num | The number of routes that are dynamically propagated to a route table. | 500 | |
vpc_quota_havip_custom_route_entry | The maximum number of custom routes that can point to an HaVip instance. | 5 | |
vpc_quota_vpn_custom_route_entry | The maximum number of custom routes that can point to a VPN gateway in a VPC. | 50 | |
None | The number of tags that can be added to a route table. | 20 | Cannot be increased. |
The number of vRouters that can be created in a VPC. | 1 | ||
The maximum number of routes that can point to a transit router (TR) connection in a VPC. | 600 |
Limits
Route table limits
Each vSwitch must be attached to a route table, and can be attached to only one route table. One route table can be attached to multiple vSwitches.
Only custom route tables can be deleted. System route tables cannot be deleted.
Route limits
Static route limits:
You cannot manually create or delete system routes.
You can create a custom route with a destination CIDR block that is more specific than the 100.64.0.0/10 cloud service system route, but the CIDR block cannot be the same. Configure more specific routes with caution because if a route is misconfigured, some Alibaba Cloud services may become inaccessible.
For a custom route whose next hop is an IPv6 gateway instance, the destination CIDR block can only be set to
::/0.The VPC Route Publish Status column is displayed for a route in the console only after the VPC is connected to a TR or an ECR.
When the destination CIDR block of a new route overlaps with that of an existing route, adding the new route is not supported in some cases. For more information, see Route priorities.
Static route publishing limits:
Routes in a custom route table cannot be published to an ECR.
Routes whose destination CIDR block is a prefix list cannot be published to an ECR.
Active/standby routes and ECMP routes whose next hop is a router interface (to VBR) cannot be published to an ECR. After a VPC route is published to an ECR, you can no longer configure ECMP or active/standby routes.
After a VPC route is published to an ECR, if you want to modify the published route, the next hop of the target route can only be set to a route type that supports the publish operation (see the table below).
The following table lists the default publish status of various types of routes in a VPC instance and whether they support publish and withdraw operations.
Dynamic route limits:
A VPC route table can receive dynamic routes from only one dynamic route source at a time.
For example, after a VPC is associated with an ECR, if you connect the VPC to an Enterprise Edition TR, enabling route synchronization for the VPC on the TR will fail. After you create a VPN Gateway and enable automatic BGP route propagation, BGP routes learned by the VPN Gateway are automatically propagated to the system route table of the VPC. In this case, you cannot associate the VPC with an ECR.
If a received dynamic route overlaps with an existing route in the route table, see Route priorities to determine which route takes effect.
Only route tables attached to vSwitches can receive dynamic routes. Gateway route tables do not support dynamic routes.
Billing
The VPC route table feature is free of charge.