Google Cloud HA VPN to AWS with BGP: Complete Guide

Introduction

As organizations adopt multi-cloud strategies, applications and services are increasingly distributed across cloud providers. It is common to see customer-facing workloads running in AWS while analytics, AI/ML, or data platforms operate in Google Cloud.

The challenge is enabling secure, resilient, and private communication between these environments without exposing traffic to the public internet.

This is where Google Cloud HA VPN and AWS Site-to-Site VPN become essential.

In this guide, we will build a highly available VPN architecture between Google Cloud and AWS using dynamic routing with Border Gateway Protocol (BGP). We will also examine how enterprises validate these connections in production environments and how the architecture supports real-world use cases such as disaster recovery, AI integrations, and hybrid application deployments.

If you are new to cloud networking, check out my guide on Azure Hub and Spoke Architecture.

You may also be interested in my Kubernetes Controllers Explained article.

For infrastructure automation, read Terraform for Beginners – Complete Introduction to Infrastructure as Code.

To understand enterprise cloud design patterns, explore Azure Private Endpoint – Complete Deep Dive Guide.

Business Problem

Imagine a financial organization running:

AWS

Customer-facing banking APIs
Mobile banking applications
Web portals

Google Cloud

Fraud detection engines
BigQuery analytics
AI workloads
Data lake platforms

The banking API must securely communicate with the fraud detection platform before approving transactions.

Without a private connection:

AWS Application
      |
   Internet
      |
Google Cloud AI Platform

Problems:

Increased attack surface
Compliance concerns
Public internet dependency
IP whitelisting complexity
Unpredictable latency

A private VPN architecture solves these challenges.

According to the Google Cloud HA VPN documentation, HA VPN provides a highly available IPSec VPN service with a 99.99% service availability SLA when deployed according to recommended practices.

Solution Architecture

Key components:

Google Cloud VPC
Google Cloud HA VPN Gateway
Cloud Router
AWS Customer Gateways
AWS Virtual Private Gateway
Dynamic routing through BGP

Understanding the Components

Google Cloud HA VPN

Building secure connectivity between cloud providers is relatively easy. Building connectivity that remains operational during failures is significantly more challenging. This is where Google Cloud High Availability (HA) VPN becomes a critical component of enterprise networking architectures.

HA VPN is Google’s managed VPN service designed to provide resilient, highly available IPSec connectivity between Google Cloud and external networks such as AWS, Azure, on-premises data centers, or colocation facilities.

Unlike traditional VPN deployments that rely on a single tunnel and a single endpoint, HA VPN is built with redundancy at its core. Each HA VPN gateway automatically provisions two independent VPN interfaces, each with its own public IP address. These interfaces can establish multiple VPN tunnels to remote gateways, enabling fault tolerance and continuous connectivity.

Why HA VPN Instead of Classic VPN?

Traditional VPN architectures often suffer from a single point of failure.

AWS
  |
Single VPN Tunnel
  |
Google Cloud

If the tunnel fails, connectivity between environments is immediately lost.

With HA VPN:

AWS
   |
Tunnel 1
Tunnel 2
Tunnel 3
Tunnel 4
   |
Google Cloud HA VPN

Multiple tunnels ensure that traffic can continue flowing even when one or more tunnels become unavailable.

Benefits of Google Cloud HA VPN

99.99% Service Availability SLA

Google provides a 99.99% availability SLA for HA VPN when configured according to recommended practices.

This means organizations can confidently use the solution for mission-critical workloads such as:

Banking systems
Healthcare applications
E-commerce platforms
Enterprise ERP systems
Hybrid cloud deployments

Automatic Failover

One of the biggest advantages of HA VPN is automatic failover.

Consider the following scenario:

Tunnel 1 : ESTABLISHED
Tunnel 2 : ESTABLISHED
Tunnel 3 : ESTABLISHED
Tunnel 4 : ESTABLISHED

Suddenly, Tunnel 1 becomes unavailable.

Tunnel 1 : DOWN
Tunnel 2 : ESTABLISHED
Tunnel 3 : ESTABLISHED
Tunnel 4 : ESTABLISHED

Instead of disrupting application traffic, Cloud Router and BGP automatically redirect traffic through healthy tunnels.

Users never notice the failure.

Applications continue operating normally.

Dynamic Routing Support

HA VPN integrates directly with Cloud Router and Border Gateway Protocol (BGP).

Rather than manually maintaining routes, networks exchange routing information automatically.

Benefits include:

Automatic route discovery
Automatic route withdrawal
Reduced operational overhead
Faster recovery during failures
Easier scalability

Multiple Tunnel Support

In our implementation, AWS automatically generated four VPN tunnel endpoints.

These four tunnels were mapped to the two interfaces of the HA VPN gateway.

