Connecting servers over a private VLAN

What a private VLAN is

A VLAN (Virtual Local Area Network) is a way of segmenting network traffic so that a defined group of devices can communicate as if they were on their own isolated switch, even when they physically share network infrastructure with other traffic. A private VLAN, in the context of server networking, refers to using that segmentation to give a set of servers a network path to each other that has no route to or from the public internet. Traffic on it stays internal, between the servers you've put on that segment, and isn't reachable from outside.

That matters for anything you'd rather not expose publicly even behind a firewall: database replication traffic between a primary and replica, an internal API that only your own services should ever call, or backup traffic moving from one server to another. Keeping that traffic off the public network removes an entire category of exposure, there's no public IP or port for it to be found on in the first place, and it often reduces latency and avoids consuming public bandwidth allowances too.

Why this matters differently for dedicated servers

On a virtualised platform, where multiple customer instances run as guests on shared physical hosts, private networking between your own instances is often built into the platform: the hypervisor or orchestration layer already has a mechanism for connecting virtual machines that belong to the same tenant on an internal, software-defined segment, without touching a physical switch port.

Dedicated servers are a different situation. Each one is a physically separate machine with its own network interface, there's no shared hypervisor layer quietly offering to connect them. For two or more dedicated servers to talk over a private VLAN, that connectivity needs to be explicitly wired at the network layer, whether that means a VLAN configured on the switch ports each server connects to, a separate physical or logical interface dedicated to internal traffic, or some other provider-specific mechanism. It isn't something that exists automatically just because the servers happen to be in the same account or the same data centre.

What this typically looks like in practice

Regardless of provider, setting up private server-to-server networking generally involves a few consistent pieces:

• A defined private network segment, isolated from the public internet and, ideally, from other customers' traffic on shared infrastructure.
• Each server attached to it, usually via a second network interface or a tagged VLAN interface, separate from the interface carrying public traffic.
• Private IP addressing on that segment, distinct from each server's public IP, used only for traffic between servers on the same private network.
• Routing and firewall rules scoped to that segment, since a private network doesn't automatically mean unrestricted access between every server on it, you still generally want to control what each server can reach.

On Flexible VPS the equivalent already exists as a product feature: Portal's Networks page lets you create a Local Network, a private overlay that connects your VPS instances across hosts. There is no equivalent self-service page for dedicated servers, so if you want a private VLAN between dedicated servers, open a support ticket and ask what is possible on your setup before you design around it.

One detail worth checking on any private network before relying on it for large transfers: the MTU (maximum transmission unit) on a private, overlay-based network segment is sometimes smaller than on a standard public interface, which can silently affect throughput if it's not accounted for. See Why your private network has a different MTU than your public one for why that happens and how to check for it.

Colocated hardware needs the same thing considered separately

If your dedicated servers sit alongside colocated hardware you own, the private-networking question extends to that equipment too, and the setup involved can differ again, since colocated hardware is entirely your own gear connecting into the data centre's network. See Connecting your colocated hardware to AWS, Azure or GCP for a related discussion of direct, non-public connectivity from colocated equipment, in that case out to public cloud rather than between servers.