VPC routing allows resources and Private Networks in the same VPC to communicate with each other via automatically-created managed routes, and user-defined custom routes.
When you create a Private Network, a managed route is automatically created and added to the VPC’s route table. This route allows the VPC to automatically route packets to resources attached to that Private Network, even if they originate from a resource attached to a different Private Network on the VPC.
Managed routes are also automatically added to the VPC’s routing table when you attach a Public Gateway to a Private Network, and tell it to advertise the default route. This type of managed route allows traffic on the given Private Network to be forwarded to addresses outside the VPC (i.e. the public internet) via the Public Gateway.
You can create your own custom routes to send traffic for defined IP ranges towards a specified resource in the VPC, for example if you want to route to a VPN installed on an Instance.
Routing is activated by default whenever you create a new VPC, and can be activated on pre-existing VPCs by following these steps. More routing features are planned for the future, such as ACLs and firewalling.
The diagram below shows an example of how routing works across two Private Networks on a VPC. The route table is held on the VPC’s virtual router (VRouter), and synched to each resource as it joins a Private Network.
Every VPC has an associated route table, used to manage and control the routing of traffic within the VPC. The routes within a route table tell the VPC where to send traffic trying to get to a specific destination IP address. One line in the route table corresponds to one route. A route consists of:
0.0.0.0/0 address), its next hop will be a Public Gateway so that it can reach the public internet (as long as a Public Gateway set to advertise the default route has been attached to the Private Network).Local subnet route for routes to Private Networks, or Default route to internet for routes to Public Gateways, or a user-defined description for custom routes.Public Gateways remain scoped to the Private Network(s) to which they are attached. They do not advertise the default route on other Private Networks in the VPC. For example, an Instance attached to Private Network A will not be able to access the internet via a Public Gateway in Private Network B.
When deciding which route to apply, the route table reads the routes from most specific to least specific, in terms of destination IP range. The first matching route encountered is the one that determines the path for the traffic. Therefore, a route to destination 172.16.8.0/22 is applied before a default route to 0.0.0.0/0.
Scaleway VPC routing supports both IPv4 and IPv6 protocols. Managed routes to Private Networks (local subnet routes) are simultaneously generated for both IPV4 and IPV6, and both are added to the route table. As Public Gateways do not support IPv6, routes to them are generated for IPv4 traffic only. Custom routes are only created for the IP type specified during the creation process. When reading your route table, a toggle allows you to switch between the default view of IPV4 routes, to an alternative view of IPV6 routes.
A VPC’s route table displays in the Routing tab of the console. The route table is populated with routes when you either create a custom route,or create a Private Network in the VPC, or attach a Public Gateway to a Private Network and set it to advertise a default route.
Bear in mind the following when activating VPC routing:
iptables or nftables.We recommend that you build your VPC infrastructure with separation of concerns in mind. Separation of concerns is a fundamental design principle aimed at breaking down large complex systems into smaller, distinct components each with clear responsibilities and interfaces. This kind of design will future-proof your VPC and come into its own when we introduce features such as custom routing and ACLs.
Separating resources into different Private Networks according to function and usage can:
For example, you may use one Private Network for frontend resources and another for backend resources, limiting public access only via Load Balancers and/or Public Gateways.