AWS, GCP Cross-Cloud Interconnect GA: Architects’ Decisions Now

After five months in preview, Partner Cross-Cloud Interconnect for AWS with VPC Network Peering in Google Cloud has been Generally Available since 16 April 2026. For enterprise architects, this marks the first Multi-Cloud path natively co-built by two hyperscalers that is ready for production use – without a third-party provider like Megaport or Equinix in the chain. This doesn’t change the fundamental question of why organisations run Multi-Cloud. It changes the execution economics for the next two quarters, because data transfer costs, latency, and sovereignty paths can now be calculated differently than they could in Q4 2025.

RelatedFinOps Maturity Check 2026  /  Platform Engineering 2026 with Backstage and Golden Paths

What’s GA, what stays in Preview, and how Azure is preparing in the background

What is Partner Cross-Cloud Interconnect? Partner Cross-Cloud Interconnect is a network path jointly built by Google Cloud and AWS, in which an AWS Direct Connect Gateway is connected directly to a GCP VPC via a certified partner router. Traffic does not travel over the public internet, and no dedicated colocation agreement with an exchange operator is required. As of April 16, 2026, the variant using VPC Network Peering in Google Cloud is GA; the integration with Network Connectivity Center remains in Preview.

The announcement on December 1, 2025 was a signal. The release on April 16, 2026 is the operational reality. What Google Cloud specifically promotes to GA in the release notes is Partner Cross-Cloud Interconnect for AWS with VPC Network Peering. In practice, this means: an AWS Direct Connect Gateway in your own account can now be connected directly to a GCP VPC via a Google-certified partner network node – without traffic touching the public internet path or requiring a dedicated colocation agreement with an exchange operator.

What is deliberately not yet GA is the integration with Google Cloud Network Connectivity Center. NCC is the service Google uses to map a hub-and-spoke topology across multiple clouds, locations, and VPC boundaries. The NCC spoke variant for Partner Cross-Cloud Interconnect remains in Preview. For teams looking to run a centralized multi-cloud routing layer, this means: production use is realistic at the earliest in Q3 2026, more likely with the autumn GA wave.

The third layer is the open network interoperability specification. In December 2025, AWS and Google jointly published an architecture designed not as a proprietary interconnect protocol but as a blueprint. Microsoft Azure was explicitly named as a candidate to join in 2026. Microsoft has not yet published concrete roadmap dates. For architecture teams, this means: the two-cloud option is now production-ready; the three-cloud option remains strategic planning.

Why Multi-Cloud Networking Is Being Costed Differently Now

The classic argument against productive multi-cloud setups was never the architecture decisions – it was the data transfer pricing between hyperscalers. AWS egress to Google, Google egress to AWS: depending on the region, that runs between around 0.07 euros and around 0.10 euros per GB, and at enterprise volumes in the petabyte range per month, it adds up to significant line items. Partner Cross-Cloud Interconnect changes the billing structure fundamentally. Direct Connect-based traffic runs at reduced egress rates, typically between around 0.02 euros and around 0.04 euros per GB depending on region and commit volume. For a serious data workload running between AWS Analytics and Google BigQuery, that can mean cutting network OpEx in half.

Latency is the second lever that shifts. An AWS-to-GCP path over the public internet sits at 12 to 40 milliseconds round-trip depending on region. With Partner Cross-Cloud Interconnect, that drops to 2 to 8 milliseconds, because packets travel directly between the interconnect routers. For latency-sensitive couplings – for example, between AWS-based transaction systems and Google-based analytics pipelines – this opens the door to architectures that were previously difficult to operate.

The third factor is sovereignty. German and European enterprise customers often run multi-cloud not for architectural reasons but for contractual and compliance ones. BaFin-regulated institutions need demonstrable exit paths; the EU Data Act requires documented portability. Partner Cross-Cloud Interconnect simplifies that documentation, because the network path between the clouds is contractually well-defined and appears in the audit trail of both hyperscalers. The mere existence of a native interconnect between AWS and Google thus becomes a compliance-conversation argument that previously belonged exclusively to third-party solutions.