HA VPN Interface 0
    ├── Tunnel 3
    └── Tunnel 4

HA VPN Interface 1
    ├── Tunnel 1
    └── Tunnel 2

This design provides redundancy across both cloud providers.

Enterprise-Grade Resiliency

Enterprise environments cannot tolerate downtime caused by a single network device, tunnel, or endpoint failure.

HA VPN eliminates these risks through:

Redundant interfaces
Multiple VPN tunnels
Dynamic routing
Automated failover
Managed infrastructure

This makes HA VPN a common choice for production-grade multi-cloud architectures.

Cloud Router

While HA VPN establishes encrypted connectivity, it does not make routing decisions by itself.

This responsibility belongs to Cloud Router.

Cloud Router is a fully managed Google Cloud service that dynamically exchanges routing information with external networks using Border Gateway Protocol (BGP).

Think of Cloud Router as the intelligence layer of the VPN architecture.

Without Cloud Router:

AWS
  |
Static Routes
  |
Google Cloud

Every new subnet must be manually configured.

Every network change requires administrative intervention.

Every tunnel failure requires manual route updates.

This approach becomes difficult to manage as environments grow.

With Cloud Router:

AWS
   <---- BGP ---->
Cloud Router

Routes are exchanged dynamically and continuously.

Responsibilities of Cloud Router

Learning AWS Routes

Cloud Router learns routes from AWS through BGP.

In our deployment, AWS advertised:

10.50.0.0/16

This tells Google Cloud:

“Any traffic destined for 10.50.0.0/16 should be sent toward AWS.”

Cloud Router automatically installs this route into Google’s routing tables.

Advertising Google Cloud Routes

Cloud Router also advertises Google Cloud routes back to AWS.

In our deployment:

10.10.0.0/24

was advertised to AWS.

AWS then learns:

“Traffic for 10.10.0.0/24 should be routed through the VPN connection.”

No manual route creation was required.

Detecting Failures

BGP continuously monitors tunnel health.

If a tunnel stops responding:

Tunnel 1 : DOWN

Cloud Router immediately detects the loss of connectivity.

Affected routes are withdrawn from the routing table.

Automatic Traffic Rerouting

After detecting a failure, Cloud Router automatically selects alternative paths.

For example:

Tunnel 1 : DOWN
Tunnel 2 : UP
Tunnel 3 : UP
Tunnel 4 : UP

Traffic automatically shifts to one of the remaining tunnels.

Applications continue operating without interruption.

This process occurs within seconds and requires no administrator intervention.

AWS Customer Gateway

A Customer Gateway is AWS’s representation of the remote VPN device.

In our architecture, the remote VPN device is the Google Cloud HA VPN Gateway.

When AWS establishes a VPN connection, it must know:

Which public IP address to connect to
Which ASN to use for BGP
What type of VPN device exists on the remote side

This information is stored within the Customer Gateway resource.

Why Two Customer Gateways Were Created

Our Google Cloud HA VPN Gateway contained two interfaces:

Interface 0
34.183.57.250

Interface 1
34.184.34.63

AWS therefore required two Customer Gateways.

Customer Gateway 1:

34.183.57.250
ASN 65001

Customer Gateway 2:

34.184.34.63
ASN 65001

Each Customer Gateway points to one HA VPN interface.

This design provides redundancy and enables AWS to build multiple VPN tunnels.

Customer Gateway Responsibilities

AWS uses Customer Gateways to:

Identify remote VPN endpoints
Establish IPSec tunnels
Exchange BGP routing information
Monitor tunnel health
Support automatic failover

Without Customer Gateways, AWS would have no knowledge of Google’s VPN infrastructure.

AWS Virtual Private Gateway

The AWS Virtual Private Gateway (VGW) acts as the VPN termination point within AWS.

Think of it as the AWS equivalent of the Google Cloud HA VPN Gateway.

All VPN tunnels created in AWS ultimately terminate on the Virtual Private Gateway.

Role of the Virtual Private Gateway

The Virtual Private Gateway performs several important functions:

Terminates IPSec Tunnels

Each VPN tunnel created by AWS connects directly to the Virtual Private Gateway.

In our deployment:

Tunnel 1
Tunnel 2
Tunnel 3
Tunnel 4

all terminated on the same VGW.

Exchanges BGP Routes

The Virtual Private Gateway participates in BGP sessions with Cloud Router.

AWS ASN:

Google Cloud ASN:

Through these BGP sessions, both clouds exchange routing information dynamically.

Connects the AWS VPC

The Virtual Private Gateway was attached to:

CymbalAdVpc
10.50.0.0/16

This attachment allows resources inside the AWS VPC to communicate with Google Cloud resources through the VPN.

Provides Redundant Connectivity

Because all VPN tunnels terminate on the Virtual Private Gateway, AWS can continue forwarding traffic through healthy tunnels even when individual tunnels fail.

