Multi-cloud Architecture is a smarter way to utilize public, private and hybrid environment. All enterprises wanted to have an option to choose multiple cloud providers for their usecases. Multi-cloud is now a days very popular for Enterprise and mid level companies. Following are benefits and considerations for selecting any multi-cloud environment.
Redundancy: Having more than one cloud provider, helps in redundancy. In case, if particular region for given cloud provider fails or any service fails we can configure redundancy by adding another cloud provider.
Scalability: This point may be not be that important but definitely worth to consider. Sometime, its lengthy process to increase resource limit for cloud account that can be safeguarded via having multiple cloud provider.
Cost: Cost can also be viewed at competition. Some of the services are cheaper on one cloud environment some or on another. This helps determine cheapest solution for enterprise.
Features: This is prime reason for multi-cloud environment. Having multicloud environment gives you flexibility to choose best suitable environment as per application needed than just to choose whatever is available at the time.
Customer Lock-in: Some of vendors have lock-in period for specific service. Enterprises always\rather mostly wish to avoid this lock-in time. Having multiple cloud we have more option on choosing correct vendor.
Nearest termination point/Customer Reach : Use of regional cloud provider will help enterprise to be near datacenter or user. This will improve performance and reduce latency issues. On top of that, each cloud provider’s global reach is different. So implement appropriate cloud provider whose reach is better for end user.
This procedure can be implemented for any vpn connection with BGP protocol. I am using Dynamic routing but static routing can be used as well. Below is architecture diagram for my VPN connectivity.

Pre-Requisites
Download Terraform software version
- Terraform v0.12.26
- provider.aws v2.70.0
- provider.google v3.0.0-beta.1
AWS and Google account should be configured for terraform access.
I am using “us-west-2” region for AWS, “us-west1” region for google. If you are planning to use different region select appropriate instance image id and update image id
Create EC2 instance keypair and add keypairname inforamtion into parameterstore.
Change BGP IPs. I am using default one, these IPs should work in case those are not used for your existing environment.
Source Code
Please download all files from below location:
https://github.com/yogeshagrawal11/cloud/tree/master/google/Network
Implementation
Follow my Terraform initial setup guide in case new for terrform.
https://cloudtechsavvy.com/2020/09/20/terraform-initial-setup/
- Download “aws_vpn.tf” and “google_vpn”
- Run “./terraform init” to initialize Terraform setup
- Run “./terraform plan” to verify connectivity to cloud and check for error
- Execute “./terraform apply –auto-approve” to start implementation
Output for terraform. Take a note of IP address which will be used in later part for configuration.

IPSec Sharekey
I am using AWS parameter store to store password for VPN tunnels. Two parameters will be used. I am not encrypting this key but its advisable to encrypt those key as per security best practice.

Take a note of value from both “vpn_sharedkey_aws_to_gcp_tunnel1” and “vpn_sharedkey_aws_to_gcp_tunnel2” parameter. These values will be used while creating IPSec tunnel.

AWS & GCP network configuration
VPC with CIDR 10.1.0.0/16 created. Route table attached.

GCP VPC configuration. Subnet is attached.

GCP firewall allows traffic from AWS subnet to GCP subnet

Customer Gateway should have ip address from GCP VPN gateway(not AWS VPN gateway address). This ASN should be with range from 64496 till 65534. ASN used in AWS customer gateway is managed by GCP
AWS Customer Gateway Config = GCP VPN Gateway config

GCP VPN gateway ip information is matching with customer gateway. Forwarding rules are mandatory for tunnel creation. Terraform will create those rules automatically.

AWS Private Gateway will have next ASN no. Its advisable to use next number. I always follow best practice, to use Odd no for certain provider like GCP and even no for certain provider like AWS. This configuration will also works with on-premise network device in that you will define precedence. All on-premise devices will have lower ASN number and so on.

