Roughly 60% of corporate data now lives in the cloud, according to long-running industry surveys, yet most companies still run at least one on-premises system that has to talk to it. That gap is exactly where cloud VPN work happens, and where most projects quietly go sideways. The tunnels come up, the pings work, and then a database replication job stalls at 1,400 packets per second because nobody clamped the MSS.
This guide walks through what actually matters when you build a site-to-site cloud VPN: choosing the right model, sizing it honestly, configuring IPsec and BGP, and avoiding the mistakes that fill support tickets. No vendor marketing, just the mechanics.
What a cloud VPN actually is (and what it isn’t)
A cloud VPN connects a private network to a cloud provider’s virtual network over an encrypted IPsec tunnel across the public internet. That’s the site-to-site flavor. It is not the same thing as a client VPN, which connects individual users’ laptops to a network. AWS Client VPN, Azure Point-to-Site, and similar products solve a different problem, and guides that blur the two cause real confusion during procurement.
The distinction matters because the engineering constraints differ. Site-to-site tunnels are always-on, route-based, and measured in throughput and availability. Client VPNs are session-based and measured in concurrent users. Mixing them up leads to gateways that are undersized for one job and overpriced for the other.
Every major provider supports IPsec with IKEv2 as the preferred key exchange. IKEv2 is specified in RFC 7296, published by the IETF in 2014, and it’s the version most providers now default to or recommend. Older IKEv1 configurations still work in many places but are increasingly treated as legacy. The underlying architecture is described in RFC 4301, which is worth skimming once if you want to understand why certain settings exist rather than just copying them.
Pick the right topology before you touch a console
Three patterns cover almost every real deployment. Choosing badly at this stage is the most expensive mistake in the whole project, because re-architecting later means new subnets, new route tables, and a change window nobody wants.
| Topology | How it works | Best for | Main drawback |
|---|---|---|---|
| Single tunnel | One IPsec tunnel from on-prem firewall to cloud gateway | Dev/test, low-stakes links | No failover; one outage kills connectivity |
| Dual tunnel (active/passive or active/active) | Two tunnels, often to two different cloud endpoints | Production workloads | More configuration; needs BGP or careful static routing |
| Hub-and-spoke with transit | Spokes connect to a central hub VPC/VNet, which connects on-prem | Many VPCs or regions | Higher cost; hub becomes a critical dependency |
AWS documents two tunnels per Site-to-Site VPN connection as its standard high-availability model. Azure offers active-active and zone-redundant gateway SKUs. Google Cloud’s HA VPN advertises a 99.99% SLA versus 99.9% for its classic VPN. Those figures shift with SKU generations, so check the provider’s current SLA page and note the access date in your design document. Quoting a number from a blog post written three years ago is how design reviews go wrong.
For multi-cloud or multi-region estates, the hub-and-spoke model usually wins, but the transit layer costs money every hour. Teams comparing providers often find the VPN gateway itself is cheap while the data processing charges are not. A broader comparison of AWS vs Azure vs Google Cloud in 2026 helps frame those cost structures before you commit.
Sizing: the part everyone gets wrong
Throughput on a cloud VPN is bound by the gateway SKU, not by the internet connection. Azure VPN Gateway throughput scales across its SKU families. AWS Site-to-Site VPN has documented per-tunnel bandwidth limits. Neither number is negotiable through configuration tweaks.
Practical rules that hold up in real deployments:
- Size for peak, not average. Backup windows and month-end batch jobs compress traffic into short bursts that blow past averages.
- Assume one tunnel’s worth of capacity during failover. If both tunnels normally carry traffic and one dies, the survivor must handle the load.
- Measure single-flow throughput separately. IPsec tunnels often deliver good aggregate throughput but poor per-flow performance. A single database replication stream may never exceed a fraction of the tunnel’s capacity.
- Check the on-premises side too. A cloud gateway rated for 1.25 Gbps is useless behind a firewall that tops out at 300 Mbps.
If sustained throughput above a few gigabits per second is a hard requirement, a VPN tunnel is usually the wrong tool. Dedicated interconnects exist for that reason. VPNs are for connectivity that needs to be encrypted, resilient, and affordable, not for bulk data movement at line rate.
Step-by-step implementation
The sequence below works across providers with minor naming differences.
1. Plan address space with zero overlap
Overlapping CIDR ranges between on-premises and cloud are the single most common blocker. If the on-prem network uses 10.0.0.0/8 and the cloud VPC also uses 10.0.0.0/16, no amount of clever routing fixes it. Map every subnet first, then allocate cloud ranges that don’t collide. This is tedious and absolutely worth the afternoon.
2. Build the cloud gateway and confirm the shared key handling
Create the virtual network gateway or VPN gateway in the target region, choosing a SKU that matches your throughput plan. Generate a strong pre-shared key and store it in a secrets manager, not in a wiki page. Rotate it on a schedule.
3. Configure the on-premises peer
Set up the IPsec policy to match: IKE version, encryption and integrity algorithms, DH group, and lifetime values. Mismatched lifetimes cause tunnels that establish and then drop at regular intervals, which is maddening to debug. NIST’s Guide to IPsec VPNs (SP 800-77 Rev. 1) remains the reference document for policy selection and is available through NIST’s Computer Security Resource Center.
4. Choose BGP over static routing
BGP lets the tunnel advertise routes dynamically and fail over automatically when a link drops. Static routing works, but every subnet change becomes a manual edit on both sides. For anything beyond a lab, run BGP with private ASNs. Most providers support it on their VPN gateways.
5. Tune MTU and MSS
IPsec adds overhead, so the effective MTU inside the tunnel is smaller than the physical link. If you don’t clamp MSS, large packets get dropped silently and small ones sail through, producing the classic symptom of SSH working fine while file transfers hang. Set the tunnel MTU per the provider’s documentation and apply MSS clamping on the on-premises firewall. Each provider publishes a recommended value; use theirs rather than guessing.
6. Test failover deliberately
Bring one tunnel down during a maintenance window and watch what happens. Does traffic reroute within seconds, or does it black-hole for two minutes while BGP reconverges? Does the application reconnect, or does it need a restart? Testing this on a Tuesday afternoon is far better than discovering it during an incident.
7. Monitor the right signals
Track tunnel status, BGP session state, packet loss, and latency per tunnel. Alert on tunnel flapping, not just on total downtime. A tunnel that bounces every 20 minutes is worse than one that’s cleanly down, because it corrupts long-lived sessions without triggering a clean failover.
Where encryption and access control fit
The tunnel encrypts traffic in transit, but it doesn’t decide who can reach what. Keep security groups and network ACLs tight on both sides of the connection. A VPN that exposes an entire on-premises subnet to an entire cloud VPC is a flat network with extra steps.
If remote workers also need access, that’s a separate build. Understanding the difference between a VPN and a proxy clarifies which tool handles encryption versus which handles traffic inspection, and it’s a distinction that comes up constantly in hybrid designs. For teams standardizing on client-side tooling, reviews of the best VPN services cover the consumer and small-business end of the market, which is a different product category from enterprise site-to-site gateways but often confused with them.
Common mistakes and how to sidestep them
Skipping the redundancy design. A single tunnel is a single point of failure. If the workload matters, build two.
Ignoring asymmetric routing. When return traffic takes a different path than outbound traffic, stateful firewalls drop it. Check route tables on both sides and confirm the return path is symmetric.
Forgetting DNS. The tunnel is up, but name resolution still points at on-premises servers that aren’t reachable. Plan conditional forwarders or private DNS zones as part of the build, not as an afterthought.
Treating the pre-shared key as a formality. Long, random keys stored properly cost nothing and remove an entire class of risk.
Not documenting the policy. Six months later, nobody remembers which DH group is in use. Write it down, including the provider documentation version you followed.
Cloud platforms evolve quickly, and gateway features follow. Teams evaluating broader platform direction may find context in coverage of Apple private cloud compute and Google Cloud in 2026, which illustrates how confidential computing and network isolation are converging. The same trend affects how much you can trust a shared network path.
Conclusion
A cloud VPN is not complicated in concept. It’s a pair of IPsec tunnels, a routing protocol, and a firewall policy. What makes implementations fail is the unglamorous detail: overlapping subnets discovered late, MTU values left at defaults, failover never tested, throughput assumptions borrowed from a marketing page instead of a SKU table.
The teams that get this right tend to follow the same pattern. They map address space before provisioning anything. They choose a topology that matches their redundancy requirement rather than their budget alone. They run BGP, clamp MSS, and test a tunnel failure on purpose. And they write down every policy value with the date they confirmed it, because cloud gateway documentation changes and memory doesn’t.
Start with the smallest topology that meets the requirement, prove failover works, then scale. A two-tunnel production link that has been tested beats a four-region mesh that nobody has ever failed over on purpose.
FAQ
How long does a typical cloud VPN implementation take?
A single-tunnel lab connection can be running in under an hour. A production deployment with dual tunnels, BGP, DNS integration, and tested failover usually takes one to three weeks of elapsed time, most of it spent on change coordination and testing rather than configuration.
Do I need BGP, or is static routing enough?
Static routing is fine for a lab or a single small VPC that rarely changes. For production, BGP is the better choice because it handles failover automatically and removes the need to manually update routes on both sides whenever a subnet is added.
Why does my tunnel connect but large transfers stall?
This is almost always an MTU or MSS problem. IPsec overhead shrinks the usable packet size, and unclamped large packets get dropped while small ones pass. Set the tunnel MTU to the provider’s documented value and enable MSS clamping on the on-premises firewall.
What’s the difference between a cloud VPN and a client VPN?
A cloud VPN (site-to-site) connects two networks, such as an office and a cloud VPC, and stays up continuously. A client VPN connects individual users’ devices to a network on demand. They use similar encryption but are sized and managed very differently.
Can I connect multiple cloud providers with VPNs?
Yes. Each provider’s gateway terminates standard IPsec, so a mesh or hub-and-spoke design across providers is technically straightforward. The complexity is in routing, address planning, and cost, since every tunnel and every gigabyte processed may carry a charge.
How often should I rotate pre-shared keys?
A common practice is every 90 to 180 days, coordinated with a maintenance window so both sides change together. Store keys in a secrets manager, never in documentation or tickets, and confirm the rotation procedure works before you need it under pressure.