This ensures:

High availability
Automatic failover
Continuous connectivity
Enterprise-grade resilience

Together, Google Cloud HA VPN, Cloud Router, AWS Customer Gateways, and the AWS Virtual Private Gateway form the foundation of a secure, scalable, and highly available multi-cloud networking architecture capable of supporting real production workloads.terminates AWS VPN connections and exchanges routes through BGP.

Lab Environment Overview

During implementation, the following environment was created:

Google Cloud

VPC:

cymbal-cloud-vpc

Subnet:

10.10.0.0/24

Cloud Router ASN:

AWS

VPC:

10.50.0.0/16

Virtual Private Gateway ASN:

Step 1 – Create Google Cloud Networking

Before we can establish VPN connectivity, Google Cloud requires a network where resources, VPN gateways, and routing components can reside.

A VPN gateway cannot exist independently. It must be attached to a VPC network because the VPN’s purpose is to provide secure connectivity to resources inside that network.

In our architecture:

Google Cloud VPC
CIDR: 10.10.0.0/24

AWS VPC
CIDR: 10.50.0.0/16

Eventually, resources in these two networks will communicate through the VPN tunnels.

Why Are We Creating a Custom VPC?

Google Cloud provides a default VPC, but production environments rarely use it.

Reasons:

Better network isolation
Easier route management
Cleaner security boundaries
Predictable IP addressing
Enterprise network standards

By creating a dedicated VPC, we gain full control over the network design.

Create the custom VPC:

gcloud compute networks create cymbal-cloud-vpc \
--subnet-mode=custom

What Happens Behind the Scenes?

Google Cloud creates:

VPC Name:
cymbal-cloud-vpc

Routing Domain:
Dedicated

Firewall Domain:
Dedicated

No subnets are created automatically because we selected:

--subnet-mode=custom

This allows us to explicitly define our own IP ranges.

Verification

Verify VPC creation:

gcloud compute networks list

Expected:

cymbal-cloud-vpc

Create subnet:

gcloud compute networks subnets create cymbal-cloud-subnet \
--network=cymbal-cloud-vpc \
--region=us-east1 \
--range=10.10.0.0/24

What Happens Behind the Scenes?

Google Cloud reserves:

10.10.0.0 - 10.10.0.255

for resources deployed inside:

us-east1

Later, this route will be advertised to AWS through BGP.

Verification

gcloud compute networks subnets list

Expected:

10.10.0.0/24

Step 2 – Deploy HA VPN Gateway

At this point we have a network but no secure connectivity.

The next component required is a VPN termination point.

Why Are We Creating an HA VPN Gateway?

The VPN gateway is responsible for:

Establishing IPSec tunnels
Encrypting traffic
Decrypting traffic
Maintaining tunnel health

Without a VPN gateway:

AWS ❌ Google Cloud

No communication is possible.

Create HA VPN:

gcloud compute vpn-gateways create \
cymbal-cloud-ha-vpn-gw \
--network=cymbal-cloud-vpc \
--region=us-east1

Verify:

gcloud compute vpn-gateways describe \
cymbal-cloud-ha-vpn-gw \
--region=us-east1

Result:

Interface 0
34.183.xx.xx

Interface 1
34.184.xx.xx

Why HA VPN Instead of Classic VPN?

Traditional VPN:

AWS
 |
Single Tunnel
 |
Google Cloud

Failure:

Tunnel Down
=
Outage

HA VPN:

AWS
 |
Tunnel1
Tunnel2
Tunnel3
Tunnel4
 |
Google Cloud

Failure:

Tunnel1 Down

Traffic continues flowing.

No outage occurs.

Step 3 – Configure Cloud Router

At this stage:

VPN Gateway Exists

But:

No Routing Exists

The VPN can establish tunnels, but it does not know where traffic should go.

This is where Cloud Router becomes essential.

Why Are We Creating Cloud Router?

Cloud Router provides:

Dynamic Routing

using:

BGP
(Border Gateway Protocol)

Without Cloud Router:

AWS
 |
Static Routes
 |
Google Cloud

Every subnet change would require manual route updates.

This becomes operationally expensive.

Create Cloud Router:

gcloud compute routers create \
cymbal-cloud-router \
--network=cymbal-cloud-vpc \
--region=us-east1 \
--asn=65001

Why ASN 65001?

Every BGP router requires a unique Autonomous System Number.

Google Cloud:

ASN 65001

AWS:

ASN 64512

These ASNs identify each routing domain during route exchange.

Step 4 – Configure AWS

Create a VM in AWS:

SSH to VM:

At this stage, the Google Cloud side is ready.

We have already created:

✓ VPC Network
✓ Subnet
✓ HA VPN Gateway
✓ Cloud Router

