Cloud VPN: Encrypted Tunnels Between On-Premises Networks and Cloud Environments

Most cloud adoption scenarios start with a hybrid architecture: some systems stay on-premises, some move to the cloud, and they need to talk to each other securely. The financial system stays in the data centre because the migration is two years out. The new analytics platform runs in AWS. The analytics platform needs to read data from the financial system. How does that traffic flow, and how is it protected?

Cloud VPN is the most common answer, and the first architecture that most organisations deploy for this problem. It creates an encrypted IPsec tunnel between the on-premises network and the cloud VPC (Virtual Private Cloud). Traffic that traverses the tunnel is encrypted in transit and the connection appears to both sides as a direct network link.

What a Cloud VPN Actually Does

A cloud VPN connects two IP networks using IPsec (Internet Protocol Security), a suite of protocols that authenticate and encrypt IP packets. The tunnel runs over the public internet but the contents are encrypted — an attacker who intercepts packets in transit sees only ciphertext.

The cloud side of the tunnel terminates at a cloud VPN gateway — a managed appliance provided by the cloud vendor. The on-premises side terminates at a customer gateway device: a physical router or firewall (Cisco ASA, Palo Alto, pfSense, FortiGate) configured with IPsec parameters matching the cloud gateway.

Once the tunnel is established, routing determines which traffic flows through it. This is where BGP (Border Gateway Protocol) becomes important for production deployments.

Site-to-Site Cloud VPN Architecture
--------------------------------------
On-Premises Network              AWS / Azure / GCP
  [192.168.0.0/16]                 [10.0.0.0/16]
       |                                 |
  [Customer Gateway]  <== IPsec ==>  [Cloud VPN GW]
  (Cisco/Palo Alto/                 (Managed service)
   FortiGate/pfSense)
       |                                 |
  [On-Prem Servers]           [VMs / Databases / Apps]

Traffic flows:
  Server (192.168.1.10) --> VPN GW --> encrypted --> Cloud GW --> VM (10.0.1.5)
  All traversal: encrypted with AES-256 / IKEv2

Static vs Dynamic Routing (BGP)

Simple VPN configurations use static routes: you manually define which IP ranges live on each side of the tunnel and enter them into the routing configuration. Static routing works for small, stable networks, but it has a significant limitation: it cannot adapt automatically to network changes.

BGP (Border Gateway Protocol) is the routing protocol that powers the internet’s routing tables. In a cloud VPN context, BGP peers exchange route information dynamically. If an on-premises network adds a new subnet, the BGP peer advertises it and the cloud VPN learns the route automatically. If a VPN tunnel fails in an HA configuration, BGP detects the failure and fails over to a working path without manual intervention.

AWS Site-to-Site VPN supports BGP through the Virtual Private Gateway. GCP Cloud VPN supports BGP on HA VPN tunnels. Azure VPN Gateway supports BGP on route-based VPN gateways. For any production VPN that connects networks of more than trivial complexity, BGP is strongly preferred over static routing.

High Availability VPN Design

A single VPN tunnel is a single point of failure. If the VPN gateway in the cloud has a maintenance event, or the internet path between the gateways degrades, traffic stops. For production workloads that depend on connectivity between on-premises and cloud, high availability design is required.

AWS HA VPN: AWS Virtual Private Gateway automatically creates two VPN endpoints in different Availability Zones. Each endpoint has two tunnels to the customer gateway. A properly configured HA VPN has four IPsec tunnels, and traffic continues as long as at least one tunnel is active. AWS’s SLA for the VPN service is 99.95% per connection.

GCP HA VPN: GCP’s HA VPN guarantees 99.99% availability when configured with two gateways and four tunnels (two tunnels per gateway). This is achieved by routing traffic through redundant Google network paths.

Azure redundant VPN: Azure VPN Gateway supports active-active configuration with two gateways, each with its own public IP, providing redundancy at both the Azure and customer gateway level.

HA VPN Design (AWS Example)
-------------------------------
On-Premises:
  [Primary Customer GW]     [Secondary Customer GW]
        |   |                       |   |
        |   +--------+   +----------+   |
        +------------+-+-+              |
                     | |                |
              [AWS VGW Endpoint 1]   [AWS VGW Endpoint 2]
              (AZ-a)                 (AZ-b)
                     |                  |
               [AWS VPC 10.0.0.0/16]

Result: 4 tunnels total
        Failover if any single component fails
        AWS SLA: 99.95% per tunnel pair

Bandwidth and Performance Considerations

Cloud VPN runs over the public internet, which means bandwidth and latency are variable and not guaranteed. AWS Site-to-Site VPN tunnels support up to 1.25 Gbps per tunnel. GCP Cloud VPN supports up to 3 Gbps per tunnel with newer HA VPN configurations. Azure VPN Gateway supports up to 10 Gbps on VpnGw5 SKU.

These numbers are ceilings. Actual throughput depends on:

The internet connection quality at the on-premises site
Route path between the on-premises gateway and the cloud region
Encryption overhead (IPsec adds roughly 10–20% overhead on payload)
Number of concurrent flows (VPN performance degrades with many small flows)

For most hybrid connectivity scenarios involving normal business traffic — application data, API calls, database queries — cloud VPN provides adequate performance. For scenarios involving large data transfers (migrating terabytes of data, replicating databases continuously, streaming large media files), cloud VPN may become a bottleneck.

When to Upgrade to Direct Connect or ExpressRoute

Cloud VPN runs over the public internet. When the public internet’s variability creates problems — consistent latency, bandwidth predictability, or regulatory requirements that data not traverse the public internet — the answer is a dedicated private connection.

AWS Direct Connect: A private network connection between your data centre and an AWS Direct Connect location. Traffic never traverses the internet. Available in 1 Gbps, 10 Gbps, and 100 Gbps configurations. Latency is consistent and predictable. Cost is significantly higher than VPN.

Azure ExpressRoute: Equivalent service from Azure, available through telecom providers who connect to Microsoft’s edge routers at peering facilities.

GCP Cloud Interconnect: GCP’s equivalent, available as Dedicated Interconnect (direct physical connection) or Partner Interconnect (through a network service provider).

The decision: use cloud VPN for initial connectivity, moderate bandwidth requirements, and cost-sensitive use cases. Move to dedicated connections when latency variability causes application problems, when bandwidth requirements exceed what a reliable internet connection can support, or when compliance requires that traffic not traverse the public internet.

Cloud VPN is where hybrid connectivity starts. For the majority of organisations, it is also where it stays — because the cost of dedicated circuits is only justified when the workload clearly outgrows what VPN can support.