Build Multi-Cloud VPN Gateways That Survive Downtime

Modern enterprises rarely bet their entire future on a single cloud provider. Instead, they strategically distribute workloads across AWS, Azure, and Google Cloud to optimize costs, leverage best-in-class services, and avoid vendor lock-in. However, this multi-cloud advantage hinges on one critical factor: secure, reliable, and performant connectivity between these disparate environments. For IT administrators tasked with knitting this fabric together, the challenge is practical and architectural. This step-by-step tutorial, grounded in 2026 research and best practices, details how to setup multi cloud vpn gateway architectures that are secure, resilient, and manageable. We'll navigate the native tools, design patterns, and configuration specifics for connecting the big three clouds.

Why a Multi-Cloud VPN Gateway? Resilience and Latency Benefits

Pursuing a multi-cloud strategy without a robust connectivity plan undermines its core benefits. As of 2026, over 89% of enterprises operate across two or more public clouds, with 47% running four or more. Yet, 63% of enterprise architects cite inter-cloud connectivity as their top operational pain point. A well-designed multi-cloud VPN gateway directly addresses these challenges by providing:

Resilience: Eliminating a Single Point of Failure (SPOF) is paramount. If one cloud region experiences an outage, traffic can be routed via VPN tunnels to another provider. This complements high-availability designs within a single cloud.
Performance & Latency: For globally distributed applications, a multi cloud vpn gateway can route user traffic to the closest cloud ingress point, reducing latency compared to backhauling all traffic to a single provider.
Cost Optimization: Internet-based site-to-site VPNs are often the most cost-effective interconnect option, especially for bursty or moderate-volume traffic. Research indicates that for workloads moving less than 10-20 TB/month, VPNs are typically more economical than premium dedicated interconnects like AWS Direct Connect or Azure ExpressRoute.
Operational Flexibility: It enables hybridization, allowing you to connect on-premises data centers to multiple clouds and facilitate cloud-to-cloud migrations and disaster recovery scenarios.

A 2026 survey found that 63% of enterprise architects cite inter-cloud connectivity as their top operational pain point, ahead of cost management and security policy consistency.

Architecture Overview: Site-to-Site VPNs and Transit Gateways

The foundational architecture for a multi cloud vpn gateway setup is the site-to-site (S2S) IPsec VPN tunnel. Each major cloud provider offers a managed VPN gateway service: AWS Site-to-Site VPN, Azure VPN Gateway, and Google Cloud HA VPN. These gateways terminate encrypted IPsec tunnels, often using the IKEv2 protocol.

The most scalable design pattern is the Hub-and-Spoke with Cloud Transit Gateway. In this model:

A central "hub" virtual network/VPC is established in each cloud (or one primary cloud acts as the central hub).
Each cloud's native transit service (AWS Transit Gateway, Azure Virtual WAN, or GCP Network Connectivity Center) aggregates connections from its internal "spoke" VPCs.
Site-to-site VPN tunnels are established between the cloud providers' hub gateways.
Dynamic routing via Border Gateway Protocol (BGP) is used to automatically advertise network routes across all connected environments.

This architecture centralizes management and provides a clear traffic flow for inspection and policy enforcement.

Prerequisites: Accounts, Permissions, and Network Planning

Before executing the setup multi cloud vpn gateway process, ensure these foundational elements are in place:

Cloud Accounts and Permissions: You need active accounts with appropriate administrative or network contributor roles in AWS, Azure, and Google Cloud. Ensure your user/service principal has permissions to create virtual networks, VPN gateways, and related resources.
Network Address Planning: This is critical to avoid IP conflicts. Allocate non-overlapping CIDR blocks for each VPC/Virtual Network across all clouds and your on-premises networks. For example:
- AWS VPCs: 10.10.0.0/16, 10.20.0.0/16
- Azure VNets: 172.16.0.0/12
- GCP VPCs: 192.168.0.0/16
Autonomous System Number (ASN) Planning: For BGP dynamic routing, each gateway needs a unique ASN. Use private ASNs in the range 64512-65535. A common convention is:
- On-premises: ASN 65001
- AWS: ASN 64512
- Azure: ASN 65515
- GCP: ASN 65001 (must be unique per Cloud Router)
Tooling: Decide on your deployment method. We'll reference CLI commands and Terraform code snippets where applicable, as Infrastructure-as-Code is recommended for reproducibility.