However, AWS still has no knowledge of Google’s VPN infrastructure.

Before AWS can establish VPN tunnels, we must create components that represent the Google Cloud environment inside AWS.

Understanding What We Are Building

Our target architecture now looks like:

Google Cloud
------------------------
HA VPN Interface 0
34.183.57.250

HA VPN Interface 1
34.184.34.63

      ?
      ?
      ?

AWS
------------------------

Currently AWS does not know:

Where Google Cloud exists
Which public IPs belong to Google Cloud
Which ASN Google Cloud will use
How to establish VPN tunnels

The next AWS resources solve these problems.

Why Are We Configuring AWS CLI?

AWS resources can be created:

AWS Console
AWS CLI
Terraform
CloudFormation

For this lab we use AWS CLI because:

Faster automation
Easier verification
Repeatable deployments

Configure AWS CLI:

aws configure

Verify:

What Happens Behind The Scenes?

AWS CLI stores credentials locally.

~/.aws/credentials

and

~/.aws/config

Every AWS command now authenticates automatically.

No Traffic Can Reach Resources

inside AWS.

List VPCs

aws ec2 describe-vpcs

Expected:

Name: CymbalAdVpc
CIDR: 10.50.0.0/16
VpcId: vpc-xxxxxxxx

What Happens Behind The Scenes?

AWS already contains:

CymbalAdVpc
10.50.0.0/16

This network will later communicate with:

Google Cloud
10.10.0.0/24

through the VPN tunnels.

Create Customer Gateways using the HA VPN public IPs.

Find HA gateway:

Now we must teach AWS where Google Cloud exists.

What Is A Customer Gateway?

A Customer Gateway represents the remote VPN device.

In our architecture:

Remote VPN Device
=
Google Cloud HA VPN Gateway

AWS cannot connect directly to Google Cloud until this object exists.

Think of Customer Gateway as:

AWS Address Book Entry

Google Cloud
IP Address
ASN
VPN Device Type

Why Do We Need Two Customer Gateways?

Earlier, Google Cloud HA VPN created:

Interface 0
34.183.57.250

Interface 1
34.184.34.63

AWS treats these as independent VPN endpoints.

Therefore:

Interface 0
=
Customer Gateway 1

Interface 1
=
Customer Gateway 2

This enables high availability.

Customer Gateway 1

aws ec2 create-customer-gateway \
    --type ipsec.1 \
    --public-ip <GCP_HA_VPN_IP1> \
    --bgp-asn 65001

Verify:

Customer Gateway 2

aws ec2 create-customer-gateway \
    --type ipsec.1 \
    --public-ip <GCP_HA_VPN_IP2> \
    --bgp-asn 65001

Verify:

At this point AWS knows where Google Cloud exists.

However Google Cloud still has nowhere to connect inside AWS.

This is solved by creating a Virtual Private Gateway.

What Is A Virtual Private Gateway?

Think of it as AWS’s VPN termination device.

Google Cloud uses:

HA VPN Gateway

AWS uses:

Virtual Private Gateway

Every VPN tunnel will terminate on this gateway.

Create Virtual Private Gateway.

What Happens Behind The Scenes?

AWS creates:

Virtual Private Gateway
ASN 64512

This gateway becomes AWS’s VPN endpoint.

Verification

aws ec2 describe-vpn-gateways

Expected:

State:
available

onnected To Anything

We must attach it to:

CymbalAdVpc

Why Is This Required?

Without attachment:

AWS Resources
    X
Cannot Reach VPN

The VPN gateway must be connected to the VPC routing domain.

Attach Virtual Private Gateway to the AWS VPC.

What Happens Behind The Scenes?

AWS now links:

10.50.0.0/16

to:

Virtual Private Gateway

Any VPN routes learned later can now reach resources inside the AWS VPC.

Verification

aws ec2 describe-vpn-gateways

Expected:

VpcAttachments:
 State: attached

Step 5 – Create VPN Connections

At this stage AWS knows:

Where Google Cloud exists
What public IP addresses belong to Google Cloud
Which ASN Google Cloud uses
Which AWS VPC requires connectivity

The next step is creating VPN connections.

A VPN Connection is the component that ties together:

Customer Gateway
        +
Virtual Private Gateway

and generates all IPSec configuration information.

Understanding What AWS Creates

Before running any commands, let’s understand what AWS is about to generate.

Many engineers think:

VPN Connection
=
Single Tunnel

This is incorrect.

In AWS:

One VPN Connection
=
Two IPSec Tunnels

Because we created:

Customer Gateway 1
Customer Gateway 2

we will create:

VPN Connection 1
VPN Connection 2

Therefore:

2 VPN Connections
        =
4 IPSec Tunnels

These four tunnels provide the redundancy required for a highly available architecture.

