4.4 Connecting to the outside world and to yourself
Describes cloud networking as of August 2026
What this is and why it exists
Very few clouds are islands. Sooner or later your network has to reach an office, another account, a partner, or a second provider — and the way you join them decides how fast it is, how much it costs, and how much of your traffic crosses the public internet. This topic gives you the four mechanisms and, more usefully, the question that picks between them.
The vocabulary
- Site-to-site VPN — an encrypted tunnel across the public internet joining two networks. Amazon calls it Site-to-Site VPN, Azure calls it VPN Gateway, Google calls it Cloud VPN.
- Dedicated interconnect — a private physical circuit between your premises and the provider: Amazon's Direct Connect, Azure's ExpressRoute, Google's Cloud Interconnect.
- Peering — joining two virtual networks so they route to each other directly, without going out to the internet.
- Transit hub — a central network that many others attach to, so each has one connection instead of many: Amazon's Transit Gateway, Azure's Virtual WAN, Google's Network Connectivity Center.
- Private endpoint — an address inside your own network that reaches a managed service without traversing the internet: Amazon's PrivateLink, Azure's Private Link, Google's Private Service Connect.
- Transitive routing — whether A reaching B and B reaching C means A can reach C; usually it does not.
The mental model
Four mechanisms, and each answers a different question.
A VPN answers "how do I join two networks today, cheaply". It is an encrypted tunnel over the ordinary internet: quick to set up, inexpensive, and it inherits every property of the internet path underneath — variable latency, occasional loss, bandwidth you do not control. That is entirely fine for administrative access, for a second office, for a backup path, and for most first connections.
A dedicated interconnect answers "how do I stop depending on the internet". It is a private circuit with predictable latency and committed bandwidth, and it costs a monthly fee plus the work of ordering it through a carrier, with lead times measured in weeks. It earns that when you move large volumes continuously, when latency must be consistent rather than merely good, or when a regulator or a contract requires that traffic not cross the public internet. It is not a performance upgrade for a small workload, and the honest advice is to start with a VPN and let a measured problem justify the circuit.
Peering answers "how do I join two of my own networks". It is direct routing between two virtual networks, usually cheap and fast, and it comes with one property that surprises everyone exactly once: peering is not transitive. If A peers with B and B peers with C, A still cannot reach C. Which is why the count matters — joining n networks pairwise takes n times n minus one, over two, connections, and that becomes unmanageable at about five. A transit hub replaces the mesh: everybody attaches once to the centre, routing is configured in one place, and adding the tenth network is one connection rather than nine.
Private endpoints answer a different question again, and it is the one most relevant to a small team. Managed services — a database, object storage, a secrets store — normally present a public address, and even with correct access rules the traffic leaves your network to reach them. A private endpoint puts an address for that service inside your own subnet, so the traffic never goes out, and the service can be configured to refuse everything else. It is often the cheapest large improvement to a security posture available: no tunnel, no circuit, no architectural change, and the managed service stops being reachable from anywhere but your network.
The one habit that keeps all of this workable is the address planning from the virtual-networks topic. Every mechanism here fails immediately if two sides use overlapping ranges — a tunnel cannot route between two networks that both believe they own 10.0.0.0/16. Write the plan down, keep a register of which range belongs to which environment and office, and check it before you agree to connect to anyone.
What you should now be able to explain or do
Choose between a VPN and a dedicated interconnect for a described requirement, and name what would change your answer. Explain why peering is not transitive and what that costs as the number of networks grows. Say what a transit hub replaces. Describe what a private endpoint changes about traffic to a managed service and why it is often the best value. State the one planning failure that breaks every mechanism in this topic.
Check yourself
An office needs to reach a private subnet, starting next week. What do you build?
A site-to-site VPN. It is an encrypted tunnel over the internet, quick to set up and inexpensive, and it is the right first answer until a measured problem justifies a private circuit.
When does a dedicated interconnect actually earn its cost?
When you move large volumes continuously, when latency must be consistent rather than merely acceptable, or when a contract or regulator requires that the traffic not cross the public internet. Not as a general speed upgrade.
A peers with B, and B peers with C. Can A reach C?
No. Peering is not transitive. You either add a direct connection between A and C, or attach everything to a transit hub and configure the routing centrally.
What does a private endpoint change about traffic to a managed database?
It gives the service an address inside your own network, so traffic never leaves it — and the service can then refuse everything that does not arrive that way.
What single planning mistake breaks a VPN, a peering and an interconnect alike?
Overlapping address ranges. Two networks that both believe they own the same block cannot be routed between, and the fix is renumbering something that is already running.
Go deeper
We haven't checked most of these for screen reader use yet.
Back to Connecting to the outside world and to yourself: work through the checklist