Overview of the Joint AWS-Google Cloud Multicloud Networking Solution

Amazon Web Services (AWS) and Google Cloud announced a groundbreaking, jointly engineered multicloud networking solution in late November 2025, currently available in public preview. This service delivers managed, private, high-bandwidth connectivity between the two clouds in minutes, eliminating the weeks or months typically required for traditional circuit provisioning involving telecommunications providers.

The solution integrates two native managed services:

• AWS Interconnect – multicloud (preview stage on AWS).
• Google Cloud Cross-Cloud Interconnect (specifically the Partner Cross-Cloud Interconnect for AWS variant).

Both providers collaborated on a shared physical infrastructure, pre-provisioned capacity pools, and an open interoperability specification. Customers provision private connections entirely through cloud consoles or APIs without manual cross-connects, letters of authorization (LOAs), VLAN configuration, or carrier coordination.

Technical Operation (High-Level)

The providers maintain quad-redundant physical connectivity (two diverse facilities with dual routers on each side) between paired regions (e.g., AWS us-east-1 with Google Cloud us-east4). This pre-built capacity pool enables on-demand allocation.

When a customer requests connectivity:

1. The initiating cloud (AWS Console/CLI or Google Cloud Console/gcloud/SDK) allocates dedicated bandwidth from the shared pool.
2. The system automatically provisions underlying interconnects, VLAN attachments (or equivalent), and Cloud Routers/BNIs.
3. An activation key or transport resource is generated and accepted on the peer cloud.
4. BGP sessions establish automatically using the providers’ Autonomous System Numbers (ASNs).
5. The customer’s VPCs (AWS) or VPC networks (Google Cloud) map to the connection via Transit Gateway, Cloud WAN, or direct attachments.

Traffic flows over private, provider-managed links with MACsec encryption (IEEE 802.1AE) applied hop-by-hop between AWS and Google edge routers. Providers handle MACsec key rotation, certificate management, and continuous health monitoring with proactive failover across the four redundant paths.

The connection appears as a single managed object:

• An “interconnect attachment” on AWS.
• A “transport” resource plus VLAN attachments on Google Cloud.

Customer Benefits and Key Properties

Customers gain:

• Private connectivity — Direct, dedicated bandwidth (typically in 10–100 Gbps increments, scalable on demand) between AWS VPCs/Transit Gateways and Google Cloud VPCs, supporting IPv4/IPv6 private addressing and link-local peering.
• Provisioning speed — Full setup in minutes via console or API from either provider.
• Resiliency — Quad-redundant paths with automatic failover and joint provider monitoring; SLA-backed once generally available.
• Security — MACsec encryption on inter-provider links, private traffic isolation (never traverses public internet), and optional customer-layer encryption (TLS/IPsec).
• Simplicity — No physical infrastructure management, no BGP expertise required for basic setup, unified operations across clouds.
• Open foundation — The interoperability specification is publicly available, enabling other clouds (Azure explicitly on the roadmap) to adopt the same API and provisioning model.

Typical Architecture Patterns Enabled

This solution dramatically simplifies common multicloud designs:

• Active-active or active-standby disaster recovery (e.g., Amazon Aurora or DynamoDB global tables replicating to AlloyDB or Spanner over private links).
• Latency-sensitive workloads spanning clouds (e.g., Vertex AI or SageMaker endpoints calling transactional services in the other cloud with single-digit millisecond latency).
• Unified “cloud WAN” topologies where AWS Cloud WAN or Transit Gateway peers directly with Google Cloud VPCs as if they were additional regions.
• AI/ML pipelines using Gemini or Claude models on Google Cloud with data lakes or training clusters on AWS over guaranteed bandwidth.

From an application team’s perspective, multicloud networking is now a simple API call rather than a multi-month infrastructure project.

Comparison with Traditional Approaches

Traditional multicloud connectivity required:

• Ordering Dedicated Interconnect (Google) or Direct Connect (AWS) circuits from carriers.
• Physical or virtual cross-connects in colocation facilities.
• Manual BGP configuration, VLAN stitching, security reviews, and ongoing circuit monitoring.

Customers owned all complexity, lead times (4–12 weeks), and single points of failure.

The new joint solution shifts everything to a fully managed service: AWS and Google own the physical layer, redundancy, monitoring, encryption, and SLAs. Customers simply select regions and bandwidth.

Answers to Specific Questions

How the open interoperability specification works The specification defines a standardized API contract (create/accept flow with activation keys) and expected behavior for capacity allocation, BGP peering, and health signaling. It builds on standard protocols (BGP, 802.1AE MACsec) but adds coordinated automation between providers. The full spec is open-source on GitHub; any cloud provider can implement the same APIs, enabling the same “minutes-to-connect” experience without bilateral engineering.

Security and encryption measures for cross-cloud links

• Traffic remains entirely private (no public internet exposure).
• MACsec (802.1AE) with 256-bit AES-GCM encryption is applied on every physical link between AWS and Google edge routers.
• Keys are provider-managed with automatic rotation.
• Both providers continuously monitor link health and cryptographic posture.
• Customers can add application-layer encryption or IPsec tunnels if required.

Provisioning dedicated bandwidth between AWS and Google Cloud From AWS Console (recommended during preview):

1. Navigate to AWS Interconnect – multicloud.
2. Select Google Cloud as the target provider.
3. Choose source AWS region, destination Google Cloud region (only paired regions are available), and desired bandwidth.
4. AWS provisions the connection and provides an activation key or direct attachment.
5. Accept/complete on Google Cloud side (Console or gcloud) if initiated from AWS, or vice versa.

From Google Cloud:

1. Create a “transport” resource in a supported region.
2. Specify capacity and AWS as the partner.
3. Accept the resulting attachment in AWS Console.

The entire process typically completes in under 10 minutes.

Architectural Diagram

The following official diagram from Google Cloud illustrates the underlying physical and logical architecture, showing quad-redundant facilities, edge routers, MACsec encryption, and how customer VPCs attach.

This matches the high-level topology described throughout AWS and Google documentation: customer networks attach via managed attachments to provider edge routers, which connect via four diverse, encrypted paths.