Why Dynamic Routing?

AWS supports two routing models.

Static Routing

AWS
 |
Static Routes
 |
Google Cloud

Every route must be manually configured.

Every network change requires administrator intervention.

Scaling becomes difficult.

Dynamic Routing (BGP)

AWS
    <----BGP---->
Google Cloud

Routes are exchanged automatically.

Benefits:

Automatic route discovery
Automatic failover
Reduced operational overhead
Faster recovery from failures

For production environments, dynamic routing is the preferred approach.

That is why we use:

StaticRoutesOnly=false

Create two Site-to-Site VPN Connections using dynamic routing.

Create VPN 1

aws ec2 create-vpn-connection \
    --type ipsec.1 \
    --customer-gateway-id <CGW1_ID> \
    --vpn-gateway-id <VGW_ID> \
    --options StaticRoutesOnly=false

What Happens Behind The Scenes?

AWS automatically generates:

VPN Connection 1

Inside this VPN connection:

Tunnel A
Tunnel B

For each tunnel AWS creates:

Public tunnel endpoint
Tunnel inside IP addresses
Pre-shared key
BGP configuration

Why Does AWS Create Two Tunnels?

Enterprise networking requires redundancy.

If Tunnel A fails:

Tunnel A
DOWN

Traffic automatically shifts to:

Tunnel B
UP

without application downtime.

VPN 2:

aws ec2 create-vpn-connection \
    --type ipsec.1 \
    --customer-gateway-id <CGW2_ID> \
    --vpn-gateway-id <VGW_ID> \
    --options StaticRoutesOnly=false

Verify:

aws ec2 describe-customer-gateways

aws ec2 describe-vpn-gateways

aws ec2 describe-vpn-connections

Four VPN tunnels
Tunnel outside IP addresses
Pre-shared keys
Tunnel inside IPs
BGP configuration

First, check what AWS created

Run:

aws ec2 describe-vpn-connections

Look for:

VpnConnectionId
CustomerGatewayId
VpnGatewayId
State

The state may be:

pending

available

Both can happen before the tunnels are fully configured.

For each VPN connection, AWS generated:

2 tunnel outside IPs
2 pre-shared keys
2 inside tunnel IP pairs
AWS BGP ASN

Since you created 2 VPN connections, you’ll end up with:

4 outside IPs
4 PSKs
4 inside tunnel networks

Get the configuration

Run:

aws ec2 describe-vpn-connections --output json

aws ec2 describe-vpn-connections > vpn.json

The output contains a field called:

CustomerGatewayConfiguration

which is XML.

Inside you’ll find entries similar to:

<ip_address>52.x.x.x</ip_address>
<pre_shared_key>xxxxx</pre_shared_key>
<bgp>
  <asn>64512</asn>
</bgp>

Step 6 – Create External VPN Gateway in Google Cloud

Represent AWS VPN endpoints inside Google Cloud.

gcloud compute external-vpn-gateways create \
aws-external-vpn-gw \
--interfaces=<AWS Tunnel IPs>

Create External VPN Gateway

Use the 4 AWS outside IPs:

23.22.32.150
32.193.93.252
52.2.4.179
52.21.126.113

These came from the VPN connection details.

gcloud compute external-vpn-gateways create aws-external-vpn-gw \
    --interfaces=0=23.22.32.150,1=32.193.93.252,2=52.2.4.179,3=52.21.126.113 \

Step 7: Get your GCP HA VPN Gateway IPs

Run:

gcloud compute vpn-gateways describe cymbal-cloud-ha-vpn-gw \
    --region=us-east1

You should see 2 interfaces.

Typically:

Interface 0 -> 34.184.34.63
Interface 1 -> 34.183.57.250

These match the customer gateways you created on AWS.

Step 8: Create 4 VPN Tunnels

You will use:

Tunnel	AWS Outside IP	PSK
tunnel1	23.22.32.150	G****************E
tunnel2	32.193.93.252	c****************u
tunnel3	52.2.4.179	F****************M
tunnel4	52.21.126.113	E****************O

Create Tunnel 1

gcloud compute vpn-tunnels create tunnel1 \
    --region=us-east1 \
    --vpn-gateway=cymbal-cloud-ha-vpn-gw \
    --interface=1 \
    --peer-external-gateway=aws-external-vpn-gw \
    --peer-external-gateway-interface=0 \
    --shared-secret="G****************E" \
    --router=cymbal-cloud-router

Create Tunnel 2

gcloud compute vpn-tunnels create tunnel2 \
    --region=us-east1 \
    --vpn-gateway=cymbal-cloud-ha-vpn-gw \
    --interface=1 \
    --peer-external-gateway=aws-external-vpn-gw \
    --peer-external-gateway-interface=1 \
    --shared-secret="c****************u" \
    --router=cymbal-cloud-router

