How do you connect on-prem to cloud networks?
Four options exist, and most organisations need the cheapest one. A site-to-site VPN over the ordinary internet is enough for most hybrid estates, production included, and is provisioned in an afternoon. The reason projects run long is almost never the link: it is that two networks built independently have chosen the same private IP ranges, and nobody discovers this until the tunnel comes up and half the routes are ambiguous.
What are the actual options?
A site-to-site IPsec VPN, a dedicated private circuit, an SD-WAN overlay, or no network integration at all with services exposed over public endpoints and locked down by TLS and allowlists. Everything else is a variation on one of those four.
The VPN runs encrypted traffic over your existing internet connection and terminates on a cloud gateway. It costs very little, deploys quickly, and inherits whatever the public internet is doing that day. A dedicated circuit, sold as Direct Connect, ExpressRoute or Cloud Interconnect depending on the provider, is a physical or partner-delivered link into the provider's network that bypasses the internet entirely, and it takes weeks to provision because someone has to cross-connect it in a facility.
The fourth option deserves more respect than it gets. If the only thing the cloud needs from your data centre is one API, publishing that API on a hardened public endpoint with mutual TLS is simpler, cheaper and easier to reason about than joining two networks together, and it does not give a compromised cloud instance a route to your file servers.
| Option | Time to provision | Costs | Good when | Weakness |
|---|---|---|---|---|
| Site-to-site IPsec VPN | Hours to days | Gateway hours, little else | Most hybrid estates, including production | Latency and throughput follow the public internet |
| Dedicated private circuit | Weeks, sometimes months | Port fee plus transfer, often a colocation cross-connect | Sustained high volume, predictable latency, no-internet policies | Long lead time, and a single circuit is a single point of failure |
| SD-WAN overlay | Days to weeks | Appliance or virtual appliance licences | Many branch sites already on SD-WAN | Another vendor plane to run and patch |
| Public endpoint, no network join | Hours | None beyond the endpoint | One or two APIs are the whole requirement | Does not help workloads needing broad internal access |
Do you need a dedicated circuit?
Only for one of three reasons, and general nervousness about the internet is not among them. The reasons that hold up are sustained bandwidth that a VPN gateway cannot carry, a latency requirement tight and consistent enough that internet variance breaks it, and a policy or regulatory position that traffic must not traverse the public internet at all.
A fourth reason is financial rather than technical: data leaving a provider over a private circuit is billed at a lower rate per gigabyte than data leaving over the internet. At low volumes that discount does not come close to the port fee. At high sustained volumes it can pay for the circuit by itself, which makes this a question you answer with a month of traffic measurement rather than an opinion.
If you do order one, order the failover at the same time. A single circuit has worse availability than a VPN, because a VPN can re-route across any path the internet offers and a circuit cannot. The common pattern is a private circuit as the primary path with a VPN configured as standby, which costs almost nothing extra and removes the worst failure mode.
Why does IP addressing decide the timeline?
Because two networks cannot exchange routes for the same address range, and private ranges are chosen by convention rather than allocation. A great many corporate networks grew into large parts of 10.0.0.0/8, and a great many cloud accounts were created by a developer who accepted the default 10.0.0.0/16. When the tunnel comes up, the routers have two claims on the same space and one of them loses.
The workarounds are all unpleasant. Network address translation on one side hides the real addresses, which breaks anything that embeds an IP in a payload or a certificate, complicates logging and makes incidents much harder to trace. Renumbering the cloud side is cleaner but means rebuilding the subnets and everything pinned to them. Renumbering the data centre is rarely on the table.
So the first hour of any hybrid networking project is spent on a spreadsheet, not a console. Write down every CIDR block in use on-premise, including the ones in branch offices and the VPN pool your remote workers get, then allocate the cloud a range from outside all of it, with room for the environments you have not built yet. This is the cheapest work in the project and it is the work most often skipped.
How does DNS work across the boundary?
Each side needs to resolve the other's private names, and by default neither can. Cloud resolvers do not know your internal zones and your internal resolvers do not know the provider's private zones, so a workload that connects perfectly by IP will fail by hostname, which is how most of these problems present.
The standard arrangement is conditional forwarding in both directions. Your on-premise resolvers forward queries for the cloud's private zones to a resolver endpoint inside the cloud network, and the cloud resolver forwards queries for your internal zones back to your domain controllers or resolvers. Both directions have to be configured, both have to be reachable over the link, and both are worth putting in a monitor.
The failure mode to watch for is a cloud workload resolving an internal hostname to its public address, then routing over the internet to your firewall instead of through the private link you paid for. It works, so nobody notices, and it quietly defeats the point of the circuit. Checking the resolved address from inside the cloud subnet, rather than assuming it, is the test that catches this.
What breaks in routing and firewalls?
Asymmetry, mostly. Traffic that leaves through one path and returns through another will be dropped by any stateful firewall in the middle, because the return packet belongs to a session that device never saw. Hybrid estates create asymmetry easily: two tunnels with different route preferences, or a route added on one side and not the other.
Route propagation limits are the other recurring surprise. Cloud route tables and gateways accept a bounded number of prefixes, and a corporate network advertising every internal subnet individually can exceed that limit and silently stop propagating the rest. Summarising your advertisements before they reach the cloud gateway avoids an outage that looks random and is not.
Design the topology as a hub rather than a mesh. One cloud network carrying the connectivity, with other cloud networks attached to it, keeps the routing comprehensible and gives you one place to inspect traffic. A mesh of individual tunnels from each project to the data centre works until the day someone needs to trace a packet.
What can you test this afternoon?
Stand up a temporary VPN to a throwaway cloud network and measure three things from a small instance inside it: round trip latency to the service you care about, sustained throughput over a few minutes rather than a burst, and whether the internal hostname resolves to a private address. That is an afternoon of work and it answers most of the architecture questions people spend weeks debating.
Then count round trips. Take one real user action and count how many separate calls it makes to the on-premise system, because that number multiplied by the latency you just measured is what the user will feel. An action making two hundred small database calls was free inside one building and is not free across a link, and no amount of bandwidth fixes it.
If the latency and the round trip count are both acceptable, a VPN is very likely all you need, and you can defer the circuit conversation until you have real traffic figures to justify it.
Common questions
- What is the best way to connect on-premise to the cloud?
- For most organisations, a site-to-site IPsec VPN over the existing internet connection. It provisions in hours, costs little beyond gateway hours and carries production traffic perfectly well. A dedicated private circuit such as Direct Connect, ExpressRoute or Cloud Interconnect is justified by sustained high volume, a strict latency requirement or a policy against using the public internet, and takes weeks to deliver.
- Do I need Direct Connect or ExpressRoute for hybrid cloud?
- Usually not at first. A private circuit is worth its port fee when traffic volume is high and sustained, when latency variance on the internet breaks something, or when a policy forbids public internet transit. The per-gigabyte transfer discount on a private circuit can also justify it, but only at volumes worth measuring first. Order failover at the same time, because a single circuit has worse availability than a VPN.
- Why do overlapping IP ranges break hybrid cloud connectivity?
- Two networks cannot exchange routes for the same address range, so when both sides have claimed parts of 10.0.0.0/8 the routers have ambiguous destinations and traffic goes to the wrong place. The fixes are all costly: network address translation hides real addresses and breaks anything embedding an IP, and renumbering means rebuilding subnets. Allocating a non-overlapping cloud range before building anything avoids the entire problem.
- How does DNS resolution work between on-premise and cloud?
- It has to be configured in both directions with conditional forwarding. Internal resolvers forward queries for the cloud's private zones to a resolver endpoint inside the cloud network, and the cloud resolver forwards queries for internal zones back to on-premise resolvers. The common failure is a cloud workload resolving an internal hostname to its public address and routing over the internet instead of the private link, which works and therefore goes unnoticed.
- Why does traffic get dropped between on-premise and cloud even though the tunnel is up?
- Most often asymmetric routing. If traffic leaves by one path and returns by another, any stateful firewall in the middle drops the return packet because it never saw the session start. The other frequent cause is exceeding the route propagation limit on a cloud gateway, where a network advertising every internal subnet individually hits the prefix cap and the remaining routes stop propagating without an obvious error.