Attach your Site-to-site VPN connection with Virtual private gateway and Customer gateway. This will create one vpn connection with Customer Gateway(GCP VPN Gateway) and AWS Virtual private gateway. I am using “ipsec.1” for connection type.

This will also create two tunnel. I am using dynamic routing. BGP protocols have limitation for 100 subnet that can be exchanged between vpn when this blog is posted. Tunnel information as follows –

Tunnel IP address issue
Tunnels are configured properly but in down stage because corresponding GCP tunnels are not created. I tried to create those tunnel using Terraform but issue is happening that both AWS and GCP were taking own ip as first ip(169.254.1.9) from 169.254.1.8/30 subnet. And second ip will be allocated as peer ip(169.254.1.10). On contrary, we have AWS ip as first ip and second ip in subnet should be used by GCP cloud router.
Correct BGP IP for GCPs are
- Tunnel 1 – Cloud router ip 169.254.1.10(second ip in subnet) and BGP peer ip(from AWS) = 169.254.1.9(which is correctly configured)
- Tunnel 2 – Cloud router ip 169.254.1.14(second ip in subnet) and BGP peer ip(from AWS) = 169.254.1.13(which is correctly configured)
Create Tunnels in GCP
Now create two tunnels in GCP VPN gateway tunnel with following configuration –
- Remote Peer IP address : 35.161.67.220 Value from Terrform output “aws_tunnel1_public_address“
- IKE Verion = 1
- IKE pre-shared key = Copy value from “vpn_sharedkey_aws_to_gcp_tunnel1” parameter from AWS parameter store. Note. Do not copy trailing spaces.
- Cloud Router = gcp-cloud-router
- BGP session Information –
- bgp name = bgp1
- peer ASN = 65002
- Cloud router BGP IP = 169.254.1.10 value of “aws_tunnel1_inside_gcp_address” from terraform output
- BGP peer IP = 169.254.1.9 value of “aws_tunnel1_inside_aws_address” from terraform output


Perform same activity on tunnel-dynamic2 with following details –
- Remote Peer IP address : 35.163.174.84 Value from Terrform output “aws_tunnel2_public_address“
- IKE Verion = 1
- IKE pre-shared key = Copy value from “vpn_sharedkey_aws_to_gcp_tunnel2” parameter from AWS parameter store. Note. Do not copy trailing spaces.
- Cloud Router = gcp-cloud-router
- BGP session Information –
- bgp name = bgp2
- peer ASN = 65002
- Cloud router BGP IP = 169.254.1.14 value of “aws_tunnel2_inside_gcp_address” from terraform output
- BGP peer IP = 169.254.1.13 value of “aws_tunnel2_inside_aws_address” from terraform output
upon changing this configuration both tunnel should be ip and running at GCP and AWS environment. Try refreshing page in case status is not changed


This completed our network connectivity between AWS and GCP environment.
Testing
To test, I am going to login to my AWS instance with my keyname that is defined in “parameterstore”. Use following ip from terraform output


We have allowed ICMP protocol for ping and “ssh” port from AWS environment to GCP environment so will test try to ping GCP instance’s private ip instance from AWS private ip address.

Voila. I could not login to GCP because I have not copied instance json file to EC2 so that ssh will be correctly authenticated.
GCP instance access on external IP

Ping test from AWS EC2 over GCP public instance IP is failed as expected because of two reason, we dont have internet gateway setup on GCP VPC secondly we have not allowed ICMP and ssh in firewall from external world.

Test is successful.
Deletion of environment
Since we created GCP tunnel separately, we need to delete those tunnel before deleting infrastructure using terraform
Go to GCP > VPN > Cloud VPN Tunnels
Select both newly created tunnels and click “Delete”

Once tunnel is deleted, Run following command from Terraform environment –
./terraform destroy –auto-approve

Make sure all 25 resources are deleted.
Conclusion
Multi cloud is new normal and private network connectivity that everyone wanted to have. I have given example of compute instances but this can be extended with multi level architecture. Try to get best of both world by implementing this solution.