Daniel sent us a question this week that starts with a very specific moment — you're provisioning a VM on Hetzner, you click "add to private network," and suddenly a machine in Helsinki and one in Frankfurt act like they're plugged into the same switch. His assumption, and I think most people's assumption, was that there's a physical cable making that happen. Within one data center, sure, that makes sense. But between cities? For a mid-tier provider? He's asking what's actually in the cables, how the networking plumbing works, what kind of security "private" really means, and whether these cross-data-center private networks are just VPNs in disguise.
The honest answer is it depends on the provider, which is the kind of answer that makes people want to throw things at us.
The correct answer is always unsatisfying.
The actual engineering behind it is fascinating. And the specific question — "is this thing literally a VPN tunnel between data centers" — that is a much sharper question than most people ask when they're clicking buttons in a cloud console. Most people don't even pause at that button. They click it, it works, and the mental model stays at "magic cable." Daniel's already past that, and he's asking the right follow-up.
Let's unpack what's actually happening when you click that button. And I want to start by acknowledging that the magic-cable mental model is incredibly useful for getting work done. You don't need to understand VLAN tagging to deploy a web app. But when something breaks, or when you're trying to reason about security, that mental model becomes actively harmful.
The first thing to understand — and this is genuinely important — is that even within a single data center, your "private network" is almost never a physical cable running directly between your two machines. It's a virtual overlay. What you're actually getting is a piece of software that encapsulates your Ethernet frames and sends them across the physical network infrastructure in a way that makes them invisible to everyone else's traffic. The physical network doesn't know or care about your private network. It's just forwarding packets.
The metaphorical cable is a lie even before you leave the building. And I think that's worth sitting with for a second, because it reframes the entire question. If the local private network is already software, then the cross-data-center version isn't a different kind of thing — it's the same kind of thing, just with a longer wire in the middle. The interesting part is what that longer wire is made of.
And that's not a bad thing. It's how multi-tenant cloud works. You can't run a dedicated Ethernet cable between every possible pair of VMs — the combinatorics alone would be absurd. If you have a thousand VMs in a rack and you want any-to-any private connectivity, you'd need half a million cables. That's physically impossible. So we virtualize. But once you understand that the local private network is already software-defined, the cross-data-center version becomes less mysterious. It's the exact same idea, stretched over a longer distance.
The real question isn't "is this a real cable" — nobody's doing that even locally — it's "what's the actual network carrying the encapsulated traffic between the data centers, and who can see it?" And that second half — "who can see it" — is where the security story either holds together or completely falls apart.
And there are broadly three approaches that providers use. Let me frame them before we dig in, because the differences matter enormously for both performance and security. Approach one: you own the physical fiber end-to-end. Approach two: you lease dedicated capacity from a carrier, but it's still logically isolated from the public internet. Approach three: you encrypt everything and send it over the public internet like everyone else. Same product from the customer's perspective — "private network between data centers" — but radically different underneath.
To understand what's really going on, we need to look at these three main technical approaches — and they're very different beasts. Let's start at the top.
The top tier. We're talking AWS, Google Cloud, Microsoft Azure. These companies have built their own global backbone networks. AWS has over a hundred thousand kilometers of dedicated fiber. That includes transatlantic cables — MAREA, a cable co-owned by Microsoft and Facebook, runs from Virginia to Spain. Havfrue, which Google partly owns, connects the US to Denmark and Ireland. When AWS sets up VPC peering between two regions, your traffic travels over fiber pairs that Amazon controls end-to-end. It never touches the public internet. This is true Layer 1 and Layer 2 connectivity. The latency is purely the speed of light in fiber, which is roughly two hundred kilometers per millisecond — about two-thirds the speed of light in a vacuum, limited by the refractive index of the glass.
Two hundred kilometers per millisecond is a number I want to pin to the wall, because we're going to come back to it repeatedly. That's the speed of light in fiber, and it's non-negotiable. You can't optimize your way past physics. If Frankfurt to Helsinki is roughly fifteen hundred kilometers as the fiber runs — and it's never a straight line, there are always detours around geographic obstacles and through exchange points — you're looking at a hard floor of about seven and a half milliseconds of latency just from the glass. Nothing you do above Layer 1 can reduce that.
It's a hard physical limit. Nothing in networking will ever beat it without violating physics. And that number — seven and a half milliseconds for fifteen hundred kilometers — is the theoretical minimum. Real-world routing always adds some overhead. Now, that's the top tier. The hyperscalers with their own submarine cables. They can get very close to that physical minimum because they control the entire path. But the second tier is where things get interesting, because this is where providers like Hetzner, DigitalOcean, Linode live. They do not own transatlantic fiber. But they don't need to — because carriers will sell you wholesale transport.
"Wholesale transport" sounds like I'm buying grain by the ton. What does that actually mean in networking terms?
It's similar conceptually. You're buying a circuit between two locations, and that circuit is abstracted away from the underlying physical hardware. The most common form is MPLS — Multi Protocol Label Switching — and specifically a flavor called VPLS, Virtual Private LAN Service. These are carrier-grade virtual circuits. The key distinction is that unlike internet routing, which relies on BGP and hop-by-hop decisions that can change at any moment, an MPLS circuit gives you a predictable path with guaranteed bandwidth and a service level agreement. Think of it like leasing a dedicated lane on a highway rather than merging into general traffic. You're still on the same physical road, but your lane is reserved and nobody else can use it.
The carrier — say Telia or NTT or whoever built the fiber — is carving off a slice of their capacity and saying "this is yours, it behaves like a point-to-point link between Helsinki and Frankfurt.
And here's the crucial point: this is not a VPN. When people say VPN, they typically mean an encrypted tunnel running over the public internet. MPLS circuits are provisioned within the carrier's private infrastructure. The traffic is separated from other customers' traffic via labels, not IP addresses, and those labels are only meaningful within the carrier's network. The public internet never sees your packets. From the perspective of the cloud provider — Hetzner, in this case — they have purchased what amounts to a long-distance private Ethernet cable, just one that's implemented through carrier switching rather than a single unbroken strand of glass.
Who's running the fiber underneath all of that? Because Hetzner isn't out there with a trenching machine burying cable between Helsinki and Frankfurt.
This is where the "who owns the cloud" question gets deep. The answer is typically a consortium or a specialized fiber operator. There are companies like Zayo, Lumen, Colt, and EuNetworks whose entire business is running long-haul fiber between data centers and selling capacity. When Hetzner lights up a connection between their Helsinki facility and their Frankfurt facility, they are almost certainly leasing the actual glass from someone like that, and then potentially adding their own transport layer on top. MPLS from a carrier like Telia, or potentially setting up their own optical equipment on a dark fiber pair they've leased. Dark fiber is literally just the glass — no equipment on either end, no signal, nothing. You light it yourself with your own optics and your own transport protocol.
That's an important distinction, right? Leasing dark fiber versus buying a managed MPLS circuit — those are very different levels of control.
With dark fiber, you're responsible for everything above the glass. You choose the optical transceivers, you choose the modulation scheme, you handle the amplification and dispersion compensation. It's more work, but you get full control and potentially higher capacity. With an MPLS circuit, the carrier handles all of that — you just get an Ethernet handoff at each end. Most mid-tier cloud providers are probably doing the latter, because operating a long-haul optical network is a specialized skill that isn't their core business.
Then there's the third tier — providers who skip the dedicated circuit entirely and just say "we're going to encrypt this and shove it over the public internet.
Right, the software-defined overlay approach. WireGuard or IPsec tunnel between data centers, often running VXLAN inside it for multi-tenancy. This is the cheapest option by orders of magnitude and it's surprisingly effective for many workloads. But it's running over the same public internet that your home connection uses, subject to the same congestion, the same BGP route flapping, the same unpredictability. Whether a provider discloses that they're doing this is another question entirely, and the honest answer is: usually not explicitly. You have to read between the lines of their documentation.
This gets at one of the core tensions in Daniel's prompt. Would a provider like Hetzner tell you, the customer, "we're using VPN tunnels between our data centers"? Or would they find a way to describe it that avoids the word "VPN" entirely?
They don't phrase it that way, because "VPN" carries specific connotations — some positive, some negative — and it's also a product in its own right. If you're selling a VPN product to end users, you don't want your internal infrastructure described with the same word, because then a customer might reasonably ask "so my private network is just a VPN? Why am I paying extra for that?" Instead you'll see language like "VXLAN-based private network" or "Layer 2 overlay spanning multiple locations." That's what Hetzner's documentation says, by the way — their Network product is explicitly described as VXLAN-based, and they note it can span multiple locations. But they don't detail the transport between those locations.
Because from their perspective, that's an implementation detail that might change next year, and the abstraction is the product. They could swap out the underlying transport from MPLS to dark fiber to something else entirely, and as long as the VXLAN overlay behaves the same way, the customer never needs to know.
What they're selling is not the physical medium — it's the network abstraction and the operational simplicity of clicking a button rather than configuring GRE tunnels and BGP sessions yourself. And that's valuable. The time savings of not having to configure and maintain your own site-to-site tunnels is real, and for many teams, that operational simplicity is worth the premium even if the underlying transport isn't fundamentally different from what they could build themselves.
Let's get into VXLAN specifically, because that's the magic word behind basically all of these abstractions. What are we actually doing at the packet level when we say "VXLAN overlay"?
VXLAN — Virtual Extensible LAN — is elegant. What it does is take an entire Ethernet frame, the Layer 2 frame, and wraps it inside a UDP packet. You're putting the frame inside the payload of a UDP datagram. "MAC-in-UDP" is the encapsulation model. The VXLAN header adds a twenty-four-bit field called the VNI — the VXLAN Network Identifier — which can support up to sixteen million isolated networks on the same physical infrastructure. To put that in perspective, traditional VLAN tagging uses a twelve-bit field, so you only get about four thousand networks. VXLAN blew that wide open.
That is not a scaling problem they'll hit soon. You could give every customer a thousand private networks and still have room to spare.
No, sixteen million separate virtual Ethernet segments, each completely isolated from the others, is more than enough for any cloud provider operating today. And because the encapsulation uses UDP, it can be routed across any IP network. The underlying network doesn't need to understand VXLAN at all. It just sees UDP packets and forwards them normally. This is what makes VXLAN so powerful for multi-data-center operations. You encapsulate the customer's Ethernet frame in Helsinki, send the UDP packet across whatever transport you have — MPLS circuit, dark fiber, or public internet — de-encapsulate in Frankfurt, and deliver the original frame to the destination VM. The transport layer is completely decoupled from the overlay.
From the VM's perspective, a broadcast ARP request just worked, across a thousand-plus kilometers and however many physical hops. The VM has no idea it's not on the same physical switch as the other VM. It sends an ARP request saying "who has this IP address?" and it gets a response, and the round trip might be eight milliseconds instead of half a millisecond, but at the Ethernet frame level, everything looks normal.
And this also illuminates the security question. VXLAN itself does not include encryption. It's not designed to be a security protocol. It's designed to be a network virtualization protocol. In its most common deployment within a provider's own network backbone, the VXLAN traffic is unencrypted. The isolation between tenants is provided by the VNI — packets with the wrong VNI are dropped — but anybody with access to the physical transport can read the encapsulated frames. If you can tap the fiber or mirror a port on a switch that's carrying VXLAN traffic, you can see the inner Ethernet frames in plaintext.
"VXLAN-based private network" is private like your apartment is private — the walls are there, everybody else has their own apartment, but the landlord can walk in and look at your stuff. And if the landlord accidentally gives someone else a key that fits your door, they can look at your stuff too.
That's an uncomfortably perfect analogy. The VNI is like your apartment number. As long as the provider's switching infrastructure correctly handles those numbers, other tenants can't see your frames. But the provider can. And if there's a misconfiguration — someone fat-fingers a VNI mapping, or a hypervisor bridge leaks traffic, or a switch VLAN is accidentally trunked to the wrong port — then isolation breaks. These misconfigurations happen. They're rare, but they're not hypothetical. Every major cloud provider has had at least one incident where network isolation failed due to a configuration error.
Now, AWS has the benefit that they physically own the transatlantic fiber. So when they shove VXLAN onto their global backbone, "the provider can see your packets" means Amazon can, but presumably nobody else is tapping the undersea cable? If we set aside nation-state adversaries with submarines.
This is one of several areas where scale changes security properties. When AWS runs your inter-region VPC peering over MAREA, nobody else's traffic is on that fiber. For a terrestrial backbone, there's a physical plant — repeaters, switching stations, manholes — and AWS controls access to them. But even that doesn't eliminate insider threat or the possibility of optical taps. For a smaller provider leasing MPLS circuits from a carrier, you're adding at least one more party into the trust picture. The carrier could theoretically inspect the traffic. Practically, that's very unlikely for a wholesale transit provider dealing in bulk MPLS — they're moving terabits per second, they're not inspecting individual customer VXLAN flows — but it's in the threat model. And compliance regimes like PCI-DSS, HIPAA, things that have explicit requirements around data-in-transit encryption, they often want to see encryption regardless of whether the underlying transport is supposed to be private.
Which means "private network" is not equivalent to "secure network" in the compliance sense. And I think that's the single most important takeaway for anyone who's been clicking that "add to private network" button and assuming it's handling their security requirements.
It is not even close in many cases, which is one of the most common misconceptions I see. People think "private network" means "encrypted." It doesn't. It means "addressed such that it's not on the public internet." Sometimes that's coupled with encryption. Often it's not. And the provider's documentation won't necessarily make this clear, because from their perspective, they're selling network isolation, not encryption. Those are different products.
Okay but let's get concrete. Let's say someone at Hetzner sat down and provisioned a cross-data-center private network between their Helsinki and Frankfurt facilities. What does that actually look like on the ground? I personally imagine they made a labeled cardboard box and put an anteroom sign on it, but stepping outside myself and my lifelong contempt for red tape — what's the actual physical and logical path?
The most likely scenario, based on what we can piece together from public information, is that Hetzner is leasing capacity from a carrier that operates fiber between those two cities. The handoff happens at a meet-me room or an exchange point in each data center. On Hetzner's side, they have a switch or router that takes the VXLAN traffic from their internal network and hands it to the carrier's equipment. The carrier then transports it across their MPLS backbone — or potentially across a dedicated wavelength on their optical network — and delivers it to the other data center. From Hetzner's perspective, it's an Ethernet handoff on both ends. They plug in, configure their VXLAN tunnel endpoints, and it works.
If that carrier circuit goes down? What's the failure mode look like?
That depends on how Hetzner has configured their redundancy. If they've purchased a single circuit with no backup, then the private network between those two data centers simply goes dark. VMs on both sides lose connectivity to each other. If they've purchased diverse paths — say, one circuit from Telia and another from NTT, taking physically different routes — then a single fiber cut might cause a brief interruption while traffic fails over to the backup path, but the network stays up. The specifics of that failover depend on the routing protocol they're using internally. Could be sub-second if they're running something like BFD with fast timers. Could be several seconds if they're relying on standard BGP convergence.
Now that we know how these networks are built, the obvious question is: what does this mean for you in practice? If you're deploying an application that spans Helsinki and Frankfurt, what should you actually expect?
For most workloads, the cross-DC private network is a convenience product. Not a security product. Not a latency product in the magical sense — at least not beyond what physics allows. People assume that moving your traffic off the public internet onto a private backbone automatically makes it faster, but the actual data is more nuanced than that. The speed of light doesn't care whether AT&T owns the fiber or Cogent has cheap cross-connect availability. The photons travel at the same speed regardless of who holds the title to the glass. What you're actually improving is routing determinism. On the public internet, your packets might take a wildly suboptimal path — Frankfurt to Helsinki via Amsterdam and Stockholm because of a BGP peering arrangement, adding hundreds of kilometers and multiple queues of unpredictable depth. On a private circuit, the path is fixed and engineered. You know exactly what you're getting.
The win isn't lower minimum latency — it's less variance. The median might be similar, but the tail latency is dramatically better.
And for certain workloads, tail latency is everything. If you're doing synchronous database replication, you care about the ninety-ninth percentile, not the median. A private circuit gives you consistent performance with very tight jitter. The public internet gives you good median performance but occasionally terrible tail latency when a link saturates or a route flaps. That consistency is what you're paying for.
Let's put some numbers on this. What's the actual latency between Helsinki and Frankfurt on a private circuit versus the public internet?
On a well-engineered carrier circuit, you're probably looking at something in the low twenties of milliseconds round-trip. The great-circle distance between Helsinki and Frankfurt is about fifteen hundred kilometers, but fiber routes are never straight — they follow roads, railways, and existing utility corridors. A realistic fiber path might be eighteen hundred to two thousand kilometers. At two hundred kilometers per millisecond, that's nine to ten milliseconds one-way, so eighteen to twenty milliseconds round-trip, plus a small amount of processing overhead at each end. On the public internet, you might see twenty-five to thirty-five milliseconds typically, but with spikes to fifty or sixty when congestion hits or a route changes. So the private circuit might save you five to fifteen milliseconds of median latency, but it saves you thirty to forty milliseconds of tail latency. That's the real value proposition.
For database replication, that tail latency difference can be the difference between a replication lag of a few milliseconds and a lag of several seconds under load.
Database replication is almost the canonical use case for cross-DC private networking. If you're running PostgreSQL with streaming replication from a primary in Frankfurt to a standby in Helsinki, you want that replication stream to be as consistent as possible. A private circuit gives you predictable throughput and predictable latency, which means your standby stays consistently close to the primary. On the public internet, a burst of congestion could cause the standby to fall seconds behind, which is exactly when you don't want it to be behind — because that's often correlated with the kind of event that might cause you to need to fail over.
If you're running something like etcd across data centers, the latency requirements get even stricter.
etcd uses the Raft consensus protocol, which requires a majority of nodes to acknowledge every write. If you're spanning three data centers with etcd, the write latency is determined by the slowest link in the majority. A private circuit with consistent latency makes that predictable. The public internet makes it a gamble. Most Kubernetes distributions strongly recommend against spanning a single etcd cluster across geographic regions for exactly this reason — the latency variance can cause leader elections to fail, which can cascade into much larger problems.
What about the security side in practice? If you're handling sensitive data — health records, financial transactions, personal information — and you're using a cross-DC private network, should you be adding your own encryption on top?
The short answer is yes, and I don't think this is even controversial among security engineers. If the data is sensitive enough that you'd encrypt it on the public internet, you should encrypt it on a private circuit too. The private circuit reduces your attack surface — you're no longer exposed to every router on the internet — but it doesn't eliminate it. The provider can still see your traffic. The carrier can still see your traffic. Any misconfiguration can still expose your traffic. Adding a layer of encryption — WireGuard between your VMs, or IPsec, or even just ensuring all your application traffic uses TLS — is cheap. The computational overhead is negligible on modern hardware. A WireGuard tunnel adds maybe a few microseconds of latency and consumes a tiny fraction of a CPU core. There's almost no reason not to do it.
From a compliance perspective, it's often not optional anyway.
If you're subject to PCI-DSS, HIPAA, GDPR, or any of the other alphabet soup of regulations, you'll almost certainly need to demonstrate that data in transit is encrypted. A private network alone doesn't satisfy that requirement, because the regulation typically doesn't care about the network topology — it cares about whether an unauthorized party could read the data. And as we've established, the provider and the carrier are both in a position to read unencrypted traffic on a private network. So you encrypt. And once you've encrypted, the distinction between a private circuit and the public internet becomes much less important from a security standpoint.
Which brings us to an interesting conclusion: the optimal approach for most teams is probably to use the provider's private network for its convenience and consistency, but to layer their own encryption on top for security. You get the best of both worlds — predictable performance from the private circuit, and actual confidentiality from the encryption.
That's exactly where I land. Use the private network as a transport convenience, not as a security boundary. Treat it like you would treat the public internet from a threat-modeling perspective, and encrypt accordingly. That way, if the provider changes their underlying transport next year — swaps an MPLS circuit for a different carrier, or moves from dark fiber to a managed wavelength — your security posture doesn't change. You're not dependent on their implementation details.
This is where Daniel's original question circles back around. "Is this just a VPN in disguise?" In some cases, literally yes — the provider is running an encrypted tunnel over the public internet and calling it a private network. In other cases, it's a dedicated circuit that's isolated from the public internet but still not encrypted at the VXLAN layer. In all cases, you should probably be running your own VPN on top anyway. So the distinction ends up mattering less than you might think.
The distinction matters for performance and reliability — a dedicated circuit is going to give you better consistency than a tunnel over the public internet — but for security, the answer converges to the same place: encrypt your traffic. Don't trust the abstraction.
One more practical consideration before we move toward wrapping up. If you're evaluating a provider and you want to know what's actually under the hood of their "private network" product, what questions should you ask?
First: what's the SLA for latency and packet loss between the data centers I care about? If they can give you a specific number with a financial penalty for violating it, that's a strong signal they're using a dedicated circuit with guaranteed capacity. If the answer is vague or nonexistent, they're probably using the public internet. Second: do you support customer-managed encryption on top of the private network? If they say no or seem confused by the question, that's a red flag. Third: can you provide documentation about the physical path between data centers for compliance purposes? If they can tell you which carriers they use and what the redundancy model is, they're operating at a level of sophistication that suggests dedicated infrastructure. If they can't, they're probably winging it.
Those are excellent, concrete questions. And Daniel, if you're listening — those are the questions to send to your provider's support team. The answers will tell you a lot about what you're actually getting.
Daniel's question was fantastic because it gets at something that almost everyone in cloud computing encounters but few people think about critically. We click buttons and things work, and the abstractions are so good that we forget there's physical infrastructure underneath. But that physical infrastructure has real properties — real latency limits, real security boundaries, real failure pattern — and understanding them makes you better at designing systems that actually work in production.
Now, before we wrap up properly: Hilbert's daily fun fact.
Hilbert: In the early eighteen hundreds, around eighteen oh eight, mathematicians in the southern Caspian basin briefly experimented with a zero glyph shaped as a small half-inch triangle of optical pigment whose fractional gradient tint produced infinitesimal results just fractionally different from the hollow-circle-based precision, and no lens could verify any functional drop in practice, leading them to abandon the approach entirely.
...okay then.
Long contour — but I suppose a transparent internal non-space content essentially never appeared again beyond a footnote of dead optical measurement, careful, certain, square, kind of single light spread minimal bound specific minute.
This has been My Weird Prompts. Big thanks to our producer Hilbert Flumingtop, and even bigger thanks to Daniel for sending in a question that took us from Helsinki to Frankfurt and back again through the entire stack of modern networking. If you enjoyed untangling what "private" means inside a data pipe, leave us a review somewhere that reviews exist, and tell a friend you've been thinking about fiber lines and threat models. We are back whenever the next weird prompt arrives. Find all episodes wherever you get your podcasts — search "My Weird Prompts." We'll see you next cycle.
Bye for now, everybody. Go build something, and maybe encrypt it while you're at it.
