Jump toSuggest an edit

Understanding VPC routing

Reviewed on 28 May 2024Published on 28 May 2024


VPC routing allows Private Networks in the same VPC to communicate with each other via automatically-created and managed routes.

Every time you create a Private Network in a VPC with routing activated, 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.

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 the ability to create custom routes.

The diagram below shows 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. An Elastic Metal server on Private Network A is therefore able to find the route to send a packet to the public internet via a Public Gateway also attached to Private Network A. An Instance also on Private Network A is able to send a packet to an Instance on Private Network B, via the vRouter.

Route table

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:

  • A destination IP or IP range. This specifies that the route applies to traffic with a matching destination IP.
  • A next hop. This specifies where the VPC should forward traffic that is trying to reach the destination IP. If the destination IP falls within the CIDR block of a Private Network, its next hop will be that Private Network, where it will find the attached resource with the specific private IP address specified by the destination. If the destination IP is not known on the VPC (represented by the 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).
  • A description. This helps to describe the type of route, e.g. Local subnet route for routes to Private Networks, or Default route to internet for routes to Public Gateways.

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 is applied before a default route to

Scaleway VPC routing supports both IPv4 and IPv6 protocols. Managed routes to Private Networks are simultaneously generated for both IPV4 and IPV6, and both are added to the route table. 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 Private Network in the VPC, or attach a Public Gateway to a Private Network and set it to advertise a default route. These routes are fully managed by Scaleway. Currently, only auto-created, managed routes are available, though in the future you will also be able to create your own custom routes.

Usage considerations

Bear in mind the following when activating VPC routing:

  • Once activated on a given VPC, routing cannot be deactivated on that VPC.
  • When routing is activated, all Private Networks on the VPC can communicate.
  • We do not yet offer the ability to create custom routes, though this is planned for the near future.
  • We do not currently offer an ACL/firewall feature to prevent communication between certain Private Networks/resources once routing is activated. However, users may choose to configure ACLs directly on certain resources (e.g. Instances, Elastic Metal servers) using tools such as iptables or nftables.
  • Public Gateways remain scoped to the Private Network 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.

Best practices

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:

  • Improve network performance by reducing broadcast traffic and congestion
  • Enhance manageability via a logical organization of resources
  • Enable easier troubleshooting, monitoring and maintenance
  • Allow for easier scalability

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.


Managed Databases are not currently compatible with routing. The VPC cannot automatically route between Managed Databases on different Private Networks, or (for example) between a Managed Database on one Private Network and an Instance on a different Private Network.

Docs APIScaleway consoleDedibox consoleScaleway LearningScaleway.comPricingBlogCarreer
© 2023-2024 – Scaleway