A cloud VPN is a managed service that connects your own network to a virtual network in the cloud through an encrypted IPsec tunnel, so the two behave like parts of one private network. It protects traffic in transit between those sites. It does not decide who may reach what once traffic arrives.
How does a cloud VPN work?
Google's Cloud VPN documentation gives a plain description: it extends a peer network to a Virtual Private Cloud network through an IPsec VPN connection. The traffic is encrypted by a VPN gateway at one end and decrypted by the gateway at the other. You can also connect two cloud networks together by linking two Cloud VPN instances.
The standard underneath is IPsec. NIST SP 800-77 Revision 1 calls IPsec a widely used network layer security control and a framework of open standards for private communication over IP networks, usually configured with the Internet Key Exchange protocol. That is why gateways from different providers and vendors can usually talk to each other if both sides agree on the settings.
Is a cloud VPN the same as a consumer VPN?
No, and the names cause confusion. A consumer VPN app routes one device's traffic through a provider's server. A cloud VPN is site to site infrastructure: a gateway on each side, tunnels between them, and routes that decide which subnets are reachable. It is a plumbing component for hybrid networks, not a privacy app.
What can go wrong?
Three things appear again and again.
First, encryption is not authorization. A tunnel between your office and a cloud network usually makes the whole remote subnet reachable unless you add rules. If a laptop in the office can reach every database in the cloud network, the VPN did exactly what it was asked to do and your design did the rest.
Second, availability. The documentation says its highly available gateway type can provide an SLA of 99.99% or 99.9% depending on topology and configuration. The point to take away is that the figure depends on how you configure it, so a single tunnel is not the same design as two.
Third, key and configuration drift. IPsec has many parameters, and NIST's guide exists largely because the choices matter. A tunnel that still works but negotiates weak settings looks healthy on every dashboard.
One more design question is routing. Some setups use static routes you maintain by hand, others exchange routes dynamically between the gateways. Dynamic routing saves effort when networks change often, but it also means a wrong advertisement on one side can redirect traffic on the other, so decide who may advertise which ranges and review the result after every change.
A constructed example
A retailer connects a warehouse to a cloud network with one tunnel. A firewall change at the warehouse silently drops the IKE traffic on a Friday night and the stock system loses its database. The retailer adds a second tunnel over a different internet link, and then limits the warehouse subnet to the single database port the stock system actually needs. Availability improved, and so did the blast radius if a warehouse machine is ever compromised.
How to check or apply this
- Draw the networks and the tunnels, and write down which subnets can talk to which.
- Replace "all traffic allowed" with the specific ports and sources each workload needs, on both sides.
- Use more than one tunnel for anything that must stay up, and test failover by taking one down.
- Check the IPsec and IKE parameters against current NIST guidance and remove old algorithms.
- Monitor tunnel state and traffic volume, and alert on a tunnel that stays up with no traffic or a sudden change in volume.
- Put certificate or pre-shared key rotation on a calendar with an owner.
- If you also need user access, treat that as a separate design. A site to site tunnel does not authenticate people.
Quick check
Does a cloud VPN encrypt traffic inside the cloud network?
Not by itself. It encrypts traffic between the two gateways. Traffic inside each network is protected by whatever controls you have there.
What standard do cloud VPN tunnels usually use?
IPsec, usually configured with the Internet Key Exchange protocol, as described in NIST SP 800-77 Revision 1.
Sources
Last reviewed: 18 October 2026.
