10 best practices to configure your VPC

10 best practices to configure your VPC Deploy • Pierre Scacchi, Alexandre Gestat • 13/09/23 • 3 min read

We are delighted to announce the launch of Virtual Private Cloud (VPC) in July 2023, following an extensive effort to migrate and implement new features.

The release of this new product is a great opportunity to review the best practices for VPC configuration. Let's dive into some great tips to ensure you get the most out of your VPC.

1. Create a defined plan with the right CIDR block

A Classless Inter-Domain Routing (CIDR) block is defined for each Private Network of your VPC. Each resource attached to a Private Network of your VPC will be assigned a private IP address inside the subnet defined by the CIDR block. The CIDR block also determines the size of the subnet.

When creating a Private Network in your VPC, Scaleway will automatically define an IPv6 CIDR, and will by default choose an IPv4 CIDR prefix which prevents subnets overlaps between the Private Networks of a VPC. The default subnet size is /22 (up to 1024 resources in your Private Network), which is a safe place to start. Unless you know what you are doing, we recommend Scaleway’s default implementation.

If needed, you can define a custom IPv4 CIDR block that aligns with your organization's current and future needs, in order to avoid potential IP address conflicts and facilitate efficient resource allocation. This will also allow you to determine the subnet size, which could be useful if you want to intentionally limit - or expand - the size of your infrastructure.

2. Spread resources across different Availability Zones

To enhance availability and create a fault-tolerant infrastructure, distribute your resources across multiple Availability Zones (AZs) within a region.

AZs are distinct data centers with independent power, networking, and cooling infrastructure. By spreading your resources, you ensure that your applications remain operational even if one zone experiences a failure. This allows you to mitigate the risk without compromising the security, as you remain isolated from the public Internet.

In the case of a Scaleway Cloud environment, it also allows two or several products to communicate securely across different AZs. For example, if you can create a managed database in PAR1 and later want to use it with an Elastic Metal server in PAR2, letting them communicate securely through a regional Private Network is definitely the way to go.

3. Isolate whenever possible

Every project comes with at least one default VPC per region (so 3 default VPCs per project). Use them (or create new ones if needed) to isolate all your new resources and to migrate your existing ones.

Our VPC product is compatible with Instances, Kapsule, Elastic Metal, RDBs, Redis™, Public Gateways and LoadBalancers, allowing you to isolate most of your infrastructure from the Internet.

Putting everything you can in a private and secure environment should be your default option.

4. Create multiple VPCs if needed

In some cases you may want to isolate different components of your infrastructure for security or organizational reasons. You can then segment your resources by creating multiple VPCs to differentiate application tiers, such as development, staging, and production environments.

Having different VPCs allows you to have finer control over network access and reduce attack surfaces.

A common use case is a CI/CD pipeline where the development cycle is validated from one VPC to another.

5. Use the DHCP for efficient IP Management

Dynamic Host Configuration Protocol (DHCP) automates the assignment of IP addresses within your VPC. It assigns an IP address automatically to every network resource without manual configuration, simplifying network administration and helping developers focus on the core value of their applications.

By using a DHCP, you reduce the time to deploy new resources in the VPC and avoid manual misconfigurations. At Scaleway, the DHCP is built-in inside the VPC and comes at no extra cost. It helps infrastructure have a simple and automatic network configuration, as all of our products that can be attached to a Private Network use by default this automatic IP management.

An IP address allocated to a resource by our managed DHCP will never change, even in case of a shutdown or a reboot of the resource. This will ensure a consistent IP address allocation. Allocated IP addresses will be released when the resource is deleted or detached from the Private Network, so beware that on a detach/reattach action, the private IP will change.

6. Activate DHCP on a legacy Private Network

All Private Networks created after July 12 2023 have DHCP built into them. However, it may not be automatically activated for older Private Networks. Previously, DHCP was a function of Public Gateways. Only legacy Private Networks that were previously attached to a Public Gateway with DHCP will have DHCP automatically activated on them. On all other Private Networks created prior to July 12 2023, DHCP remains deactivated by default.

We highly recommend activating DHCP on all of your Private Networks, to take advantage of itsf IP address management in our fully-integrated ecosystem. Beware that activating DHCP is permanent, and that it will overwrite any existing manually configured static IP addresses for resources attached to the network. So before activating DHCP on a legacy Private Network, check out our documentation and decide whether it is safe for you to do so.

7. Remove public IPs from your Instances

When creating a new Instance and placing it inside your VPC (by attaching it to a Private Network), your Instance has two distinct network interfaces:

The first interface is set up by default during the creation of the Instance. It is a public interface, which uses NAT to translate its IP address into a public FlexIP address everyone on the Internet can see. More details about this public FlexIP in our blog.

The second interface is created when the Instance is attached to the Private Network. This interface has a private IP address within the Private Network CIDR block and is not directly accessible from the Internet.

To fully isolate your Instances in your VPC, detach your public IPv4 address and disable your IPv6 address, too. By doing so, your Instance will only be accessible from your Private Network, reducing the surface for potential threats. Don’t forget to set up a SSH Bastion to keep a secure access to…