NavigationContentFooter
Jump toSuggest an edit

Understanding VPC routing

Reviewed on 03 December 2024Published on 28 May 2024

Overview

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.

  • An Elastic Metal server on Private Network A can send a packet to the public internet via a Public Gateway also attached to Private Network A.
  • An Instance also on Private Network A can send a packet to an Instance on Private Network B, via the vRouter.
  • The same Instance on Private Network A can send a packet to an IP destination at the other end of the VPN hosted on Instance XYZ on Private Network B, thanks to a custom route.

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.
    • For local subnet routes, the next hop will be the relevant Private Network. Traffic destined for an IP within the CIDR block of the Private Network’s subnet will find the attached resource there.
    • For custom routes, the next hop is a defined resource on a defined Private Network.
    • If the destination IP is not known on the VPC (represented by the 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).
  • 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, or a user-defined description for custom routes.
Important

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.

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 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.

Limitations

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.

Was this page helpful?
API DocsScaleway consoleDedibox consoleScaleway LearningScaleway.comPricingBlogCareers
© 2023-2024 – Scaleway