Create Tunnel 3

gcloud compute vpn-tunnels create tunnel3 \
    --region=us-east1 \
    --vpn-gateway=cymbal-cloud-ha-vpn-gw \
    --interface=0 \
    --peer-external-gateway=aws-external-vpn-gw \
    --peer-external-gateway-interface=2 \
    --shared-secret="F****************M" \
    --router=cymbal-cloud-router

Create Tunnel 4

gcloud compute vpn-tunnels create tunnel4 \
    --region=us-east1 \
    --vpn-gateway=cymbal-cloud-ha-vpn-gw \
    --interface=0 \
    --peer-external-gateway=aws-external-vpn-gw \
    --peer-external-gateway-interface=3 \
    --shared-secret="E****************O" \
    --router=cymbal-cloud-router

After all 4 tunnels succeed

Run:

gcloud compute vpn-tunnels list

Step 8: Cloud Router Interfaces

AWS ASN:

GCP ASN:

65001

From your output.

we’ll create four router interfaces and four BGP peers.

Step 9 – Configure Cloud Router Interfaces and BGP peers

Create router interfaces for each tunnel.

Purpose:

Bind tunnel to Cloud Router
Enable BGP communication

Create four BGP peers.

Google Cloud ASN:

AWS ASN:

BGP establishes route exchange between both cloud providers.

Tunnel1 Interface

gcloud compute routers add-interface cymbal-cloud-router \
    --interface-name=if-tunnel1 \
    --vpn-tunnel=tunnel1 \
    --ip-address=169.254.146.206 \
    --mask-length=30 \
    --region=us-east1

BGP Peer:

gcloud compute routers add-bgp-peer cymbal-cloud-router \
    --peer-name=peer1 \
    --interface=if-tunnel1 \
    --peer-ip-address=169.254.146.205 \
    --peer-asn=64512 \
    --region=us-east1

Tunnel2 Interface

gcloud compute routers add-interface cymbal-cloud-router \
    --interface-name=if-tunnel2 \
    --vpn-tunnel=tunnel2 \
    --ip-address=169.254.201.34 \
    --mask-length=30 \
    --region=us-east1

BGP Peer:

gcloud compute routers add-bgp-peer cymbal-cloud-router \
    --peer-name=peer2 \
    --interface=if-tunnel2 \
    --peer-ip-address=169.254.201.33 \
    --peer-asn=64512 \
    --region=us-east1

Tunnel3 Interface

gcloud compute routers add-interface cymbal-cloud-router \
    --interface-name=if-tunnel3 \
    --vpn-tunnel=tunnel3 \
    --ip-address=169.254.76.254 \
    --mask-length=30 \
    --region=us-east1

BGP Peer:

gcloud compute routers add-bgp-peer cymbal-cloud-router \
    --peer-name=peer3 \
    --interface=if-tunnel3 \
    --peer-ip-address=169.254.76.253 \
    --peer-asn=64512 \
    --region=us-east1

Tunnel4 Interface

gcloud compute routers add-interface cymbal-cloud-router \
    --interface-name=if-tunnel4 \
    --vpn-tunnel=tunnel4 \
    --ip-address=169.254.254.42 \
    --mask-length=30 \
    --region=us-east1

BGP Peer:

gcloud compute routers add-bgp-peer cymbal-cloud-router \
    --peer-name=peer4 \
    --interface=if-tunnel4 \
    --peer-ip-address=169.254.254.41 \
    --peer-asn=64512 \
    --region=us-east1

After all 8 commands complete, wait about 1–2 minutes and run:

gcloud compute vpn-tunnels describe tunnel1 \
    --region=us-east1 \
    --format='flattened(status,detailedStatus)'

and

gcloud compute routers get-status cymbal-cloud-router \
    --region=us-east1

Verification and Validation

A VPN deployment is incomplete without validation.

Verify Tunnel Status

gcloud compute vpn-tunnels list

Expected:

ESTABLISHED

for all tunnels.

[Attach Screenshot]

Verify BGP Sessions

gcloud compute routers get-status \
cymbal-cloud-router \
--region us-east1

Expected:

peer1: UP
peer2: UP
peer3: UP
peer4: UP

[Attach Screenshot]

Verify Route Exchange

Learned AWS Routes:

10.50.0.0/16

Advertised Google Cloud Routes:

10.10.0.0/24

[Attach Screenshot]

Real-World Validation

After establishing VPN connectivity, enterprises validate application communication rather than stopping at tunnel health checks.

Consider:

AWS

Customer API

10.50.1.25

Google Cloud

Fraud Detection Service

10.10.0.20

Architecture:

AWS Customer API
        |
      HA VPN
        |
Google Cloud Fraud Engine

Request:

curl http://10.10.0.20:8080/score

Expected Response:

