On November 30, 2025, AWS and Google announced a jointly engineered path to multicloud networking that most teams can deploy in an afternoon. The new AWS Interconnect multicloud capability connects directly to Google Cloud’s Cross‑Cloud Interconnect, replacing weeks of circuit wrangling with a managed, private link you can provision from a console or API. It lands with resilience baked in, proactive health monitoring, and an open spec the providers say others can adopt. For architects, this isn’t a press‑release moment—it’s an operations moment.
What shipped this week (and what it replaces)
Here’s the thing: multicloud connectivity used to mean colocation contracts, cross‑connect orders, Partner Interconnect paperwork, and careful BGP peering across at least two physical facilities. Lead times were measured in weeks—sometimes months. Now, AWS exposes a managed attachment you create in three steps (choose provider, choose region, choose bandwidth) and Google meets you on the other side with Cross‑Cloud Interconnect. The providers handle physical capacity, redundancy, and lifecycle events. You handle routing policy and segmentation.
Key details to anchor on for planning: the service launched in preview tied to five AWS Regions; provisioning targets minutes; resilience uses physically redundant facilities and routers; and there’s proactive monitoring with coordinated maintenance windows. Salesforce is named as an early adopter, and AWS says a similar connection to Microsoft Azure is planned for 2026. If you run global workloads across AWS and Google today, your migration spreadsheet just got shorter.
DIY colos vs. managed cross‑cloud
When you built this yourself, you paid in three currencies: time (vendor coordination), risk (single‑facility surprises), and toil (BGP and ACLs fragmented across providers). The managed link flips the model. You lose some hand‑tuned flexibility, but you gain interoperable APIs, standardized attachments, and provider‑owned capacity management. In practice, the trade‑off means you ship DR and data movement projects sooner, with fewer in‑house networking heroes on pager duty.
“AWS Interconnect multicloud” architecture you’ll actually deploy
Let’s get practical. You’ve got VPCs on AWS and VPC networks on Google Cloud. You want predictable bandwidth, clear fault domains, and sane routing. Here are the patterns we’re already implementing with customers.
Core building blocks
On AWS: build around Cloud WAN if you have multiple regions and business segments, or Transit Gateway for a simpler hub‑and‑spoke. On Google Cloud: use VPC spokes + Cloud Router behind Cross‑Cloud Interconnect. Keep your attachments per segment (Prod, PCI, R&D) to prevent noisy neighbors and to isolate blast radius.
Routing: advertise the minimum viable prefixes. Use BGP communities or equivalent tagging to keep default routes out of places they don’t belong. Make asymmetric routing a deliberate choice, not an accident.
Security: treat the cross‑cloud link as trusted transport, not an implicit trust zone. Enforce least privilege with security groups/firewalls on both sides and consider a policy layer for east‑west inspection where required by regulation.
Three reference patterns
1) Active/active services across clouds. Put stateless frontends in both clouds; terminate global traffic with anycast DNS or geo‑routing; replicate session state to a neutral store (e.g., Redis on one side with CDC to the other, or a Kafka backbone). The managed link reduces failover jitter and packet loss compared to VPN fallbacks.
2) Warm‑standby DR. Keep the primary in AWS, maintain warm capacity in Google Cloud, and continuously replicate databases using native tools (DMS → Datastream, or Debezium-based CDC). Cutover drills become realistic because link provisioning isn’t your blocker anymore.
3) Data gravity and AI pipelines. Land raw data in the cloud where it’s produced; move only curated features or embeddings cross‑cloud on a schedule. If you train on Vertex AI this quarter but serve on Amazon Bedrock or SageMaker, the link keeps egress predictable and secured without building a colo core.
People also ask
Does this replace Direct Connect or Partner Interconnect?
No. Think of the managed cross‑cloud link as a new lane focused on cloud‑to‑cloud traffic. Direct Connect and Partner Interconnect remain your on‑prem → cloud options. Many enterprises will run both: Direct Connect for datacenter traffic, and the new AWS↔Google link for east‑west traffic between cloud workloads.
How secure is it compared to DIY?
The providers are owning physical capacity and redundancy, with private addressing and control‑plane health checks. You still own identity, encryption at the payload layer, and segmentation. In regulated environments, you’ll layer on inspection or microsegmentation policies the same way you do for any east‑west path.
What about cost?
There’s no vendor‑neutral price sheet to cite yet, but expect three levers: the managed attachment itself (bandwidth‑tiered), data transfer charges that differ by direction and region, and your own architecture choices (active/active doubles some egress). The big savings show up in lead time and staff hours: fewer tickets, fewer weekend cutovers, fewer colos to ride herd on.
Latency and throughput expectations?
Latency depends on region pairing and the provider’s backbone path; throughput is tied to your chosen bandwidth tier and per‑attachment caps. For user‑facing apps, place state close to clients and use the link for replication, not hot path calls.
The 48‑hour rollout checklist
Want to prove value quickly? Here’s a tight plan we’ve used to get a production‑worthy pilot running without drama.
Hour 0–4: Scope and prerequisites
- Pick one AWS region and one Google region with preview support and good latency. Document RTT targets.
- Confirm IP overlap status. If overlap exists, plan translation (NAT/Cloud NAT) at the edge of each segment.
- Decide your control plane: Cloud WAN segments or Transit Gateway route tables; VPC service perimeters on Google for least privilege.
Hour 4–12: Provision the managed link
- Create the AWS Interconnect multicloud attachment, select provider = Google, region, and bandwidth. Tag it by segment.
- On Google Cloud, create Cross‑Cloud Interconnect, attach to a dedicated VPC spoke, and configure Cloud Router/BGP.
- Establish health checks/alerts in both providers; subscribe to maintenance notifications for the attachment.
Hour 12–24: Route only what you need
- Advertise a narrow set of prefixes from each side; verify no default routes leak.
- Stand up test services in both clouds; run continuous pings/iperf and record baseline SLOs.
- Enable DNS failover policies; verify session stickiness or idempotency for cross‑cloud requests.
Hour 24–48: Prove resilience
- Fail link paths intentionally (disable an attachment, withdraw prefixes) and confirm graceful failover.
- Measure recovery time, packet loss during failover, and application error rates; store results in your runbook.
- Write a one‑page executive summary with before/after lead time, expected OpEx deltas, and risk reduction.
Operational gotchas we’ve already seen
Region coverage and quotas. Because the launch is in preview, not every region pair is available. Confirm quotas for attachments, routes, and BGP sessions before you standardize your pattern.
Cross‑cloud SLOs are a team sport. Each provider publishes SLAs, but east‑west paths inherit the weaker link during incidents. Build app‑level retries and idempotency into anything traversing the link.
IP overlap and NAT hairpins. Many enterprises reuse 10.0.0.0/8. If you don’t disentangle now, expect awkward NAT hairpins and troubleshooting funk when TCP handshakes mysteriously die mid‑flow.
DNS is half the battle. Scope your private DNS zones carefully. Don’t let automated resolvers in one cloud inadvertently become a single point of failure for both.
MTU mismatches. Jumbo frames inside VPCs won’t help if your cross‑cloud path clamps MTU. Test for fragmentation and set MSS clamping on the edges.
Policy drift. Over time, route tables, firewall rules, and IAM policies drift in unscripted environments. Treat cross‑cloud as infrastructure as code from day one.
Where the ROI usually lands
Zooming out, the value shows up fast in three places.
Lead‑time compression: moving from multi‑week cross‑connect timelines to same‑day provisioning means projects like DR and data sharing stop slipping quarters.
Ops load: you eliminate colo vendor management, physical capacity planning, and a chunk of bespoke automation. A small platform team can run a larger footprint.
Risk reduction: quad‑redundant facilities and proactive monitoring aren’t a silver bullet, but they make your east‑west backbone less brittle than hand‑rolled VPN mesh or single‑facility interconnects.
How this affects your stack choices
If you’re building AI agents or data pipelines, the new link changes default decisions. Train in the cloud with the best accelerators you can secure this quarter; serve where your apps and customers live. Run Kafka or Pub/Sub bridges for cross‑cloud eventing; keep schemas compatible and idempotent. For application networking, prefer service meshes that tolerate failover across L3 changes or use gateway‑level retries rather than mesh‑wide magic.
For larger programs, consider formalizing a cross‑cloud core team that owns routing policy, DNS, and disaster recovery drills. It’s the fastest way to keep application teams unblocked while you harden the backbone.
What to do next
- Pick a region pair and run the 48‑hour pilot above. Treat it like a DR game day.
- Standardize on Cloud WAN segments (or Transit Gateway tables) mapped one‑to‑one with Google VPC spokes.
- Document IP strategy for the next 24 months. If you must keep overlap, declare translation zones.
- Automate attachments and routing with IaC. No console‑only setups in production.
- Establish SLOs: RTT, packet loss, and recovery time for failovers. Put them on a dashboard.
Want deeper playbooks?
If you’re moving quickly on multicloud, we’ve published related deep dives you can use today. For a soup‑to‑nuts rollout plan, see our deployment playbook for AWS Interconnect multicloud. If you’re focused on Google pairings specifically, read AWS Interconnect with Google: Multicloud, Minus the Pain and our take on the new AWS + Google networking link. And if your multicloud goals include AI agents, our 90‑day plan for Bedrock agents—Amazon Bedrock AgentCore—pairs neatly with this connectivity.
A candid take for execs
Yes, this is a big deal. But it’s not magic. You’ll still pay egress where applicable, you’ll still architect for failure, and you’ll still need disciplined routing and DNS. The difference is that your platform team can now deliver cross‑cloud plumbing at the speed your application teams move. That’s the unlock. Most organizations should pilot now, standardize a reference pattern by Q1, and sunset at least one colo dependency by mid‑2026.
