Private Networking Between Cloud Servers
Keeping internal traffic on private addresses is faster, cheaper and safer than routing it over the public internet. It is also easy to get subtly wrong.
As soon as an environment has more than one server, those servers need to talk to each other. How that traffic is routed affects latency, cost and exposure, and the default is often not the best option.
Why private addresses are the right answer
- Latency. Traffic stays inside the provider’s network rather than leaving and returning.
- Cost. Internal transfer is usually free or cheap; public egress usually is not.
- Exposure. A database bound only to a private address cannot be reached from the internet at all, regardless of firewall mistakes.
That last point is the strongest. Configuration errors happen; a service that has no public route is protected by topology rather than by a rule someone might edit.
What private networking looks like
Providers implement this differently but the shape is consistent. Servers in the same region receive an address on a private range, reachable only by other resources in your account. Larger providers add virtual networks with subnets you define; simpler providers offer a flat private network you enable per server.
Two details are worth checking. Private networking is often regional, so servers in different regions cannot use it. And on some providers it must be enabled at creation time rather than added later.
Binding services correctly
Having a private address is not enough if the service is still listening on all interfaces. A database bound to every interface is reachable on the public address too, and only the firewall is stopping it.
Bind internal services explicitly to the private address. Then even an open firewall port does not expose them.
Do not treat private as trusted
A common mistake is assuming the private network is safe and therefore skipping authentication or encryption between services. On many providers the private range is shared infrastructure, and in any case a single compromised server should not grant free access to everything else.
Keep authentication between services, and use TLS for anything sensitive, even internally.
Practical layout for a small estate
- Application server: public address for inbound traffic, private address for talking to the database.
- Database server: private address only, no public address at all.
- Firewall: allow database traffic only from the application server’s private address.
That arrangement is simple, cheap and removes an entire class of exposure. The firewall layers involved are described in cloud networking basics.
Cloud accounts on OldCloudShop
Ten providers, every configuration and the starting price for each.
Continue in the library
Other entries covering account structure, billing, security and provider infrastructure.