A cloud VPN is a managed tunnel endpoint, offered by a cloud platform, that connects your office or data center to your cloud network, or links users to it. Under the label it is usually IPsec. The provider runs the gateway, but you still own the keys, routes and access rules.
What is actually inside it?
The term is used for two things. One is a site-to-site connection between your gateway device and a virtual gateway in a cloud network. The other is a remote access service for people. This post covers the first, because that is where cloud-specific questions arise.
For the site-to-site kind, the building blocks are the same open standards used between any two gateways. RFC 4301 defines the security architecture for IP, and RFC 7296 defines IKEv2, which performs mutual authentication and sets up the security associations. NIST SP 800-77 Rev. 1 is the practical guide for organizations. If you can read your on-premises tunnel configuration, you can read the cloud side.
What does the provider handle?
Typically the provider operates the cloud gateway: availability, patching of the gateway software and scaling. You get an endpoint address and a list of supported settings. That saves you running and updating a gateway in the cloud yourself.
What stays with you?
Quite a lot.
Algorithm choices. Providers often support several settings for compatibility. Choose the strongest your device supports, and disable older suites where you can. NIST SP 800-77 Rev. 1 is the reference for what to pick.
Authentication. Pre-shared keys are easy and easy to mishandle. A long random key per tunnel, stored in a secrets manager, is the minimum. Certificates are better where both ends support them.
Routing. A tunnel is only useful with routes, and routes decide what can talk to what. If you advertise your whole office network into the cloud and the cloud network back, a compromise on one side can reach the other. Advertise only the subnets that need to talk.
Redundancy. A single tunnel is a single failure. Use two tunnels on separate paths or devices, and test failover.
Firewall rules on both sides. The tunnel carries traffic. It does not authorize it. Add security groups or firewall rules on the cloud side, and policy on your own gateway, following NIST SP 800-41 Rev. 1, which advises that traffic not expressly permitted should generally be denied.
Monitoring. Track tunnel state, throughput, and rekey failures, and alert on a tunnel that flaps.
How is it different from a VPN gateway you run?
A self-run gateway is a virtual machine or appliance you patch and size. It gives you full control over software and logs, at the cost of upkeep. A managed cloud VPN trades some control for less work. Neither changes the rules on keys, routes and filtering.
A constructed example
A logistics firm connects its warehouse router to a cloud network with two IPsec tunnels. At first it advertises the whole warehouse range, including the building's camera network, into the cloud. During a review, an engineer notices that a compromised cloud workload could reach the cameras through the tunnel. The team narrows the advertised routes to the two subnets used by the inventory system, replaces the shared key with a per-tunnel random value, and adds a deny-by-default rule on the warehouse router for anything arriving from the tunnel that is not inventory traffic.
How to check or apply this
- List the subnets that really need to talk across the tunnel.
- Use certificates or long random keys, one per tunnel, held in a secrets manager.
- Choose strong algorithm settings and turn off legacy suites.
- Build two tunnels and test failover during a quiet window.
- Add deny-by-default rules on both ends.
- Alert on tunnel flaps and rekey failures.
- Review the route list and keys on a schedule.
Quick check
Is a cloud VPN a different protocol?
Usually not. Most managed site-to-site VPNs use IPsec with IKE, defined in RFC 4301 and RFC 7296.
Does a cloud VPN protect traffic inside the cloud?
No. It protects traffic crossing the tunnel. Traffic between workloads inside the cloud needs its own controls.
Sources
- RFC 4301, Security Architecture for the Internet Protocol
- RFC 7296, Internet Key Exchange Protocol Version 2
- NIST SP 800-77 Rev. 1, Guide to IPsec VPNs
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
Last reviewed: 18 October 2026.