Step 1: Configuring the AWS Virtual Private Gateway (VGW)

The AWS side of the connection involves creating a Virtual Private Gateway (VGW) attached to your VPC and defining Customer Gateways representing your peers (Azure and GCP).

Create the Virtual Private Gateway: Attach a VGW to your hub VPC. This gateway will terminate incoming VPN connections.

Define Customer Gateways: Create a Customer Gateway resource for each remote peer. This resource stores the public IP address of the remote VPN gateway and its BGP ASN.

# Terraform example for Azure peer
resource "aws_customer_gateway" "azure" {
  bgp_asn    = 65000  # Azure VPN Gateway's BGP ASN
  ip_address = "52.143.72.189" # Azure VPN Gateway Public IP
  type       = "ipsec.1"
}

# Terraform example for GCP peer
resource "aws_customer_gateway" "gcp" {
  bgp_asn    = 64514
  ip_address = google_compute_address.vpn_external.address # GCP External IP
  type       = "ipsec.1"
  tags = {
    Provider = "GCP"
  }
}

Create VPN Connections: Establish a VPN Connection resource linking your VGW to each Customer Gateway. For resilience, create two tunnels per connection (each uses a different gateway endpoint). Enable BGP for dynamic routing.

resource "aws_vpn_connection" "azure_bgp_enabled" {
  vpn_gateway_id      = aws_vpn_gateway.main.id
  customer_gateway_id = aws_customer_gateway.azure.id
  type                = "ipsec.1"
  static_routes_only  = false # Enable BGP

  tunnel1_inside_cidr = "169.254.10.0/30"
  tunnel2_inside_cidr = "169.254.20.0/30"
  tunnel1_bgp_asn    = "65000"
  tunnel2_bgp_asn    = "65000"
}

Step 2: Setting Up the Azure VPN Gateway and Local Network

Azure requires a dedicated GatewaySubnet and a Virtual Network Gateway of type Vpn. As of 2026, you must use the AZ SKU family (e.g., VpnGw2AZ) for new gateways, as the non-zonal SKUs are being retired.

Create the GatewaySubnet: In your hub Virtual Network, create a subnet named exactly GatewaySubnet with a /26 or /27 CIDR block.

az network vnet subnet create \
  --resource-group MyResourceGroup \
  --vnet-name MyVnet \
  --name GatewaySubnet \
  --address-prefixes 10.0.1.0/24

Deploy the VPN Gateway: Create a Virtual Network Gateway. For production, select a Gen2 AZ SKU (like VpnGw2AZ), enable zone-redundancy, and critically, enable active-active mode. This provides two live instances, each with its own public IP, for high availability and failover without drops. Enable BGP and set the ASN (default is 65515).
Create Local Network Gateways: This resource represents the on-premises or other-cloud side. Create one for AWS and one for GCP, inputting their VPN gateway public IPs and on-premises CIDR ranges (or BGP peer IP).
Establish Connections: Finally, create Connection resources that link your Azure VPN Gateway to each Local Network Gateway, specifying the shared pre-shared key (PSK) and BGP settings.

An active-active, zone-redundant Azure VPN Gateway provides a 99.95% SLA and supports up to 10 Gbps aggregate throughput on the VpnGw5AZ SKU.

Step 3: Creating Cloud Router and VPN on Google Cloud

Google Cloud's solution is Cloud VPN (specifically HA VPN for production). The setup involves creating an external VPN gateway pointing to AWS/Azure, a Cloud VPN gateway, and a Cloud Router for BGP.

