Static routing

With static routing, you can route traffic from a subnet to the specified IP address ranges through the VMs specified as the next hop.

Routing is based on route tables. The tables contain static routes consisting of the target subnet's prefix in CIDR notation and the internal IP address of the next hop.

Route tables are linked to a subnet and can't contain duplicate prefixes. Traffic from the subnet with the linked table is routed to the prefixes specified in the routes through the appropriate next hop addresses.

You can also use the prefix in routes. This means that all traffic, if it's not sent via other routes, is routed through the next hop specified for the prefix

For example, a subnet with CIDR has a linked route table with the following routes:

Name Prefix next hop

In this case, all traffic to subnet, which is located in a different virtual network, is routed through the VM with the address All other traffic is routed through the VM with the address Note that overriding the route for prefix may affect the external availability of the VM from the subnet with the table that contains this route.

You currently can't use prefixes from address ranges that are allocated to subnets within a virtual network. Only destination prefixes outside the virtual network are supported, such as subnet prefixes from another Yandex.Cloud network or your local network.

When creating a route, you can set an unused internal IP that isn't linked to a VM as the next hop. In this case, the route is only used after you run a VM with the appropriate IP address.

The two main uses of static route in Yandex.Cloud:

  1. Building a network route to the appropriate subnet through a single VM. The internal IP address is used as the VM ID. For more information about building network routes in Yandex.Cloud and other virtual or local networks, see the tutorials Routing through a NAT instance and Creating an IPSec VPN tunnel.
  2. A fail-safe routing scheme with routes in multiple availability zones. You can create VMs in different availability zones and route them to the same destination subnet. Note that different route tables should be linked to subnets in different availability zones, since you can't place routes to the same prefixes in the same table. If a VM in one of the availability zones fails, VMs from the other zones will remain linked to the destination subnet.

Rerouting traffic to the internet

If the destination prefix of a route from the route table is specified as an internet address prefix, access to and from such addresses via the VM's public IPs from the subnets that this table is linked to is disabled.

For example, let's say there's a VM named vm-1 with a public IP address connected to the my-subnet subnet. If you link a table named my-route-table with a route for the prefix (all addresses) via the next hop to the my-subnet subnet, then access via the vm-1 public address is disabled. This happens because all traffic to and from the my-subnet subnet is now routed via the next hop address.

To keep cloud resources available from a public address, you can:

  • Move resources with public IPs to a separate subnet.
  • Instead of configuring a route to the internet, enable internet access for the subnet via a NAT. The feature is at the preview stage and can be provided by technical support upon request.