Connecting two cloud providers is not a theoretical exercise. It is a requirement that appears in every multi-cloud strategy, every gradual migration, and every architecture where teams chose best-of-breed services across providers. The network connection between AWS VPCs and GCP VPCs must handle production traffic, meet latency requirements, and not become a cost surprise.
We have deployed all three approaches described here. Each solved the problem for a specific stage of infrastructure maturity and time. The right choice depends on your bandwidth needs, budget, and how much operational responsibility you want to carry.
Why multi-cloud connectivity matters
The most common scenarios that require cross-cloud networking:
- Gradual migration - moving workloads from AWS to GCP (or reverse) while both environments serve production traffic during the transition period
- Best-of-breed services - running Kubernetes on GKE while using AWS-specific services (RDS, Kinesis, SQS) that have no equivalent on GCP
- Data replication - synchronising databases across clouds for disaster recovery or read replicas in different regions
- Shared services - centralised logging, monitoring, or identity systems that serve workloads on both clouds
- Regulatory requirements - keeping certain data processing in specific regions/providers while other workloads run elsewhere
In every case, the connectivity solution must deliver predictable latency, sufficient bandwidth, and encryption in transit. The difference between approaches is who manages the complexity and what you pay for it.
Generation 1: VM-based VPN (OpenVPN / WireGuard)
This was the standard approach before cloud-native VPN services matured. You run a VPN instance (or pair for HA) in each cloud, configure routing between the VPCs, and manage the tunnels yourself.
How it works
- Deploy a VM in AWS (e.g., t3.medium) with OpenVPN or WireGuard installed
- Deploy a matching VM in GCP (e.g., e2-medium)
- Configure a tunnel between the two public IPs
- Set up route tables in both VPCs to direct cross-cloud traffic through the VPN instances
- Manage failover, monitoring, and certificate rotation yourself
What we used this for
In our earlier projects (2018-2020), this was the go-to approach for connecting small-to-medium workloads between AWS and GCP. Typical use case: a startup with a primary GCP deployment needing access to an AWS-hosted third-party integration. We also used this approach to connect two distant AWS regions before inter-region peering matured.
Advantages
- Full control over encryption, protocol, and configuration
- Works between any two endpoints (cloud-to-cloud, cloud-to-on-premises, cloud-to-colo)
- WireGuard adds minimal latency overhead (~0.5ms per hop)
- Extremely cheap - just the cost of two small VMs plus network traffic
Drawbacks
- Single point of failure unless you deploy HA pairs with keepalived or a similar-class solution
- Bandwidth limited by VM instance type - a t3.medium caps at ~5 Gbps network, and VPN encryption reduces effective throughput to ~2-3 Gbps
- Operational burden - you own patching, monitoring, failover, key rotation, and capacity planning. This is also a potential compliance problem.
- No SLA from the cloud provider - if the tunnel drops, it is your problem to diagnose
- Routing complexity - as the number of subnets grows, route table management becomes error-prone
When it still makes sense
- Dev/test environments where HA is not critical
- Very low bandwidth requirements (<100 Mbps)
- Connecting to providers that don’t offer managed VPN (smaller hosting companies, on-premises labs)
- Budget under $50/month for the connectivity layer
Generation 2: Cloud-native Site-to-Site VPN
Both AWS and GCP offer managed VPN services that eliminate the VM management burden while keeping costs reasonable.
AWS Site-to-Site VPN + GCP Cloud VPN (HA)
The standard pattern:
- Create a Virtual Private Gateway (or Transit Gateway) on AWS
- Create an HA Cloud VPN Gateway on GCP
- Configure two tunnels per connection (AWS requires this for high SLA coverage)
- BGP-based routing automatically handles failover between tunnels
Each tunnel uses IPsec and provides up to 1.25 Gbps. With two tunnels in active/active configuration, you get ~2.5 Gbps aggregate. For higher bandwidth, you can create multiple VPN connections (up to 4, giving ~10 Gbps theoretical maximum).
What we deployed
From 2020 onwards, this became our default for production multi-cloud connections. We typically deployed:
- 2x VPN tunnels (AWS to GCP) for HA
- BGP with dynamic routing for automatic failover
- Private IP addressing with non-overlapping CIDR blocks
- CloudWatch + GCP Cloud Monitoring alarms on tunnel status
Advantages
- Managed by cloud providers - no VMs to patch, no keys to rotate manually
- Built-in HA - dual tunnels with automatic failover
- BGP routing - dynamic route propagation, no manual route table updates
- SLA-backed - AWS VPN SLA covers 99.95% uptime per tunnel
- Encryption by default - IPsec with AES-256-GCM
Drawbacks
- 1.25 Gbps per tunnel cap - if you need more, you add parallel connections which adds complexity
- IPsec overhead - ~10-15% bandwidth reduction from encryption/encapsulation
- Latency - adds ~2-5ms over the underlying internet path due to encryption processing
- Cost scales with data transfer - AWS charges $0.05/GB for data out through VPN; at 10 TB/month that is $500 just for egress
- Occasional tunnel flaps - IKE rekeying can cause brief interruptions that disrupt stateful connections
Cost breakdown
| Component | Monthly cost |
|---|---|
| AWS VPN connection (2 tunnels) | ~$73 |
| GCP Cloud VPN gateway + tunnels | ~$73 |
| AWS data transfer out (1 TB) | ~$50 |
| GCP egress (1 TB, same continent) | ~$20 |
| Total (1 TB/month transfer) | ~$216 |
Generation 3: Managed Cross-Cloud Interconnect
In 2024-2025, both AWS and Google launched managed services specifically for multi-cloud connectivity at Layer 3:
- Google Cloud Cross-Cloud Interconnect - a dedicated connection from GCP to AWS (or Azure/Oracle) with guaranteed bandwidth and Google’s SLA
- AWS Interconnect Multicloud - AWS’s equivalent, providing dedicated connectivity between AWS and other cloud providers
These services eliminate IPsec entirely. Traffic flows over dedicated infrastructure managed by the provider, encrypted at the network layer, with guaranteed bandwidth up to 100 Gbps.
How it works
- You request a Cross-Cloud Interconnect connection (e.g., 10 Gbps) through the GCP or AWS console
- The provider provisions a dedicated path between their network and the partner cloud
- BGP peering is established between your VPC routers on both sides
- Traffic flows at Layer 3 without IPsec encapsulation - the connection itself is physically private
No VMs, no IPsec overhead, no tunnel management. You get a pipe between VPCs with guaranteed bandwidth.
Google Cloud Cross-Cloud Interconnect specifics
- Available in 10 Gbps and 100 Gbps capacities
- Supports connections to AWS, Azure, and Oracle Cloud
- Uses Google’s global network backbone for transport
- BGP-based routing with support for multiple VLAN attachments
- 99.99% SLA (with redundant connections)
- Available in specific metro locations (check availability per region pair)
AWS Interconnect Multicloud specifics
- Dedicated connectivity between AWS and GCP/Azure
- Layer 3 managed service with BGP routing
- No IPsec overhead - traffic is isolated at the physical/link layer
- Integrates with AWS Transit Gateway for hub-and-spoke architectures
- Available through AWS Direct Connect locations
Advantages
- No encryption overhead - traffic is physically isolated, no IPsec processing penalty
- Guaranteed bandwidth - 10 Gbps or 100 Gbps dedicated capacity, not shared
- Sub-millisecond latency addition - no encryption/decryption processing delay
- SLA-backed - 99.99% with dual connections
- Zero tunnel management - no rekeying, no tunnel flaps, no IKE negotiations
- Massive scale - 100 Gbps single connection vs. juggling ten 1.25 Gbps VPN tunnels
Drawbacks
- Cost - starts at ~$1,500-3,000/month for 10 Gbps (before data transfer)
- Location constraints - not available in all region pairs; requires specific metro colocation
- Provisioning time - days to weeks, not minutes like VPN
- Overkill for small workloads - if you transfer 100 GB/month, VPN is dramatically cheaper
- Minimum commitment - typically requires annual commitment for best pricing
Comparison table
| Aspect | VM-based VPN | Cloud-native Site-to-Site VPN | Managed Cross-Cloud Interconnect |
|---|---|---|---|
| Max bandwidth | 2-5 Gbps (VM limited) | 1.25 Gbps/tunnel, ~10 Gbps with 4 connections | 10-100 Gbps dedicated |
| Latency overhead | ~0.5-1ms (WireGuard) | ~2-5ms (IPsec) | <0.5ms (no encryption processing) |
| Encryption | WireGuard/OpenVPN (you manage) | IPsec AES-256 (managed) | Physical isolation (no IPsec needed) |
| HA/failover | Manual (keepalived, scripts) | Automatic (dual tunnels, BGP) | Automatic (redundant connections) |
| SLA | None | 99.95% per tunnel | 99.99% with redundancy |
| Setup time | Hours | Minutes | Days to weeks |
| Monthly cost (1 TB transfer) | ~$30-50 (VM costs) | ~$216 | ~$1,700-3,200 |
| Monthly cost (50 TB transfer) | ~$50 + egress | ~$2,700 | ~$2,000-3,500 |
| Operational burden | High (you manage everything) | Low (provider manages tunnels) | Minimal (fully managed) |
| Best for | Dev/test, low budget, custom protocols | Production workloads <10 Gbps | High-bandwidth, latency-sensitive production |
Decision framework
Choose your connectivity approach based on these questions:
How much bandwidth do you actually need?
- Under 1 Gbps - Site-to-Site VPN is sufficient and cost-effective
- 1-10 Gbps - Site-to-Site VPN with multiple connections, or consider interconnect if latency matters
- Over 10 Gbps - Managed Cross-Cloud Interconnect is the only practical option
What is your latency budget?
- If sub-5ms matters (real-time data sync, transaction processing) - Managed Interconnect
- If 5-15ms is acceptable (batch processing, async replication) - Site-to-Site VPN
How long will the connection exist?
- Temporary (migration, 3-6 months) - Site-to-Site VPN; don’t commit to interconnect for short time periods
- Permanent (multi-cloud architecture) - Managed Interconnect, the long-term cost per GB is lower over time at scale
What is your team’s operational capacity?
- Lean team, no dedicated network engineers - Managed Interconnect or Site-to-Site VPN
- Network engineering expertise available - VM-based VPN is viable if budget is tight
Our experience across three generations
At Devopsity, we have deployed all three approaches in production:
VM-based VPN (2018-2020): WireGuard tunnels connecting GCP workloads to AWS-hosted payment processors. Cheap and effective for a startup budget, but the operational burden grew as the team scaled. We spent more time debugging tunnel issues than building product features.
Site-to-Site VPN (2020-2024): Dual-tunnel HA connections between AWS VPCs and GCP VPCs for fintech clients running split workloads. Reliable, manageable, but we hit the 1.25 Gbps ceiling during peak data replication windows. The solution was adding parallel connections - which worked but added routing complexity.
Managed Cross-Cloud Interconnect (2024-present): For clients with high-bandwidth requirements (database replication, ML training data pipelines between clouds), the managed interconnect eliminated the “how many VPN tunnels do we need?” problem entirely. The cost is higher, but the operational simplicity and guaranteed bandwidth justify it for production-critical paths.
The pattern we see: most organisations start with Site-to-Site VPN and graduate to Managed Interconnect when their cross-cloud traffic exceeds 5-10 Gbps consistently or when they need latency guarantees for real-time workloads.
Planning multi-cloud connectivity?
Book a free 30-minute call. We will discuss your bandwidth requirements, latency constraints, and recommend the right approach for your architecture.
Frequently asked questions
Can I use Google Cross-Cloud Interconnect and AWS Site-to-Site VPN together?
Yes. A common pattern is using Managed Interconnect for the primary high-bandwidth path and keeping a Site-to-Site VPN as a backup. BGP route preferences handle the failover automatically - traffic uses the interconnect when available and falls back to VPN if the interconnect goes down.
How does data transfer pricing work with Cross-Cloud Interconnect?
You pay for the interconnect port (fixed monthly fee based on capacity) plus data transfer charges. The data transfer rate is typically lower than internet egress - Google charges reduced egress rates for traffic going through interconnect. At high volumes (10+ TB/month), the per-GB cost is significantly lower than VPN egress.
Is IPsec encryption still needed with Managed Interconnect?
Not strictly, since the connection is physically isolated. However, some compliance frameworks (PCI DSS, certain HIPAA interpretations) require encryption regardless of physical isolation. You can add application-layer TLS or a lightweight encryption overlay if compliance demands it, without the full IPsec tunnel overhead.
Can I connect AWS and GCP through Azure?
Technically yes (Azure as a transit hub), but this adds latency, cost, and complexity. The direct AWS-GCP interconnect services are purpose-built for this. Use Azure as a transit only if you already have a hub-and-spoke architecture with Azure at the centre.
What happens to my existing VPN when I add a Managed Interconnect?
Keep it as a failover path. Configure BGP route preferences so traffic prefers the interconnect (lower MED or higher local preference). The VPN tunnels remain active but carry no traffic unless the interconnect fails. This gives you a redundancy layer with minimal additional cost.