Create HA VPN Gateway: In your GCP VPC, create an HA VPN gateway. This is a regional, highly available resource.
```
gcloud compute vpn-gateways create aws-gateway \
  --region=us-central1 \
  --network=default
```

Define External VPN Gateway: Create a resource representing the peer's VPN gateway using its public IP.

gcloud compute external-vpn-gateways create aws-external \
  --interfaces=0=34.203.215.127 # AWS VPN Public IP

Create Cloud Router: This managed service runs BGP sessions. Create a router with a unique ASN for the region.
Configure VPN Tunnels: Create two VPN tunnels (for redundancy) per peer connection. Each tunnel links the HA VPN gateway, the external VPN gateway, the Cloud Router, and specifies the shared secret and BGP peer information.

GCP HA VPN offers a 99.99% SLA, supports up to 10 Gbps throughput with multiple tunnels, and benefits from GCP's global VPC routing model.

Step 4: Establishing BGP Sessions for Dynamic Routing

Static routing is manageable for simple setups, but for a resilient multi cloud vpn gateway, dynamic routing with BGP is essential. It enables automatic failover and route propagation without manual intervention.

BGP Session Establishment: When configured on both sides of each VPN tunnel (AWS-Azure, Azure-GCP, AWS-GCP), BGP peers will establish sessions over the encrypted IPsec tunnels. The "inside tunnel" IPs (e.g., 169.254.x.x/30) are used for this peer-to-peer communication.
Route Advertisement: Each Cloud Router or VPN Gateway will advertise the CIDR ranges of its attached VPCs/networks to its peers.
Route Preference and Failover: Use BGP attributes like AS_PATH prepending to influence path selection. Ideally, design for two active tunnels with BGP Equal-Cost Multi-Path (ECMP) routing for load balancing and immediate failover.

Proper BGP design is critical for multi-cloud VPN success. Best practices include advertising aggregated CIDR blocks, applying inbound/outbound route filters to prevent leaks, and using two active tunnels with BGP ECMP for load balancing and fast failover.

Step 5: Testing Connectivity and Failover Scenarios

Once configured, validate the setup thoroughly.

Tunnel State: Use cloud provider CLIs to check VPN tunnel status. For AWS:
```
aws ec2 describe-vpn-connections --vpn-connection-ids vpn-12345678
```
BGP Peer Status: Verify BGP sessions are established on all Cloud Routers and VPN gateways.
Network Reachability: Launch test instances in spoke VPCs across clouds and use ping or traceroute to verify connectivity over the private tunnel IPs (not public IPs).
Failover Testing: Simulate a failure by disabling one tunnel or shutting down a test instance in one cloud. Observe BGP convergence (typically within seconds) and verify traffic reroutes via the alternate tunnel or cloud path.

Cloud provider monitoring tools (Amazon CloudWatch, Azure Monitor, Google Cloud Operations) can be used to create dashboards for ongoing visibility.

# Example CloudWatch dashboard creation for monitoring
aws cloudwatch put-dashboard \
  --dashboard-name "Multi-Cloud-VPN-Monitoring" \
  --dashboard-body file://vpn-dashboard.json

Security Hardening: Encryption Protocols and Access Controls

A multi cloud vpn gateway is a critical security perimeter. Harden it using these practices:

Encryption Protocols: Configure IPsec policies to use strong, modern standards. Research recommends IKEv2 with AES-256-GCM encryption for its performance and security. Enable Perfect Forward Secrecy (PFS) to protect past sessions if a key is compromised.
Pre-Shared Key (PSK) Management: Use strong, randomly generated PSKs and implement a process for regular rotation.

Network Segmentation and ACLs: Apply network access control lists (NACLs) or firewall rules to restrict traffic over VPN tunnels. Only allow necessary protocols and ports between specific CIDR blocks.

