A cloud VPN is a VPN whose gateway runs in the cloud and is operated by a cloud provider or a VPN service vendor, not on hardware the organisation runs itself. Staff devices and office networks connect to that gateway through encrypted tunnels to reach the organisation’s applications and networks.
“Cloud VPN” is not a standards term. It describes where the VPN gateway runs and who operates it, not a protocol. Some consumer VPN apps also carry the name.
TL;DR
- A cloud VPN’s gateway runs in the cloud and is operated by a vendor or a cloud provider. It comes in two forms: a cloud-delivered service, which some vendors call VPN as a service, or a cloud provider’s managed gateway at the edge of the organisation’s virtual private cloud.
- With a cloud-delivered service, staff usually sign in through the organisation’s identity provider and connect to a vendor site; with a provider’s gateway, offices usually connect their own gateway over IPsec. Both use the same kinds of protocols as other VPNs.
- Unlike an on-premises VPN, the provider or vendor runs and patches the gateway and bills by gateway hours and data transfer, or by subscription; the organisation still decides who gets access.
- The tunnel ends on the vendor’s or provider’s systems; HTTPS inside it stays encrypted unless TLS inspection is on. Admitted users get network-level access unless policy narrows it, and a vendor outage can cut access for many customers.
- It suits organisations with remote staff or cloud-hosted applications. A VPN you run on a rented cloud server, or a consumer app named “Cloud VPN”, is not a cloud VPN in this sense.
What does “cloud VPN” mean?
The term covers two business products and, more loosely, some consumer apps.
| Meaning | Who runs the gateway | What it connects | Who uses it | Example |
|---|---|---|---|---|
| Cloud-delivered service (VPN as a service, VPNaaS) | A VPN service vendor, in its data centres | Staff devices, and sometimes office networks, to company applications and networks | Organisations with remote or distributed staff | A remote access service sold by a security vendor |
| Cloud provider’s managed gateway | The cloud provider | An office or data centre network to a virtual private cloud; some also connect individual users | Organisations with servers or applications in a public cloud | Google Cloud VPN, AWS Site-to-Site VPN, Azure VPN Gateway |
| Consumer use of the name | A consumer VPN provider | One person’s device to the internet | Individuals | Consumer apps named “Cloud VPN” |
Cloud-delivered service. A vendor runs the VPN gateways in its data centres, often called points of presence: the vendor’s sites where users’ connections arrive. The organisation manages its users and access policy from the vendor’s management console. Some vendors call this VPN as a service (VPNaaS). It can replace, or run alongside, the gateway an organisation would otherwise run in its own office or data centre.
Cloud provider’s managed gateway. AWS, Microsoft Azure and Google Cloud each offer a VPN gateway that the customer configures and the provider runs. It connects an office or data centre network to a virtual private cloud (VPC), the customer’s private network inside the provider’s platform. Google’s product is named Cloud VPN and supports site-to-site connections only. Routing, redundancy and gateway sizes for these services are covered in the site-to-site VPN guide.
How does a cloud VPN work?
A cloud VPN works like any VPN: devices or networks send traffic through encrypted tunnels to a gateway, which decrypts it and passes it on.
In a cloud-delivered service
The user’s device connects to the vendor’s site, the user signs in, and the vendor applies the organisation’s policy.
- Connect. The VPN client on the user’s device connects to one of the vendor’s points of presence, usually one near the user, chosen by the service or by the administrator’s settings.
- Sign in. The service usually sends the user to the organisation’s identity provider, the system that holds staff accounts, through SAML or OpenID Connect. Multi-factor authentication (MFA) set there therefore applies to the VPN. Some services also accept a device certificate.
- Apply policy. The tunnel ends in the vendor’s data centre, where the organisation’s access policy is applied.
- Forward traffic. Traffic for private applications travels on through connectors or through site tunnels from the organisation’s offices. A connector is software the organisation installs on its own servers or cloud networks; it makes outbound connections to the service. Depending on the split tunnelling settings, internet traffic can also leave from the vendor’s site.
With a cloud provider’s managed gateway
The customer creates and configures the gateway in the cloud platform; the provider deploys and runs the instances behind it. Azure, for example, builds each gateway from two or more virtual machines that it manages.
The office gateway and the cloud gateway then set up IPsec tunnels across the internet. IPsec is the IETF’s set of protocols for securing traffic at the IP layer. Depending on the provider and its settings, either side can start the connection; on AWS, the office gateway does by default. Traffic is decrypted on the provider-managed gateway at the edge of the virtual network and routed to the servers and applications.
Some provider services also connect individual users: Azure VPN Gateway through point-to-site connections, and AWS through a separate service, AWS Client VPN.
In both forms, the tunnels use the same kinds of protocols as other VPNs. Site connections usually use IPsec; client connections use IPsec with IKEv2, TLS-based tunnels, WireGuard or newer HTTP/3-based tunnels, depending on the service. The VPN protocols guide compares them.
What are the types of cloud VPN?
Cloud VPNs connect either individual devices or networks, and some products do both.
Client-to-cloud (remote access)
A VPN client on each device connects to the cloud gateway. Remote and travelling staff use it, and so do contractors. Cloud-delivered services are built for this. Among the cloud providers, AWS offers it as a separate service (AWS Client VPN), Azure VPN Gateway offers it as point-to-site, and Google Cloud VPN does not offer it. The client, sign-in and device checks work as in any remote access VPN.
Site-to-cloud (site-to-site)
The gateway at an office or data centre keeps IPsec tunnels open across the internet to the cloud gateway, so the devices behind it need no VPN software. AWS Site-to-Site VPN, Azure VPN Gateway and Google Cloud VPN all do this, and some cloud-delivered services also accept site tunnels from offices.
Google Cloud VPN comes in two gateway types, HA VPN and Classic VPN; they are Google’s products, not general types of cloud VPN. Their availability commitments vary by configuration, from 99.99% to 99.9%, and some setups have none.
Cloud VPN vs traditional (on-premises) VPN
The difference is who owns and runs the gateway. When applications move to the cloud, an on-premises gateway can send remote users’ traffic through the organisation’s own network first and then back out to the internet. NIST calls this hair-pinning: it adds distance and latency and can create bottlenecks.
| On-premises VPN | Cloud provider gateway | Cloud-delivered service | |
|---|---|---|---|
| Who runs the gateway | The organisation, on its own hardware or software | The cloud provider | The VPN service vendor |
| Patching and upgrades | The organisation | The provider | The vendor; the organisation may still update clients and, with some services, connectors |
| Capacity | Limited by the device and, on some products, the licence; growth means new hardware or more licences | Set by the gateway size or tunnel type the customer chooses | Scaled by the vendor, within the licence |
| Cost model | Hardware or licences, maintained in-house (capital expense) | Billed by usage: hours plus data transfer (operating expense) | Subscription, usually per user for staff; office connections may be licensed by bandwidth or by site (operating expense) |
| Maintenance timing | The organisation decides | Varies: AWS and Azure give partial control; Google may maintain at any time without notice | Set mainly by the vendor; some services let customers pick a preferred upgrade window |
| Where users connect | The office or data centre | The cloud network, where the provider offers user connections | One of the vendor’s sites, usually near the user |
| Route to cloud-hosted applications | Can go back through the organisation’s own network first | Over IPsec tunnels across the internet, from the office gateway to the cloud network | From the vendor’s site |
| What faces the internet | The organisation’s gateway | The provider’s gateway, normally on a public IP address; VPN over private circuits is also offered | The vendor’s sites, on public IP addresses |
Who is responsible for what?
Moving the gateway to a provider or vendor moves the gateway’s upkeep, not the organisation’s responsibility for who gets access.
| Task | Cloud provider gateway | Cloud-delivered service |
|---|---|---|
| Gateway software, patching and upgrades | Provider | Vendor |
| Gateway uptime and capacity | Provider, within the gateway size and redundancy the customer configures | Vendor |
| Identity and multi-factor sign-in | Customer | Customer |
| Access policy | Customer | Customer |
| User devices and client software | Customer | Customer |
| Hosting connectors (and, with some services, updating them) | Not applicable | Customer |
| Reviewing logs and acting on them | Customer | Customer (the vendor provides the logs) |
| On-premises gateway at the other end of a site tunnel, with enough redundancy | Customer | Customer |
Where traffic is decrypted
With a cloud-delivered service, the VPN tunnel ends in the vendor’s data centre, so the vendor’s systems see the traffic once the tunnel encryption is removed. The content of web traffic protected by HTTPS stays encrypted unless the organisation turns on TLS inspection, where the service offers it: the service then decrypts HTTPS traffic, inspects it and re-encrypts it before sending it on. With a cloud provider’s gateway, traffic is decrypted on the provider-managed gateway at the edge of the virtual network (in Azure, inside a dedicated gateway subnet of that network), then routed to the servers and applications.
AWS, Microsoft and Google each publish a shared responsibility model that leaves data and access control with the customer.
Benefits of a cloud VPN
The benefits come from handing the gateway to a provider or vendor.
- No gateway hardware to buy or patch. The organisation still maintains its clients, any connectors it hosts and any on-premises gateway at the other end of a site tunnel.
- Capacity without new hardware. More capacity comes from a larger gateway size or more tunnels from the provider, or from the vendor scaling its service within the licence. Costs rise with usage or the number of users.
- Shorter routes to cloud applications. Users connect to a vendor site, usually near them, instead of routing through the organisation’s own network. This helps when the applications are in the cloud, not when they are in the office.
- Central management. With a cloud-delivered service, users and policy are managed from the vendor’s management console.
Is a cloud VPN safe? Limitations and risks
A cloud VPN encrypts traffic in its tunnels with standard protocols, but it is not free of risk: the risks lie in the access it grants, the dependence on the provider or vendor, flaws in the gateways and the customer’s own configuration.
- Network-level access. Once admitted, a user can reach whatever the access policy allows on the network. Zero trust network access (ZTNA) grants access to individual applications, per session, instead.
- Outage dependence. An outage at the vendor or provider can cut access for many of its customers at once.
- The vendor sees traffic after the tunnel ends. With a cloud-delivered service, the vendor’s systems handle traffic once the tunnel encryption is removed, although the content of HTTPS traffic stays encrypted unless TLS inspection is turned on.
- Lock-in. Proprietary clients and policy formats can make switching vendors difficult.
- Where traffic is processed. The vendor’s sites decrypt and inspect the traffic, wherever they are; some vendors let customers limit the regions used.
- The customer’s share remains. Identity, multi-factor sign-in, access policy and configuration mistakes stay with the customer.
- Public gateways still need fixes. The vendor’s or provider’s gateways are reachable from the internet and need security fixes like any gateway; the vendor or provider applies them, mostly on its own schedule.
What is not a cloud VPN?
A VPN you run on a rented server, a mesh VPN, a consumer VPN and a private circuit to a cloud provider are not cloud VPNs in the business sense.
- A VPN you run on a rented cloud server. This is a self-hosted VPN: the customer installs it and patches the operating system and the VPN software.
- A mesh VPN. In a mesh VPN, the coordination service may be hosted, but traffic flows directly between devices where the network allows, and through a relay otherwise.
- A consumer VPN service. A consumer VPN also runs its servers in data centres, but it carries one person’s traffic to the internet; the business meanings give an organisation’s staff or offices access to its private networks. Consumer VPN apps named “Cloud VPN” can be free to download and sell paid upgrades; are free VPNs safe to use covers their risks.
- A private circuit to a cloud provider. Azure ExpressRoute and AWS Direct Connect bypass the public internet and are not encrypted by default, although an IPsec VPN can run over them.
Where does a cloud VPN fit in SASE?
A cloud-delivered VPN can be one part of a larger cloud security service. NIST notes that Gartner coined the term secure access service edge (SASE) in 2019 for an architecture that delivers networking and security functions together as a cloud service. Some cloud-delivered security platforms include remote access VPN in the same service as zero trust network access and a secure web gateway, which filters users’ web traffic.
When does a cloud VPN make sense?
A cloud VPN suits organisations that would rather not run gateways and whose staff or applications are already spread out.
It fits when:
- no one on staff runs and patches VPN gateways;
- the workforce is distributed;
- contractors and other third parties need limited, temporary access, sometimes from devices the organisation does not manage;
- applications already run in the cloud;
- offices need to reach a virtual private cloud, for example while moving servers to the cloud or to copy data there for backup or disaster recovery;
- older applications, or applications that open ports dynamically, need network-level access rather than access to one application.
It fits less well when:
- the organisation must control software versions or the timing of maintenance;
- data must not pass through a third party’s systems;
- the organisation’s on-premises gateways already work.
An example: remote staff and a cloud-hosted application
A cloud-delivered service can give home workers a shorter route to a cloud-hosted application. Take an organisation whose staff work from home and whose finance application runs in a virtual private cloud. With an on-premises gateway, a remote user’s traffic can travel to the organisation’s own network first and then out to the cloud. With a cloud-delivered service, the user connects to a vendor site, usually one near them, signs in through the organisation’s identity provider and reaches the application through a connector in the virtual private cloud.
Frequently asked questions
What is the difference between a VPN and a cloud VPN?
A cloud VPN is an ordinary VPN whose gateway is run for the organisation by a cloud provider or vendor. The encryption is no different: both rely on protocols such as IPsec or TLS. What changes is who runs and patches the gateway.
What is a cloud VPN used for?
Organisations use a cloud-based VPN to give remote staff and contractors access to company applications and cloud networks without running their own gateway. Offices also use it to link their networks to a virtual private cloud during a server migration, or for backup and disaster recovery.
Is a cloud VPN a remote access VPN or a site-to-site VPN?
It can be either, or both. Cloud-delivered services are designed for remote access, and some also accept tunnels from offices. Among the cloud providers, Google Cloud VPN and AWS Site-to-Site VPN connect networks only, AWS handles individual users through a separate service, and Azure VPN Gateway does both.
How do you set up a cloud VPN?
For a cloud-delivered service, the organisation connects it to its identity provider, sets access policy in the vendor’s console, usually installs a client on staff devices and adds connectors or site tunnels. For a provider’s gateway, it configures the gateway in the cloud platform and sets up IPsec tunnels between it and the office gateway.
Is a cloud VPN free?
Usually not. Cloud providers bill their VPN gateways by the hour plus data transfer. Cloud-delivered services charge a subscription, usually per user, and some price office connections by bandwidth or by site. Consumer VPN apps called “Cloud VPN” are a different product, and some are free to install.
What is VPN as a service (VPNaaS)?
VPN as a service is a name some vendors use for a cloud-delivered VPN. The vendor runs the gateways in its data centres and keeps them patched. The organisation decides, from the vendor’s console, who can connect and what they can reach.
Is Google Cloud VPN a cloud VPN?
Yes, in the cloud provider sense. Google Cloud VPN is a managed gateway that connects an office or data centre network to a Google Cloud virtual private cloud over IPsec. Google states that it does not support client-to-gateway connections, so individual devices cannot dial in to it with VPN client software.
Is a consumer VPN a cloud VPN?
Not in the business sense, although both run on servers in data centres. A consumer VPN serves one person: it routes their internet traffic through its servers and changes the IP address websites see. A cloud VPN connects an organisation’s staff or offices to the organisation’s private applications and networks.
Is Cloudflare WARP (1.1.1.1) a cloud VPN?
The consumer app is not. Cloudflare’s app, “1.1.1.1: Faster Internet”, encrypts traffic between your device and Cloudflare’s network in its “Traffic and DNS” mode, and Cloudflare states that WARP does not provide anonymity. Cloudflare’s business client, the Cloudflare One Client (formerly WARP), is different: it connects staff devices to a cloud-delivered service.
Can I run my own VPN in the cloud?
Yes. You can rent a cloud server and install VPN software such as WireGuard or OpenVPN on it. That is a self-hosted VPN, not a managed cloud VPN: you run and patch the server, its operating system and the VPN software yourself.
Is a cloud VPN the same as zero trust network access?
No. A VPN admits a device to the network, and the user can then reach anything the access policy permits. Zero trust network access grants access to one application at a time, per session. Some cloud-delivered platforms offer both in the same service.
Does a cloud VPN slow down your connection?
It can. Encryption and tunnelling add overhead to every packet. A nearby vendor site can also shorten the route to cloud applications compared with sending traffic through the organisation’s own network first. The result depends on where the user, the vendor’s site and the application are.