What happens when your office network needs to talk to a virtual private cloud, but the public internet sits in between? That is the problem a cloud VPN solves. It builds an encrypted tunnel between your own network and a cloud provider’s network, so traffic crosses the open internet without being readable to anyone in the middle.
The idea sounds simple. The practice is where teams get tripped up. Tunnel configuration, routing choices, throughput ceilings, and high-availability design all matter, and small mistakes show up as outages rather than error messages. This article walks through what a cloud VPN actually is, how it works under the hood, where it fits against dedicated connections, and what to watch for when you build one.
What a Cloud VPN Actually Is
A cloud VPN is a site-to-site IPsec tunnel between a customer network and a cloud provider’s virtual private cloud network. Google Cloud’s documentation describes Cloud VPN as connecting an on-premises network to a VPC network over IPsec, with traffic encrypted in transit. AWS and Azure offer equivalent services: AWS Site-to-Site VPN and Azure VPN Gateway.
The key word is site-to-site. This is not the consumer VPN you install to hide browsing from an ISP. It connects two networks, not two people. Servers in a data center reach private IP addresses inside a cloud VPC as if they were on the same local network, and the cloud sees the traffic as coming from a trusted peer.
Most cloud VPNs also support point-to-site connections, where individual laptops dial in. But the site-to-site case is the one that carries production workloads, and it is the one that requires real design work.
The Standards Behind the Tunnel
Cloud VPNs are not proprietary magic. They are built on IPsec, a family of protocols standardized by the IETF. The current architecture document is RFC 4301, published in December 2005, which defines how IPsec authenticates and encrypts packets. The encryption itself is typically handled by ESP, defined in RFC 4303.
Key exchange is usually IKEv2, defined in RFC 7296 in October 2014. IKEv2 negotiates security associations, rotates keys, and handles reconnection after a tunnel drops. Most cloud gateways support IKEv2 as the default; some still support IKEv1 for legacy equipment that cannot be upgraded. (9481.org)
Why does this matter to someone configuring a tunnel? Because both ends must agree on the same parameters. Encryption algorithm, integrity algorithm, Diffie-Hellman group, lifetime, and pre-shared key or certificate must match exactly. A single mismatch produces a tunnel that never comes up, often with a log message that says very little.
Modern cloud gateways typically default to AES-256 for encryption and SHA-256 for integrity, with Diffie-Hellman groups 14 or higher. Those defaults are reasonable. The temptation to weaken them to match an old firewall is where security quietly erodes.
How Traffic Flows Through a Cloud VPN
A cloud VPN connection involves four moving parts:
- The customer device. The physical or virtual device on your side: a firewall, a router, or a software appliance.
- The cloud VPN endpoint. The provider-managed endpoint that terminates the tunnel.
- The tunnel itself. The encrypted IPsec connection between the two endpoints.
- Routing. The mechanism that decides which traffic enters the tunnel and which goes elsewhere.
Routing is the part people underestimate. Some configurations use static routing, where you list the remote subnets by hand. Others use BGP, where the two sides advertise routes dynamically and reconverge when a link fails. Static routing is simpler to set up and easier to break silently: add a new subnet in the cloud, forget to add it to the static list, and traffic vanishes with no obvious cause.
BGP adds configuration complexity but pays it back the first time a tunnel fails. Routes withdraw automatically, traffic shifts to the surviving tunnel, and nobody pages anyone at 3 a.m.
High Availability: Single Tunnel vs. Redundant Design
A single VPN tunnel is a single point of failure. The internet path between your data center and a cloud region crosses multiple networks, any of which can degrade. Providers address this with two tiers of service.
| Feature | Classic / single-tunnel VPN | High-availability VPN |
|---|---|---|
| Tunnel interfaces | One | Two, on separate infrastructure |
| Routing | Static only | BGP supported |
| Typical SLA | Around 99.9% | Around 99.99% |
| Failure behavior | Tunnel down means outage | Traffic fails over to second tunnel |
| Setup effort | Lower | Higher, needs two customer gateways or one with two interfaces |
Google Cloud, for example, offers HA VPN with a 99.99% SLA and Classic VPN with a 99.9% SLA. AWS documents a 99.95% SLA for Site-to-Site VPN. Those numbers look close until you convert them: 99.9% allows roughly 43 minutes of downtime a month, while 99.99% allows about four.
The practical lesson is that HA design requires redundancy on both ends. Two cloud tunnels terminating on one customer device still fail together if that device dies. Teams that plan for a second physical device, or a second internet provider, avoid the most common design flaw.
Cloud VPN vs. Dedicated Interconnect
Cloud VPN runs over the public internet. Dedicated interconnects, such as Google Cloud Interconnect, AWS Direct Connect, and Azure ExpressRoute, run over private fiber from a colocation facility to the provider’s edge. The trade-off is straightforward.
| Dimension | Cloud VPN | Dedicated interconnect |
|---|---|---|
| Transport | Public internet, encrypted | Private circuit, often unencrypted by default |
| Bandwidth | Bounded per tunnel, often a few Gbps | Scales to 10 Gbps and beyond |
| Latency and jitter | Variable, dependent on internet paths | Predictable |
| Time to deploy | Hours to days | Weeks to months |
| Cost model | Low monthly, egress charges | Port fees plus carrier circuit costs |
| Best fit | Moderate traffic, fast setup, backup path | Heavy or latency-sensitive workloads |
A common pattern is to use both. The interconnect carries bulk production traffic, and a cloud VPN sits alongside as a backup path that activates when the private circuit fails. Because the VPN is already configured and tested, failover is a routing change rather than a project.
For teams still mapping out what needs to move and what needs to connect, a structured inventory before a cloud migration makes the connectivity decisions much easier to justify.
Throughput, Bandwidth, and the Numbers People Miss
Per-tunnel throughput is capped by the provider, and the caps are lower than many teams expect. Google Cloud documents roughly 3 Gbps per tunnel for HA VPN; AWS documents up to 1.25 Gbps per tunnel. Aggregate throughput scales by adding tunnels, but each tunnel has its own ceiling.
Three practical consequences follow.
First, encryption costs CPU. A software customer device pushing several Gbps will saturate long before the tunnel does. Check the device’s IPsec throughput rating, not its raw routing throughput.
Second, TCP over long paths behaves badly. A tunnel between continents adds round-trip latency, and single TCP flows slow down accordingly. More tunnels do not fix latency; they only add capacity.
Third, egress charges still apply. VPN traffic leaving the cloud is billed like any other egress. A clearer way to track cloud data transfer costs helps here, because tunnel traffic often hides inside a general egress line item until someone asks why the bill jumped.
Configuration Mistakes That Actually Happen
Most cloud VPN outages trace back to a small set of recurring errors. None of them are exotic.
- Mismatched proposals. One side offers AES-256/SHA-256/DH14, the other insists on AES-128/SHA-1/DH2. The tunnel never establishes. Fix: compare both configurations line by line before assuming the network is at fault.
- Overlapping subnets. The on-premises range and the VPC range share addresses. Traffic routes to the wrong place or is dropped. Fix: plan address space before deployment, not after.
- Missing return routes. The tunnel comes up, traffic flows one way, and replies disappear because the remote network has no route back.
- Forgotten firewall rules. IPsec succeeds, but the security group or firewall policy blocks the actual application ports. Tunnel status looks green while nothing works.
- No dead peer detection tuning. A tunnel that silently stops passing traffic without being torn down leaves traffic black-holed. DPD settings and BGP hold timers determine how fast the system notices.
- Pre-shared keys in documentation. Credentials pasted into a wiki page outlive the engineer who wrote them. Rotate them and store them properly.
There is a pattern in this list: every item is a configuration mismatch, not a hardware failure. Cloud VPN troubleshooting is mostly a comparison exercise between two configs.
Security Considerations Beyond Encryption
Encryption in transit is table stakes, but it is not the whole security story.
Tunnel scope matters. A VPN that routes entire VPC ranges into a corporate network extends the corporate attack surface into the cloud and vice versa. Route only the subnets that need to talk.
Authentication is a weak point. Pre-shared keys are convenient and common, but certificate-based authentication with rotation is stronger. Some providers support both; choose deliberately.
Logging is often missing. Tunnel up/down events, IKE negotiation failures, and BGP session changes should land in the same monitoring system as everything else. A tunnel that flaps every few hours is a symptom worth investigating.
The VPN is not a segmentation strategy. Once traffic enters the VPC, it is subject to whatever security controls exist there. A VPN does not replace network policies, identity controls, or workload-level authorization. Enterprise AI and cloud security controls need to apply inside the perimeter as well as at its edge.
When to Split Connectivity Across Accounts
Larger organizations rarely run one VPC. They run dozens, spread across accounts or projects, often with separate teams owning each. Connectivity design has to follow that structure.
A hub-and-spoke model centralizes VPN termination in a shared networking account and routes spoke traffic through it. This keeps the number of tunnels manageable and centralizes inspection. The alternative, per-account tunnels, multiplies configuration and cost but gives teams autonomy.
The decision usually comes down to blast radius and ownership. When to split workloads across cloud accounts is a related question, and the same logic applies: boundaries that match team ownership tend to age better than boundaries drawn for convenience.
Conclusion
A cloud VPN is one of the few pieces of cloud infrastructure that is genuinely simple in concept and genuinely fiddly in practice. The concept is an encrypted IPsec tunnel between two networks. The practice involves matching proposals on both ends, choosing routing that survives failure, sizing throughput against real device limits, and accepting that redundancy only works when it exists on both sides.
The teams that get this right tend to do three things. They plan address space and routing before deployment. They build two tunnels and test failover deliberately rather than trusting the SLA. And they treat the VPN as one layer in a broader connectivity and security design, not as a finished solution.
Start with the smallest working tunnel, verify it carries traffic in both directions, then add redundancy. That order catches configuration errors while they are still cheap to fix.
A final operational note. Keep a written record of every tunnel’s parameters—peer addresses, proposals, routing mode, and owning team—and review it whenever either side changes. Most silent failures are drift: one end updated, the other forgotten. A quarterly comparison of both configurations costs an hour and prevents the outages described above. Cloud VPN rewards discipline more than cleverness, and the discipline is mostly documentation and deliberate testing.