# Example AWS NACL for Azure-specific traffic
resource "aws_network_acl" "azure_traffic" {
  vpc_id = aws_vpc.main.id
  ingress {
    rule_no    = 100
    from_port  = 0
    to_port    = 0
    protocol   = "-1"
    cidr_block = "10.1.0.0/16" # Specific Azure VNet range
  }
}

Least Privilege IAM: Ensure the cloud identities used to manage the VPN gateways have only the necessary permissions.

Ongoing Management, Monitoring, and Cost Optimization

Deploying the gateway is just the beginning. Effective ongoing management is key.

Centralized Monitoring: Aggregate logs and metrics from all three clouds into a single dashboard. Set alerts for tunnel state changes, BGP session drops, and bandwidth thresholds.
Cost Management: VPN gateway costs are primarily from:
- Gateway Hourly Fees: e.g., $32.40/month for an AWS VPN connection, ~$29.20/month for an Azure VPN Gateway hour, $35.40/month for a GCP HA VPN gateway.
- Data Egress Fees: Traffic exiting one cloud to another over the internet incurs egress fees (e.g., $0.09/GB for AWS, $0.087/GB for Azure, $0.12/GB for GCP premium tier).
Regularly review traffic patterns. If sustained traffic between two clouds exceeds 15-20 TB/month, evaluate dedicated interconnects (AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect) for potential cost savings and performance benefits.

Automation: Use Terraform or similar IaC tools to manage the entire setup. This ensures consistency, enables version control for network configuration, and simplifies recreation or modification.

# Reusable Terraform module for different providers
module "site_to_site_vpn" {
  source = "./modules/vpn-connection"
  for_each = var.cloud_providers
  provider_name     = each.key
  customer_gateway_ip = each.value.gateway_ip
  bgp_asn          = each.value.bgp_asn
  routes           = each.value.routes
  vpn_gateway_id   = aws_vpn_gateway.main.id
}

FAQ

What is the main benefit of using BGP with a multi-cloud VPN? BGP enables dynamic routing, which automatically propagates network route changes across all connected clouds and provides automatic failover between redundant VPN tunnels, significantly improving resilience without manual reconfiguration.

How does the cost of a multi-cloud VPN compare to dedicated interconnects (like AWS Direct Connect)? Site-to-site VPNs over the internet have lower fixed costs (no port fees) but incur data egress charges. Dedicated interconnects have higher monthly port fees but lower per-GB data transfer costs. Research indicates VPNs are more cost-effective for sustained traffic below roughly 15-20 TB/month per connection.

Which VPN protocol and encryption should I use? At the time of writing, best-practice guidance recommends using the IKEv2 protocol with AES-256-GCM encryption and enabling Perfect Forward Secrecy (PFS). These provide a strong balance of security and performance.

Can I use third-party or mesh VPN solutions instead of native cloud gateways? Yes. In 2026, solutions like Tailscale (WireGuard-based), Netbird, or enterprise appliances from Palo Alto Networks or Fortinet offer alternative models. These can simplify mesh networking and provide advanced security features but introduce a third-party dependency and potential cost.

Is active-active mode important? Yes, for production environments. Active-active mode (available on Azure and through multiple tunnels on AWS/GCP) means both sides of a VPN connection have live gateways. This eliminates the brief downtime associated with failover in active-standby mode and can increase aggregate throughput.

Bottom Line

Setting up a secure multi cloud vpn gateway across AWS, Azure, and Google Cloud in 2026 is a tractable but detailed task. Success hinges on meticulous network planning (non-overlapping CIDRs, unique BGP ASNs), leveraging the modern, zone-redundant SKUs (like Azure's AZ family), and implementing dynamic routing with BGP for true resilience. While cloud-native VPN services offer a managed, integrated path, your architecture must account for the trade-offs in performance, cost, and complexity. By following the step-by-step configurations for each provider, hardening security with modern encryption, and implementing centralized monitoring and automation, IT administrators can build a robust connectivity backbone that unlocks the full strategic potential of a multi-cloud environment.