{
  "transaction_id":"TXN-100234",
  "risk_score":12,
  "recommendation":"APPROVE"
}

This confirms successful private communication across clouds.

High Availability Demonstration

One of the biggest advantages of HA VPN is automatic failover.

Normal State:

Tunnel1 ESTABLISHED
Tunnel2 ESTABLISHED
Tunnel3 ESTABLISHED
Tunnel4 ESTABLISHED

If Tunnel1 fails:

Tunnel1 DOWN
Tunnel2 ESTABLISHED
Tunnel3 ESTABLISHED
Tunnel4 ESTABLISHED

Application traffic continues uninterrupted because BGP automatically reroutes traffic through healthy tunnels.

This is why enterprises deploy HA VPN instead of traditional single-tunnel VPNs.

Production Use Cases

Deploy a Real Multi-Cloud Application Across AWS and Google Cloud

This becomes the proof that the VPN is actually carrying application traffic.

The flow becomes:

Part 1
--------
Build HA VPN

Google Cloud <-----> AWS

Part 2
--------
Deploy Application

AWS Frontend
     |
     | VPN
     |
Google Cloud Backend

Part 3
--------
Validate

curl
Application Calls
Failover Test
BGP Verification

Production Validation Environment

AWS

Deploy:

customer-portal

Private IP:

10.50.10.25

Role:

Frontend API

Google Cloud

Deploy:

customer-service

Private IP:

10.10.0.20

Role:

Backend API

Step 1 – Create Backend API on Google Cloud

Create VM:

gcloud compute instances create customer-service \
    --zone=us-east1-b \
    --subnet=cymbal-cloud-subnet \
    --machine-type=e2-micro

Screenshot:

VM creation
Internal IP

SSH

gcloud compute ssh customer-service \
    --zone=us-east1-b

Install Python

sudo apt update

sudo apt install python3-pip -y

pip3 install flask

Screenshot:

Installation completed

Create Application

nano app.py

Paste:

from flask import Flask, jsonify

app = Flask(__name__)

@app.route("/customer/<customer_id>")
def customer(customer_id):

    return jsonify({
        "customer_id": customer_id,
        "name": "Mukesh Sharma",
        "account_type": "Premium",
        "status": "Active",
        "region": "Google Cloud us-east1"
    })

app.run(host="0.0.0.0", port=8080)

Start Application

python3 app.py

Output:

Running on http://0.0.0.0:8080

Screenshot:

Application running

Step 2 – Open Firewall

Create firewall:

gcloud compute firewall-rules create allow-customer-api \
    --network=cymbal-cloud-vpc \
    --allow=tcp:8080 \
    --source-ranges=10.50.0.0/16

Why?

Allow AWS VPC
10.50.0.0/16

to reach

Google Cloud
10.10.0.0/24

Screenshot:

Firewall rule

Step 3 – Validate Backend Locally

Inside GCP VM:

curl localhost:8080/customer/1001

Expected:

{
  "customer_id":"1001",
  "name":"Mukesh Sharma",
  "account_type":"Premium",
  "status":"Active",
  "region":"Google Cloud us-east1"
}

Screenshot:

Successful response

Step 4 – Deploy Frontend Application on AWS

Launch EC2:

customer-portal

VPC:

CymbalAdVpc

Subnet:

10.50.x.x

Screenshot:

EC2 deployment

SSH

ssh ec2-user@<private-ip>

Install Packages

sudo yum update -y

sudo yum install python3 -y

pip3 install flask requests

Create Frontend Application

nano frontend.py

Paste:

from flask import Flask
import requests

app = Flask(__name__)

@app.route("/customer/<customer_id>")
def customer(customer_id):

    response = requests.get(
        f"http://10.10.0.20:8080/customer/{customer_id}"
    )

    return response.text

app.run(host="0.0.0.0", port=5000)

Replace:

10.10.0.20

with actual GCP VM private IP.

Start Frontend

python3 frontend.py

Output:

Running on http://0.0.0.0:5000

Screenshot:

Application started

Step 5 – Validate Cross-Cloud Connectivity

From AWS:

curl http://10.10.0.20:8080/customer/1001

Expected:

{
  "customer_id":"1001",
  "name":"Mukesh Sharma",
  "account_type":"Premium",
  "status":"Active",
  "region":"Google Cloud us-east1"
}

This proves:

AWS
   |
VPN
   |
Google Cloud

works.

Step 6 – Validate Through Frontend

Call frontend:

curl http://localhost:5000/customer/1001

Expected:

{
  "customer_id":"1001",
  "name":"Mukesh Sharma",
  "account_type":"Premium",
  "status":"Active",
  "region":"Google Cloud us-east1"
}

Flow:

User
 |
AWS Frontend
 |
VPN Tunnel
 |
