AWS Interconnect just arrived in preview with a first-class bridge to Google Cloud’s Cross‑Cloud Interconnect. Translation: a managed, private, high‑bandwidth link between clouds that you can provision in minutes instead of weeks. If your teams have been juggling Do‑It‑Yourself multicloud—Direct Connect + Partner circuits + VPNs + bespoke routing—this is the first credible step toward turning that spaghetti into a supported product.
Here’s what shipped, why it matters, and exactly how to pilot it without breaking your roadmap.
What actually launched (and when)
On November 30, 2025, AWS announced the preview of AWS Interconnect – multicloud, with Google Cloud as the first launch partner. The integration uses Google’s Cross‑Cloud Interconnect as the counterpart on the Google side and is framed around an open specification and API so other providers can join. AWS says preview is available in select regions (five to start), with additional availability coming as the program matures. Azure support is signposted for later in 2026.
From the Google side, the value prop is straightforward: you can spin up private links from Google Cloud to AWS with an on‑demand model, targeting minutes for end‑to‑end setup. Bandwidth during preview starts at 1 Gbps, with a roadmap to scale up to 100 Gbps at general availability. While preview features rarely carry full SLAs, Google’s Cross‑Cloud Interconnect family advertises enterprise‑grade reliability when GA—expect the joint experience to inherit that posture as the service hardens.
Why this matters: from weeks to minutes, with a managed backbone
Multicloud has always been easy on a slide, hard in a change window. The painful parts aren’t exotic: ordering cross‑connects, mapping VLANs, reconciling BGP policy, and chasing down gray failures between providers. A managed, productized path between AWS and Google changes three things:
First, lead time compresses. Instead of waiting on colocation work orders, you get a console/API flow. Second, you inherit known‑good patterns. The connectivity is designed to work with Amazon VPC constructs like Transit Gateway and Cloud WAN, and with Google’s VPCs and routing—less bespoke glue. Third, bandwidth becomes a feature you dial, not a procurement event, which is especially relevant for AI and data engineering teams moving big artifacts between GPU clusters and analytical stores.
How AWS Interconnect works in practice
Think of it as managed, private peering between your estates. On AWS, you attach Interconnect to the constructs you already use—VPCs, Transit Gateway, or Cloud WAN—so you don’t have to rethink your segmentation strategy. On Google Cloud, you land into VPCs using Cross‑Cloud Interconnect. Under the hood, each provider operates their side of the fabric, with a shared control plane to coordinate provisioning and bandwidth pools. You pick capacity, attach to your network edges, and exchange routes.
Traffic stays off the public internet and gets dedicated capacity with predictable performance. For security folks: this doesn’t remove your responsibility for segmentation, firewalling, and inspection. It does remove a lot of brittle DIY plumbing that’s historically led to change freezes and late‑night pages.
AWS Interconnect for AI pipelines: practical patterns
Where does this help immediately? Anywhere you’re moving large, hot datasets on a schedule—or continuously. A few real‑world patterns we’ve helped teams design:
• Training on one cloud, serving on another. If your model training runs best near certain GPU types but you prefer a different edge or data stack for serving, a private link reduces your batch export/import pressure and shortens the loop for fine‑tunes.
• ETL between analytical backbones. If your warehouse and lakehouse split across providers, your cross‑cloud copy jobs, feature pipelines, and vector index refreshes become saner when you aren’t riding the public internet.
• Low‑friction failover. True active/active is still work, but high‑bandwidth private paths make controlled failover drills less terrifying, especially for stateful systems that need frequent replication.
If you’re planning GPU expansion, pair this with capacity insights from our take on the EC2 P6‑B300 launch. The combination—dedicated inter‑cloud bandwidth and access to newer accelerators—opens up more flexible placement for training and inference clusters.
Costs and the egress question: what changes and what doesn’t
Here’s the thing: a managed private path doesn’t magically zero your egress bill. You still pay for data leaving a provider unless a specific program waives or rebates that traffic, and those carve‑outs vary by region, product, and provider policy. What this new path does change is your architecture bill of materials: fewer colocation contracts, fewer physical cross‑connects, and fewer vendor‑managed routers to patch and babysit. It also changes predictability—bandwidth you can turn up and down without tickets reduces your risk of over‑provisioning.
Use this moment to reevaluate where your egress spend hides. If you’ve been burned by regional NAT sprawl, revisit your design playbook with our guidance on cutting NAT Gateway complexity and costs. Separately, if you’re running services on the edge or in containerized runtimes and want a reality check on compute vs network trade‑offs, our Cloudflare Containers pricing analysis can help you frame the conversation with finance.
People also ask: does it replace Direct Connect, VPNs, or third‑party fabrics?
No. It gives you an additional, managed option that’s easier to stand up and scale, but there are still solid reasons to keep Direct Connect, Partner Interconnect, or site‑to‑site VPNs in your mix. For example, if you’re anchoring into on‑prem and a specific colocation topology you control, those circuits may remain the right tool. The new path shines when the endpoints on both sides are cloud VPCs and you want “minutes to value” plus elastic bandwidth.
Is AWS Interconnect cheaper than building it yourself?
It depends on the baseline. If you’ve already sunk costs into cages, routers, and long‑lived cross‑connects, the benefit is operational speed and resiliency rather than raw dollars. If you’re pre‑build or mid‑migration, you can likely avoid a chunk of CapEx and reduce opaque managed‑router OpEx. Always model: data volumes, expected concurrency, bandwidth tiers, and the distribution of flows (east‑west intra‑cloud vs cross‑cloud). Then apply each provider’s published rates and any committed‑use discounts you hold.
What regions are supported at preview?
AWS notes five regions at launch, with expansion expected. If you’re not in those regions, you can still pilot by anchoring your test VPCs where the preview exists and using your existing backbone to reach those VPCs. That’s not perfect, but it’s enough to validate provisioning flows, routing policies, and automation patterns.
Security and compliance: what changes, what stays on you
Private transport reduces exposure to internet pathologies, but it doesn’t absolve you of segmentation and inspection. Treat the inter‑cloud link like a high‑speed corridor between two cities: you still need border controls. The basics still apply—least‑privilege routing, route‑table scoping, Security Group and firewall enforcement, and explicit policies for which systems are allowed to talk cross‑cloud.
On the compliance side, private connectivity can simplify certain attestations because you’re not transiting the public internet, but data residency, encryption, and audit obligations remain. Expect preview‑phase limits on formal SLAs and certifications; plan your pilots accordingly.
AWS Interconnect: a pilot playbook you can run this week
Here’s a seven‑step plan we’re running with platform teams who want results without risk:
1) Define one concrete use case. Pick something consequential but bounded: nightly feature store syncs, model checkpoints, or a BI data mart refresh.
2) Place test VPCs in supported preview regions. Mirror a slim version of prod network policy (route tables, TGW/Cloud WAN attachments, firewall rules).
3) Provision 1 Gbps to start. Prove the flow, measure, then scale bandwidth. Don’t start at 10 Gbps unless you’ve modeled sustained need.
4) Automate from day one. Capture the whole flow in IaC—CloudFormation/Terraform on AWS, Terraform/gcloud on Google. You’ll want reproducibility for change control.
5) Observe ruthlessly. Enable logs and flow records on both sides. If you’re already building AI telemetry, pair this with ideas from our CloudWatch Generative AI observability playbook to watch agent traffic shape over time.
6) Run a failure game day. Pull the plug on one side’s link, validate failover and alarms, and document Mean Time to Detect/Recover.
7) Do a real cost check. Measure bytes, concurrency, idle time, and link‑up duration. Compare to your current VPN/Direct Connect/colo costs to make a go/no‑go recommendation.
Architecture reference: three patterns worth copying
1) Data pump with controlled choke
Use Transit Gateway on AWS and a dedicated VPC on Google for data movement only. Keep application subnets off the cross‑cloud route tables. You reduce blast radius and make cost tracking cleaner because all cross‑cloud bytes traverse a small, well‑observed segment.
2) Split‑brain ML: train where GPUs are, serve near users
Point the inter‑cloud link at object storage and feature stores to move artifacts and features, not every inference request. Your serving tier stays hot near customers; your training tier scales opportunistically where accelerators are available.
3) Zero‑trust overlay for sensitive systems
Even with private transport, keep service‑to‑service auth at Layer 7. Mutual TLS and workload identity (e.g., SPIFFE‑style identities) give you a second line of defense if someone fat‑fingers a route. Private pipes plus strong identities beat private pipes alone.
Limits and gotchas in preview
• SLAs and quotas: Preview often means soft quotas and evolving support. Don’t move Tier‑1 traffic until GA and until your specific region is covered.
• Asymmetry: Route advertisement and accepted prefixes may have limits; plan subnetting accordingly to avoid prefix explosions.
• Tooling gaps: Expect a few rough edges in metrics, alarms, or per‑flow visibility during preview. Bake this into your runbooks and use direct logs until console dashboards mature.
How does this impact vendor strategy and risk?
Counterintuitive but true: better multicloud pipes can reduce vendor lock‑in and increase reliance on the top providers. That’s fine. Your goal is portability at the architectural seams: data, identity, and networking. A managed, private link lets you put workloads where they perform best and shift when cost/performance moves. It also gives you a cleaner story for regulators and boards asking about resilience after a major outage.
Let’s get practical: a readiness checklist
Before you hit “Create,” make sure you can answer yes to these:
• We have a clear use case with measurable success criteria (throughput, latency, transfer window).
• Our route tables and firewall rules are documented and reviewed for least privilege cross‑cloud.
• Our IaC can stand up and tear down the entire path in a dev account/project.
• We’ve modeled egress and bandwidth costs under best/worst‑case transfer volumes.
• We have observability and synthetic tests for the cross‑cloud path.
• We have a rollback plan and change window approved.
FAQ: quick answers your stakeholders will want
How fast can we set this up?
In preview, the stated goal is minutes end‑to‑end once your prerequisites are in place. Your mileage depends on account/project guardrails and change control, not the physical cross‑connect queue you’ve dealt with in the past.
What bandwidth should we start with?
Start small—1 Gbps proves posture and automation. Turn up only after you validate flow patterns and packet sizes. When GA arrives, expect options up to 100 Gbps for the heavy hitters.
Does this affect our security posture?
Yes—in a good way, if you keep your zero‑trust basics. You’re removing internet exposure and ISP variability. But you still need segmentation, identity, and logging. Treat the link as privileged and protect it accordingly.
Will this eliminate our egress bill?
No. Private ≠ free. What you gain is predictable capacity and usually a simpler cost story than bespoke colo builds. Still, model the traffic; don’t assume savings without a spreadsheet.
What to do next
• Nominate a pilot app and owner. Make it someone who can ship.
• Book two hours with networking and platform leads to walk the pilot playbook.
• Stand up a dev‑only link and measure—throughput, jitter, and transfer window reliability.
• Review costs weekly for the first month and compare to your current approach.
• Decide: expand, hold for GA, or retire if it doesn’t meet the bar.
If you want a second set of eyes on your plan, our team at ByBowu services helps companies build practical multicloud roadmaps. See how we ship for clients in the portfolio, browse more hands‑on guides on the blog, or reach out via contacts to compare notes.
