What exactly is someone asking for when they say they need a “cloud VPN”? The honest answer is that it depends on who is talking. A network engineer at a bank, a startup founder, and a cloud architect at a retailer may all use the same three words to describe three different things. That ambiguity is not a small detail. It shapes budgets, security reviews, and architecture decisions. This article pins down the most common meaning, explains the alternatives, and shows where the term breaks down so readers can ask better questions in their next design meeting.
The Core Definition Most People Mean
A cloud VPN is an encrypted tunnel that connects a private network to a cloud provider’s virtual network over the public internet. One end sits on premises, in a data center, or in another cloud. The other end is a VPN gateway managed by the cloud provider. Traffic between them travels through an IPsec tunnel, which encrypts packets and authenticates both ends before any data flows. (A clearer way to track cloud data transfer costs)
That is the definition used in the networking documentation of the major cloud platforms. It is the “site-to-site” case, and it is what most organizations mean when they budget for a cloud VPN line item.
The tunnel itself is not magic. It relies on a well-documented set of standards. The IPsec architecture is defined in a public standards document, and readers who want the full technical picture can review the IETF specification for the IPsec security architecture, which describes how authentication headers and encapsulating security payloads work together. The key exchange that sets up the tunnel is usually handled by IKEv2, and the IETF’s IKEv2 protocol standard (RFC 7296) explains the negotiation steps in detail. Those two standards are the foundation under nearly every cloud VPN product on the market.
What travels through the tunnel
Once the tunnel is up, it carries ordinary IP traffic. Applications do not need to know a VPN exists. A database server in a private rack can talk to a virtual machine in the cloud as if they sat on the same switch. That transparency is the main appeal. It also means a misconfigured tunnel can quietly expose more than intended, which is why firewall rules and routing tables matter as much as the encryption itself.
The Two Topologies You Will Actually See
Cloud VPN deployments fall into two broad shapes, and mixing them up causes most of the confusion in planning meetings.
| Topology | What it connects | Typical use |
|---|---|---|
| Site-to-site | On-premises network to a cloud virtual network | Hybrid workloads, lift-and-shift migrations, legacy system access |
| Cloud-to-cloud | One cloud provider’s network to another’s | Multi-cloud redundancy, data sharing between platforms |
| Client-to-cloud | Individual devices to a cloud network | Remote workers, contractor access |
The first two are the classic cloud VPN patterns. The third is sometimes offered as a separate remote-access VPN service and is often confused with zero-trust network access products, which solve a similar problem in a different way.
Site-to-site in practice
Most site-to-site setups involve a physical or virtual appliance on the customer side and a provider-managed gateway on the cloud side. The provider handles high availability, key rotation, and failover between tunnels. The customer handles routing, firewall policy, and making sure the on-premises device supports the exact encryption parameters the provider expects.
That last point trips people up constantly. A tunnel that fails to come up is almost always a mismatch in phase-one or phase-two settings, not a broken internet connection. Engineers who have done a few of these learn to check the proposal settings first and everything else second. (9481.org)
High Availability Changes the Math
Early cloud VPN products offered a single tunnel with a modest uptime commitment. Modern offerings are different. Providers now sell HA VPN configurations that run two or more tunnels across separate infrastructure and publish service level agreements in the high nineties of a percent.
The practical difference is significant. A single tunnel means a maintenance window or a routing hiccup can take down the link. A redundant pair means one path can fail without anyone noticing. For workloads that cannot tolerate a few minutes of downtime, the redundant option is not optional.
The same logic appears across providers. AWS documents a site-to-site model with two tunnels per connection specifically so that one can fail while the other carries traffic. Azure’s VPN Gateway documentation describes site-to-site, point-to-site, and virtual-network-to-virtual-network connections as distinct types, each with its own redundancy story. Google Cloud separates its HA VPN product from a classic option with a lower availability commitment. The names differ, but the architecture lesson is the same: count the tunnels before promising an uptime figure to the business.
Cloud VPN Versus Dedicated Interconnect
A frequent point of confusion is the difference between a VPN and a private connection. They solve overlapping problems but are not interchangeable.
A cloud VPN runs over the public internet. That makes it fast to set up, cheap to start, and available almost anywhere. It also means performance varies with internet conditions, and latency is whatever the route gives you.
A dedicated interconnect is a private physical link from a customer’s facility to the cloud provider’s network. It offers predictable bandwidth, lower and steadier latency, and a different SLA. It also takes weeks or months to provision and costs considerably more.
The usual pattern is to start with a VPN, measure what the workload actually needs, and move to a dedicated link only when the numbers justify it. Teams that skip the measurement step often over-provision. Teams that never revisit the decision often end up running production traffic over a link that was sized for a proof of concept.
Managed Service or Self-Managed Appliance?
Here is where the definition genuinely splits. “Cloud VPN” can also describe a vendor-hosted VPN service — a managed endpoint that lives in the cloud and handles authentication for remote users — as opposed to a VPN appliance a team runs on its own virtual machines.
The two meanings share a name and little else. A site-to-site tunnel joins networks. A managed remote-access service joins people to applications. One is infrastructure plumbing. The other is an access control product with a user directory, a client app, and a per-seat price.
Readers comparing offerings should check three things before assuming they are looking at the same category:
- Does the product connect networks or individual users?
- Who operates the endpoint — the provider or the customer?
- What is the unit of pricing — bandwidth, tunnels, or seats?
Getting clear answers to those questions early prevents a procurement conversation from going sideways later. It also explains why search results for the term look so inconsistent.
Security Reality Check
An IPsec tunnel protects data in transit. It does not decide who should reach which resource once the packets arrive. That distinction matters more than it used to.
A VPN extends a network boundary. Anything routable across the tunnel is reachable unless something else stops it. Many breaches that get blamed on “the VPN” were really failures of internal segmentation — a flat network behind a strong tunnel. The tunnel did its job. The access model did not.
The current practice is to pair VPN connectivity with identity-based access controls, per-workload firewall rules, and logging that shows who reached what. Public-sector guidance on deploying IPsec VPNs, such as the NIST guide to IPsec VPNs, walks through planning, implementation, and validation in more depth than any vendor page will. It is worth reading before a first deployment rather than after an incident review.
A useful habit: treat every VPN tunnel as a trust boundary that needs its own rules, not as a trusted hallway into the network. That single shift in framing changes how teams write firewall policy.
Common Mistakes That Show Up Again and Again
Certain problems recur across organizations of every size. Recognizing them in advance saves weeks.
Skipping the inventory. Teams deploy a tunnel before listing which subnets need to talk to which. The result is overlapping CIDR ranges that cannot be routed without re-addressing. A disciplined pre-migration inventory catches this early.
Ignoring cost visibility. VPN gateway hours and data processing charges are easy to overlook until the first invoice. Tracking transfer costs separately from compute costs keeps surprises small.
Treating the tunnel as permanent. Tunnels are configuration, not concrete. They should be documented, version-controlled, and reviewed on a schedule.
Forgetting the return path. Asymmetric routing is a classic tunnel-era failure. Traffic goes out through the VPN and comes back through a different path, and the connection silently dies.
Assuming the SLA covers the application. A 99.99% tunnel SLA says nothing about whether the application behind it stays up. Availability has to be designed end to end.
How Cloud VPN Fits Into a Broader Architecture
A VPN is rarely the whole story. It is one connection type among several, and mature teams treat connectivity as a portfolio.
Some workloads belong on a private interconnect. Some belong on a VPN. Some should never leave the cloud region they were built in. The decision depends on latency tolerance, data volume, regulatory constraints, and how often the workload changes. That is why connectivity planning belongs with the broader architecture review rather than in a networking silo.
The same discipline applies to account structure. Splitting workloads across separate cloud accounts changes how many tunnels are needed, who owns them, and how they are monitored. Teams that plan account boundaries and connectivity together avoid a common trap: a single sprawling network that nobody can safely change. For readers thinking through that split, there is useful guidance on when to split workloads across cloud accounts that pairs well with connectivity planning.
Conclusion
A cloud VPN, in its most useful definition, is an encrypted IPsec tunnel between a private network and a cloud provider’s virtual network, carried over the public internet and terminated at a provider-managed gateway. That definition covers most real deployments. It does not cover all of them, because the same phrase is also used for cloud-to-cloud links and for managed remote-access services. The term is genuinely ambiguous, and treating one vendor’s framing as universal leads to bad comparisons.
The practical takeaway is to ask what is being connected and who operates each end before agreeing on a product name. Once that is clear, the rest follows: pick a topology, count the tunnels, decide whether the internet is good enough or a dedicated link is warranted, and wrap the whole thing in access controls that assume the tunnel is not a trust badge. Do that, and the ambiguity stops being a problem and starts being a checklist.
Frequently Asked Questions
What is a cloud VPN in simple terms?
It is an encrypted connection between a private network and a cloud provider’s network, running over the public internet. Traffic enters a tunnel at one end and comes out at the other, so both sides behave as if they were on the same network. The encryption keeps the data unreadable to anyone in between.
Is a cloud VPN the same as a regular VPN?
Not quite. A consumer VPN hides a single device’s traffic behind a remote server. A cloud VPN typically joins entire networks, often permanently, and is managed by a cloud provider’s gateway. The underlying IPsec technology overlaps, but the scale, configuration, and operational ownership are different.
Does a cloud VPN replace a private connection?
No. A VPN runs over the public internet, so performance depends on internet conditions. A dedicated interconnect is a private physical link with predictable bandwidth and a different SLA. Many organizations use a VPN for smaller or temporary links and a dedicated connection for high-volume production traffic.
How many tunnels should a cloud VPN have?
At least two for anything that matters. Redundant tunnels across separate infrastructure let one path fail without dropping the connection. Single-tunnel setups are fine for testing or non-critical links, but they turn every maintenance window into an outage risk.
Is a cloud VPN secure enough for sensitive data?
The tunnel itself is strong when configured correctly. The bigger risk is what sits behind it. A VPN does not decide who can reach which resource, so it must be paired with identity controls, firewall rules, and logging. A flat internal network behind a perfect tunnel is still a flat internal network.
Why do vendors describe cloud VPN so differently?
Because there is no single standards-body definition. Some vendors mean a tunnel to their cloud, some mean a tunnel between clouds, and some mean a managed remote-access service. The word describes a family of products rather than one specification, so the details have to be checked per offering.
