Migrate from Private Networks to VPC

Exoscale doesn’t migrate Private Networks to VPC automatically, but you can do it yourself without downtime. An instance can be attached to a Private Network and to a VPC Subnet at the same time, so the migration runs both networks side by side:

1. Attach every instance to a VPC Subnet in addition to its Private Network.
2. Move your clients to the VPC addresses, one service at a time.
3. Remove the Private Network once nothing uses it anymore.

The Private Network keeps working until the last step. If something goes wrong, you can roll back at any point by pointing your clients back to the Private Network addresses.

Before You Start

Private Networks and VPCs work differently on two points that are important to keep in mind.

VPC Is a Routed Network

A Private Network is a layer 2 segment. A VPC is a layer 3 network that only carries IPv4 unicast traffic. This means that a few Private Network use cases can’t be migrated without changes. These use cases include:

• IPv6 addresses on the Private Network.
• Broadcast or multicast, such as VRRP/keepalived in multicast mode, mDNS or NetBIOS discovery.
• Your own DHCP or PXE server.
• A virtual IP moved between instances with gratuitous ARP. In a VPC, ARP is answered by the platform, and an instance can only send traffic from its own VPC address unless it was created with IP forwarding.

Security Groups Filter VPC Traffic

Security Group rules don’t apply to traffic inside a Private Network, but they apply to VPC interfaces. Traffic that flows freely on your Private Network today is dropped on the VPC until you add specific rules that allow it.

Step 1: Plan and Create Your VPC Subnets

Create one Subnet for each Private Network you migrate, in the same zone as your instances. You can create a new VPC or use the default VPC of the zone.

Give each Subnet an IPv4 block that doesn’t overlap with the range of its Private Network, or with any other range your instances use.

Step 2: Allow Private Traffic in Security Groups

List the traffic that flows over your Private Network today, and add Security Group rules that allow it before any of it moves to the VPC. Rules can target the Security Group of the clients or the IPv4 block of a Subnet.

If a Security Group has egress rules, only the traffic they allow can leave its instances. Add matching egress rules for the VPC traffic too.

If you want a quick way forward that matches the current behavior of Private Networks, you can add all the instances of a given Private Network to one Security Group, with a self-referencing rule that allows all traffic. The instances in this Security Group can then communicate freely, like they did over the Private Network.

$ exo compute security-group create subnet-internal-communication
$ exo compute security-group rule add subnet-internal-communication --protocol all --security-group subnet-internal-communication

Step 3: Attach Your Instances to the Subnet

Attach each instance to its new VPC Subnet. You can choose its address yourself with the --ipv4 option, or let the platform pick a random one for you.

A new network interface appears in each instance and gets its address through DHCP. Check it with ip address. On older templates, you might need to start the DHCP client on this interface yourself, as described in the Quick Start.

Then make your services reachable on the VPC addresses as well:

• Services bound to a Private Network address must also listen on the VPC address.
• Host firewall rules (nftables, iptables, ufw) that reference the Private Network interface or range must be extended to the VPC ones.

Before moving to the next step, you can confirm that clients can reach the service over the VPC:

ubuntu@app-1:~$ ip route get 10.100.0.12
ubuntu@app-1:~$ nc -zv 10.100.0.12 5432

Step 4: Move Your Clients to the VPC Addresses

Switch your clients from the Private Network addresses to the VPC addresses, one service at a time, and check that each service works before moving on. Depending on your setup, this can mean updating:

• DNS records
• Configuration files, connection strings and /etc/hosts entries.
• Service discovery registrations.

To roll back a service, point its clients back to the Private Network address.

Step 5: Remove the Private Network

Once every client uses the VPC addresses, check that no traffic is left on the Private Network. On each instance, find the Private Network interface with ip address, then watch its counters for a while. Counters that no longer move mean the interface isn’t used anymore.

Detach every instance from the Private Network, then delete it.

Finally, clean up the configuration that referenced the Private Network in your instances: static interface configuration (netplan, cloud-init) for manual Private Networks, and host firewall rules for the old range.