Google Cloud Backend
 |
Response

Step 7 – Verify Routing

Google Cloud:

gcloud compute routers get-status \
cymbal-cloud-router \
--region us-east1

Verify:

Learned Route:
10.50.0.0/16

Screenshot.

AWS:

ip route

Verify:

10.10.0.0/24

Screenshot.

Step 8 – High Availability Validation

Show:

gcloud compute vpn-tunnels list

Expected:

tunnel1 ESTABLISHED
tunnel2 ESTABLISHED
tunnel3 ESTABLISHED
tunnel4 ESTABLISHED

Screenshot.

Step 9 – Simulate Failure

Disable one tunnel.

Example:

gcloud compute vpn-tunnels delete tunnel1 \
  --region us-east1

Wait 30 seconds.

Check:

gcloud compute vpn-tunnels list

Expected:

tunnel1 DOWN
tunnel2 ESTABLISHED
tunnel3 ESTABLISHED
tunnel4 ESTABLISHED

Step 10 – Validate Application Again

From AWS:

curl http://localhost:5000/customer/1001

Expected:

{
  "customer_id":"1001",
  "name":"Mukesh Sharma",
  "account_type":"Premium",
  "status":"Active",
  "region":"Google Cloud us-east1"
}

Application continues working.

No outage.

No manual intervention.

Banking

AWS:

Customer applications

Google Cloud:

Fraud Detection
Risk Analysis

Retail

AWS:

E-commerce platform

Google Cloud:

Recommendation Engine
Vertex AI

Healthcare

AWS:

Patient portal

Google Cloud:

Medical analytics platform

Disaster Recovery

AWS:

Production environment

Google Cloud:

DR environment

Continuous replication occurs through private VPN connectivity.

Mergers and Acquisitions

Organizations operating on different cloud providers can securely integrate systems without immediately migrating workloads.

Key Takeaways

By implementing HA VPN between Google Cloud and AWS, we achieved:

Secure multi-cloud communication

Dynamic route exchange through BGP

Automatic failover

High availability architecture

Reduced dependency on public internet

Enterprise-grade networking design

Foundation for AI, analytics, disaster recovery, and hybrid application architectures

This architecture is widely adopted by enterprises pursuing multi-cloud strategies and provides a robust foundation for secure connectivity between AWS and Google Cloud environments.

GeekyMukesh

How to Build a Highly Available VPN Between AWS and Google Cloud

Introduction

Business Problem

AWS

Google Cloud

Solution Architecture

Understanding the Components

Google Cloud HA VPN

Why HA VPN Instead of Classic VPN?

Benefits of Google Cloud HA VPN

99.99% Service Availability SLA

Automatic Failover

Dynamic Routing Support

Multiple Tunnel Support

Enterprise-Grade Resiliency

Cloud Router

Responsibilities of Cloud Router

Learning AWS Routes

Advertising Google Cloud Routes

Detecting Failures

Automatic Traffic Rerouting

AWS Customer Gateway

Why Two Customer Gateways Were Created

Customer Gateway Responsibilities

AWS Virtual Private Gateway

Role of the Virtual Private Gateway

Terminates IPSec Tunnels

Exchanges BGP Routes

Connects the AWS VPC

Provides Redundant Connectivity

Lab Environment Overview

Google Cloud

AWS

Step 1 – Create Google Cloud Networking

Why Are We Creating a Custom VPC?

What Happens Behind the Scenes?

Verification

What Happens Behind the Scenes?

Verification

Step 2 – Deploy HA VPN Gateway

Why Are We Creating an HA VPN Gateway?

Why HA VPN Instead of Classic VPN?

Step 3 – Configure Cloud Router

Why Are We Creating Cloud Router?

Why ASN 65001?

Step 4 – Configure AWS

Understanding What We Are Building

Why Are We Configuring AWS CLI?

What Happens Behind The Scenes?

List VPCs

What Happens Behind The Scenes?

What Is A Customer Gateway?

Why Do We Need Two Customer Gateways?

Customer Gateway 1

Customer Gateway 2

What Is A Virtual Private Gateway?

What Happens Behind The Scenes?

Verification

Why Is This Required?

What Happens Behind The Scenes?

Verification

Step 5 – Create VPN Connections

Understanding What AWS Creates

Why Dynamic Routing?

Static Routing

Dynamic Routing (BGP)

What Happens Behind The Scenes?

Why Does AWS Create Two Tunnels?

First, check what AWS created

Get the configuration

Step 6 – Create External VPN Gateway in Google Cloud

Create External VPN Gateway

Step 7: Get your GCP HA VPN Gateway IPs

Step 8: Create 4 VPN Tunnels

Create Tunnel 1

Create Tunnel 2

Create Tunnel 3

Create Tunnel 4

After all 4 tunnels succeed