Getting the most from Private Networks

This document sets out guidance, advice and best practices for building and optimizing your Scaleway VPCs and Private Networks.

Private Networks and VPC definitions

VPC allows you to build your own Virtual Private Cloud on top of Scaleway’s shared public cloud. Within each VPC, you can create Private Networks. Resources attached to Private Networks can communicate securely between themselves, away from the public internet, reducing security risks by ensuring traffic is isolated from public routes.

The VPC operates at the network layer (layer 3) of the OSI model, while Private Networks are a layer 2 resource. As such, a VPC is responsible for routing packets between its different Private Networks. Private Networks provide network isolation within a VPC and enable you to segment your resources and traffic across different subnets.

VPCs and Private Networks are both regional resources. When you create a Private Network in a VPC, it is necessarily scoped to the same region as the VPC. Some Scaleway resources are also regional, others are zonal and scoped to a single Availability Zone (AZ). When attaching resources to a Private Network, you can attach resources from any AZ within the Private Network’s region, allowing for example an Elastic Metal server in PAR-2 to communicate securely, away from the public internet, with an Instance in PAR-1 and a Managed Database in PAR-3.

One default VPC for each region is automatically created in each Scaleway Project. The VPC routing feature allows for managed and custom routes between the Private Networks of a VPC, so resources on different Private Networks can communicate.

Designing your network topology

When you start creating resources and building your infrastructure with Scaleway, take some time to consider and plan your network topology. 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 Scaleway introduces further features such as ACLs for VPC.

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, stripping other resources of public IP addresses. You may want to create different VPCs for production and test environments, allowing you to isolate potential errors in testing from the production environment.

When creating a Private Network, you can let Scaleway automatically generate a CIDR block for it that is guaranteed to be unique in this VPC. All resources attached to the Private Network get a private IP address from this block. However, you also have the option to define your own CIDR block for the network. Ensure you choose a prefix and network size that is appropriate for your needs, does not overlap with that of any other Private Network in the VPC, and contains enough IP addresses for all resources that will be attached to the Private Network.

Attaching resources to Private Networks

When you attach a resource (e.g. an Instance, an Elastic Metal server) to a Private Network, you can either:

• Let Scaleway automatically assign any IP address from the Private Network’s CIDR block to use for the attachment, or
• Define a specific, reserved IP address from the CIDR block to use for the attachment.

Auto-assigning an IP address

This solution is best for simplicity, dynamic environments, and short-lived resources. It can be especially useful in large-scale deployments where manual IP management could be cumbersome. When you let Scaleway automatically assign IP addresses, we ensure there are no IP conflicts within your VPC, reducing any risk of human error.

Note that when you select this option, the IP address randomly assigned to the resource will be stable, and does not risk changing until you detach the resource from the Private Network. At this point, the private IP address is released back into the pool of generally available addresses from the network’s CIDR block, and may be auto-assigned to another resource requesting attachment.

Using reserved IP addresses

You can reserve private IP addresses from your Private Networks’ CIDR blocks thanks to Scaleway’s IP Address Management solution, which helps you plan, track and manage the IP address space of your VPCs and their Private Networks. From the IPAM space in the Scaleway console, simply use the Reserve private IP feature to select the Private Network you want to reserve an IP address on, and choose to either reserve any available address, or a specific address not currently attached to any resource. The reserved address will then not risk being auto-assigned by Scaleway to other resources during network attachment, and can be kept until you are ready to use it to attach a specific resource.

Further, when you attach a resource to a Private Network and specify a reserved IP to use, the IP will remain reserved even after you detach the resource from the network. You can choose to either release the IP back into the pool, or keep it reserved until you use it to attach another resource.

Using reserved IP addresses is ideal to ensure that certain IP addresses are never released into the general pool and kept for certain critical resources with fixed IP requirements, even when that resource is detached from the Private Network, or when migrating between resources. Reserved IP addresses may also be useful where your Private Network is extending or integrating with external networks, or to assign addresses to virtual machines hosted on Elastic Metal servers via Proxmox.

Removing public IPs from resources

We strongly recommend that you disable public connectivity on all of your Scaleway resources, unless it is absolutely required. It is preferable to attach resources to Private Networks wherever possible, and direct all traffic to the resource’s private IP address on that network. This ensures optimal security, reduced cost and enhanced latency. Find out more in our documentation about public connectivity best practices.

Public connectivity over Private Networks

Public Gateways

You can use Scaleway Public Gateways to provide resources on a Private Network with a secure point of access to and from the public internet.

• Set the Public Gateway to advertize a default route to the internet, allowing attached resources to send packets to the internet via the gateway, without needing their own public IP address.
• Activate the SSH bastion so that you can establish SSH connections to resources on the Private Network via the gateway’s bastion.
• Use static NAT to map ingress traffic from the public internet towards resources on the Private Network, using private IP addresses and ports.

Load Balancers

Another option is to attach a Scaleway Load Balancer to the Private Network. By giving the Load Balancer a public IP address, and configuring Instances on the Private Network as backend servers for the Load Balancer via their private IP addresses, the Load Balancer can securely and efficiently distribute traffic to the Instances. This solution is suitable when you have multiple Instances serving the same application, although you can also use multiple frontends/backends and routes to direct traffic to specific server pools.

You can also disable public connectivity on the Load Balancer itself. This may be relevant if the Load Balancer is configured to receive and distribute traffic from resources on a different Private Network within the same VPC, for example.

Connecting a VPC to external infrastructure

Watch this space for Scaleway’s upcoming solution to provide private, secure connectivity between resources in a Scaleway VPC and your external or on-premises architecture. In the meantime, you may consider installing a manual VPN on a Scaleway Instance to connect to other non-Scaleway infrastructure, and create a custom route towards this VPN so traffic on your Private Network can securely communicate with resources at the other end of your VPN tunnel.

Resource-specific information

Different types of Scaleway resources may have different requirements and possibilities in terms of Private Networks. See the comparative table below for more information, and to jump to the resource-specific documentation on Private Networks for each product.

• Max attached PNs: The maximum number of Private Networks that a resource can be attached to
• Mandatory PN: Whether or not a Private Network must necessarily be attached to this resource
• Compatible with private IPv6: Whether or not the resource is compatible with private IPv6 addressing. Compatible resources generally acquire both an IPv4 and an IPv6 address when attached to a Private Network.
• Compatible with reserved IPs: Whether or not you can use a reserved IP to attach the resource to a Private Network