Five Decisions Enterprise Architects Should Make This Week

The announcement is not straightforward to assess. Not every enterprise architecture benefits immediately. Not every architecture team has the capacity to schedule a re-evaluation. Conversations with DACH architects over the past two weeks point to five concrete decision moments where Partner Cross-Cloud Interconnect changes the underlying calculus.

The first decision concerns existing multi-cloud setups that rely on third-party paths. Organizations currently running production traffic between AWS and GCP via Megaport, Equinix Fabric, or PCCW Console Connect should schedule a technical cost comparison in Q2. The third-party layer often remains justified for organizational reasons – existing contracts, established support processes – but the default assumption has flipped. For new deployments, the native path has become the default. For architecture boards, that means something concrete: every new multi-cloud project now starts with the question of whether Partner Cross-Cloud Interconnect meets the requirement. The third-party option enters the conversation afterward, as a complementary or replacement variant depending on the project’s regulatory and operational context.

The second decision concerns planned data analytics migrations. Teams currently planning a move from AWS Redshift to Google BigQuery – or in the other direction – can now calculate the network component with reliable numbers. Business cases built in Q4 2025 with conservative egress assumptions now have a new baseline. For an approval decision two or three weeks out, this can materially improve the return on capital. This is especially relevant where migration teams have treated the network line item as fixed friction. Once that figure becomes variable, scenarios that were previously sidelined for egress reasons move back into play.

The third decision concerns disaster recovery topologies. Cross-cloud DR was one of the most expensive options through 2025 because the recovery path typically ran over public egress. With native interconnect, an active-active setup between an AWS region and a Google region becomes arithmetically realistic. Teams with existing single-cloud DR setups should at minimum sketch out what cross-cloud DR would look like under the new cost assumptions. That output belongs in the next risk assessment.

The fourth decision concerns AI and ML workloads. Over the past several quarters, Google Cloud has invested heavily in TPU v6 and specialized inference hardware, while AWS has pushed Trainium2 and its own Bedrock integrations. For teams working across both stacks, the network question is not trivial: train models on GCP, run inference on AWS edge. The native interconnect reduces data movement costs far enough that split architectures move from the feasibility zone into the default zone. For ML platform teams, this is the most significant shift of the past twelve months – because the split between training stack and inference stack previously broke down at the network billing stage, not at the architectural concept itself.

The fifth decision concerns governance. In many German enterprise contexts, cross-cloud connectivity was the point where governance and network security jointly said no, because traffic flows between cloud domains were difficult to document. With a native path that appears in both hyperscaler consoles, the documentation burden drops noticeably. Organizations that have already formalized a multi-cloud strategy in policy should update the governance sections in May. For internal audit, the implication is clear: a multi-cloud path that appears in both audit trails is auditable; one routed through a third party requires supplementary evidence. This distinction carried little weight in governance discussions before because there was no alternative. Now there is.

Alongside these five decisions sits a sixth consideration – less operational, more strategic: how does the negotiating position with hyperscalers change when switching between AWS and GCP becomes technically easier? Enterprise buyers renewing cloud contracts over the next twelve months gain an additional argument in pricing discussions, because exit costs are now measurably lower. This won’t land on day one after GA, but it will surface in the next contract round.

What all these decisions have in common: none of them are single-sprint topics. Recalculating egress costs across two cloud accounts typically takes two to three weeks, because telemetry from both sides has to be consolidated. A DR re-evaluation can consume an entire quarter. The bet AWS and Google are placing with the April 16 GA is not adoption in four weeks – it is a shift in default assumptions over two to three quarters. For architecture teams that work proactively, now is the right moment to pressure-test their own assumptions. For teams that operate reactively, pressure from finance and compliance will arrive at the latest by autumn.

Frequently Asked Questions

More from the MBF Media Network

Image source: AI-generated (Juli 2026)