AWS y Google Cloud: Cross-Cloud Interconnect ya está disponible: lo que los arquitectos empresariales deben decidir ahora

7 Min. de lectura · Actualizado: 21.04.2026

Tras cinco meses en fase de vista previa, Partner Cross-Cloud Interconnect para AWS con VPC Network Peering en Google Cloud está Generally Available desde el 16.04.2026. Para los arquitectos empresariales, esto significa que el primer camino multicloud construido de forma nativa por dos hyperscalers ya puede utilizarse en producción, sin necesidad de un tercero como Megaport o Equinix en la cadena. Esto no cambia la pregunta fundamental de por qué las empresas adoptan multicloud, pero sí altera la economía de ejecución de los próximos dos trimestres, ya que ahora el tráfico de datos, la latencia y los caminos de soberanía pueden calcularse de manera distinta a como se hacía en el Q4 de 2025.

RelacionadoFinOps en el chequeo de madurez 2026  /  Platform Engineering 2026 con Backstage y Golden Paths

Qué es GA, qué sigue en Preview y cómo se prepara Azure en segundo plano

¿Qué es Partner Cross-Cloud Interconnect? Partner Cross-Cloud Interconnect es una ruta de red construida conjuntamente por Google Cloud y AWS, en la que un AWS Direct Connect Gateway se conecta directamente a una VPC de GCP a través de un router certificado por un partner. El tráfico no circula por Internet público y no requiere un contrato de colocación propio con un operador de exchange. Desde el 16.04.2026, la variante con VPC Network Peering en Google Cloud es GA, mientras que la integración con Network Connectivity Center sigue en Preview.

El anuncio del 01.12.2025 fue una señal. La liberación el 16.04.2026 es la realidad operativa. Lo que Google Cloud eleva concretamente a GA en las Release Notes es Partner Cross-Cloud Interconnect para AWS con VPC Network Peering. Esto significa, en la práctica: un AWS Direct Connect Gateway en la propia cuenta puede conectarse ahora directamente a una VPC de GCP a través de un nodo de red certificado por Google, sin que el tráfico pase por la ruta de Internet público ni sea necesario un contrato de colocación propio con un operador de exchange.

Lo que aún no es GA de forma intencionada es la integración con Google Cloud Network Connectivity Center. NCC es el servicio con el que Google implementa una topología hub-and-spoke entre múltiples nubes, ubicaciones y límites de VPC. La variante Spoke de NCC para Partner Cross-Cloud Interconnect sigue en Preview. Para los equipos que deseen operar una capa central de routing multicloud, esto significa que el uso productivo no será realista hasta, como muy pronto, el Q3 2026, y más probablemente con la oleada de GA del otoño.

El tercer nivel es la especificación abierta de interoperabilidad de redes. AWS y Google presentaron conjuntamente en diciembre de 2025 una arquitectura que no está pensada como un protocolo de interconexión propietario, sino como un blueprint. Microsoft Azure fue mencionado explícitamente como candidato a unirse en 2026. Microsoft no ha publicado hasta ahora fechas concretas en su roadmap. Para los equipos de arquitectura, esto significa: la opción de dos nubes ya es productiva, mientras que la opción de tres nubes sigue siendo una planificación estratégica.

Por qué el *networking* multicloud se calcula ahora de otra manera

El argumento clásico en contra de los entornos multicloud productivos no eran las decisiones arquitectónicas, sino los costes de transferencia de datos entre los *hyperscalers*. La salida (*egress*) de AWS a Google o de Google a AWS: según la región, oscila entre 0,08 y 0,12 USD por GB. En volúmenes empresariales de petabytes al mes, la suma se convierte en partidas significativas. *Partner Cross-Cloud Interconnect* cambia estructuralmente la facturación. El tráfico basado en *Direct Connect* se tarifa con precios reducidos de *egress*, normalmente entre 0,02 y 0,05 USD por GB, dependiendo de la región y el volumen comprometido. Para un *workload* de datos serio entre AWS Analytics y Google BigQuery, esto puede suponer una reducción a la mitad de los costes operativos de red (*OpEx*).

La latencia es la segunda palanca que cambia. Una ruta AWS-GCP a través de internet público ronda entre 12 y 40 milisegundos de *round-trip*, según la región. Con *Partner Cross-Cloud Interconnect*, esto se reduce a entre 2 y 8 milisegundos, ya que los paquetes circulan directamente entre los *routers* de interconexión. Para acoplamientos sensibles a la latencia —por ejemplo, entre sistemas transaccionales basados en AWS y *pipelines* de *analytics* en Google—, esto abre la puerta a arquitecturas que antes resultaban operativamente complejas.

El tercer aspecto es la soberanía. Las empresas europeas, especialmente las alemanas, adoptan el multicloud no tanto por razones arquitectónicas, sino por requisitos contractuales y de cumplimiento. Las entidades reguladas por la BaFin necesitan rutas de salida demostrables, y el *EU Data Act* exige portabilidad documentada. *Partner Cross-Cloud Interconnect* simplifica esta documentación, ya que la ruta de red entre las *clouds* está definida contractualmente con claridad y aparece en el *audit trail* de ambos *hyperscalers*. La mera existencia de una interconexión nativa entre AWS y Google se convierte así en un argumento en las conversaciones de cumplimiento, algo que antes correspondía a soluciones de terceros.

Cinco decisiones que los arquitectos empresariales deberían tomar esta semana

El anuncio no es trivial de evaluar. No toda arquitectura empresarial se beneficia de inmediato. No todos los departamentos de arquitectura tienen la capacidad de programar una reevaluación. De las conversaciones con arquitectos del ámbito DACH en las últimas dos semanas, se desprenden cinco momentos decisivos concretos en los que Partner Cross-Cloud Interconnect cambia el modelo de cálculo.

La primera decisión afecta a los entornos multicloud existentes con rutas de terceros. Quienes hoy operan en producción a través de Megaport, Equinix Fabric o PCCW Console Connect entre AWS y GCP, deberían programar una comparación técnica de costes para el segundo trimestre. La capa de terceros sigue siendo relevante por razones organizativas (contratos existentes, procesos de soporte establecidos), pero la suposición por defecto ha cambiado. En nuevas instalaciones, la ruta nativa se ha convertido en la opción predeterminada. Para los comités de arquitectura, esto significa concretamente: cada nuevo proyecto multicloud comienza con la pregunta de si Partner Cross-Cloud Interconnect cumple con los requisitos. Solo después entra en juego la opción de terceros como variante complementaria o sustitutiva, dependiendo del contexto regulatorio y operativo del proyecto.

La segunda decisión afecta a las migraciones planificadas de Data Analytics. Los equipos que están planeando un cambio de AWS Redshift a Google BigQuery, o viceversa, pueden ahora calcular el componente de red con cifras fiables. Los modelos de costes en los business cases, que en el cuarto trimestre de 2025 aún trabajaban con supuestos conservadores de egreso, obtienen una nueva línea base. Para la decisión de aprobación en dos o tres semanas, esto puede mejorar decisivamente el retorno de la inversión. Esto se vuelve especialmente relevante si el equipo de migración ha considerado hasta ahora el coste de red como una fricción fija. Tan pronto como esa cifra se vuelve variable, avanzan escenarios que antes quedaban aparcados por razones de egreso.

«Lo interesante no es la reducción de los costes de egreso, sino lo que se vuelve posible después. Cuando el tráfico cross-cloud deja de ser un dolor económico, surgen arquitecturas viables que antes se evitaban por buenas razones». Lee Sustar, Forrester, en el contexto de la rueda de prensa de Kyndryl, abril de 2026

La tercera decisión afecta a las topologías de recuperación ante desastres. Hasta 2025, la recuperación ante desastres cross-cloud era una de las variantes más caras, ya que la ruta de recuperación solía pasar por egreso público. Con el interconect nativo, una configuración activa-activa entre una región de AWS y una región de Google se vuelve matemáticamente más realista. Los equipos con configuraciones de recuperación ante desastres en una sola nube deberían al menos esbozar un diseño arquitectónico de cómo sería la recuperación cross-cloud bajo los nuevos supuestos de costes. El resultado debe incluirse en la próxima evaluación de riesgos.

La cuarta decisión afecta a las cargas de trabajo de IA y ML. Google Cloud ha apostado en los últimos trimestres por TPU v6 y hardware especializado de inferencia, mientras que AWS lo ha hecho por Trainium2 e integraciones propias con Bedrock. Para los equipos que trabajan en ambos entornos, la cuestión de la red no es trivial: los modelos se entrenan en GCP, pero la inferencia se ejecuta en el edge de AWS. El interconect nativo reduce los costes de movimiento de datos hasta el punto de que estas arquitecturas divididas pasan de la zona de viabilidad a la zona por defecto. Para los equipos de plataformas de ML, este es el cambio más significativo de los últimos doce meses, ya que antes la división entre el stack de entrenamiento y el de inferencia fracasaba por la facturación de la red, no por la idea arquitectónica en sí.

La quinta decisión afecta al ámbito de la gobernanza. La conectividad cross-cloud era, en muchos contextos empresariales alemanes, el punto en el que gobernanza y seguridad de red decían conjuntamente que no, porque el flujo de tráfico entre dominios cloud era difícil de documentar. Con una ruta nativa que aparece en ambas consolas de hyperscaler, el esfuerzo de documentación se reduce notablemente. Quienes ya han plasmado una estrategia multicloud como política, deberían actualizar los apartados de gobernanza en mayo. Para la revisión interna, esto significa: una ruta multicloud que aparece en ambos registros de auditoría es verificable; una ruta gestionada a través de terceros requiere evidencia adicional. Esta distinción tenía poco peso en las conversaciones de gobernanza hasta ahora, porque no había alternativa. Ahora la hay.

Paralelamente a estas cinco decisiones, queda una sexta consideración, menos operativa y más estratégica: ¿cómo cambia la posición negociadora frente a los hyperscalers cuando el cambio entre AWS y GCP se vuelve técnicamente más sencillo? Los compradores empresariales que renegocien sus contratos de cloud en los próximos doce meses tendrán un argumento adicional en las conversaciones de precios, ya que los costes de salida se reducen de manera medible. No es un argumento que surta efecto al día siguiente del lanzamiento general, pero será visible en la próxima ronda de contratos.

Lo que todas estas decisiones tienen en común es que no son temas de un solo sprint. Recalcular los costes de egreso entre dos cuentas cloud suele llevar entre dos y tres semanas, ya que es necesario consolidar la telemetría de ambos lados. Una reevaluación de la recuperación ante desastres puede requerir todo un trimestre. La apuesta que AWS y Google hacen con el lanzamiento general el 16 de abril no es la adopción en cuatro semanas, sino el cambio de los supuestos por defecto en dos o tres trimestres. Para los equipos de arquitectura que trabajan de manera planificada, este es el momento adecuado para revisar sus propias suposiciones. Para los equipos que actúan de manera reactiva, la presión desde los departamentos de finanzas y cumplimiento llegará, a más tardar, en otoño.

Preguntas frecuentes

¿Qué ocurrió exactamente el 16 de abril de 2026 con GA?

Partner Cross-Cloud Interconnect para AWS con VPC Network Peering en Google Cloud. Es la ruta a través de un router certificado de socio desde un AWS Direct Connect Gateway a un GCP-VPC. La integración con Google Network Connectivity Center (NCC) como Spoke sigue en Preview. Para escenarios de dos nubes AWS-GCP, la GA está lista para uso productivo. Para Hub-and-Spoke entre varias nubes, se planea como muy pronto para el tercer trimestre de 2026.

¿Qué reducción de costes es realista?

Para la transferencia de datos pura entre AWS y GCP, típicamente una reducción a la mitad de los costes de salida, dependiendo de la región y el volumen de compromiso. El Egress por Internet público oscila entre 0,08 y 0,12 USD por GB, mientras que el Egress por Direct Connect se reduce a 0,02-0,05 USD por GB. El ahorro real depende del patrón de tráfico. En cargas de análisis con picos, el impacto es mayor; en conexiones de streaming continuas, menor.

¿Siguen siendo relevantes Megaport o Equinix como terceros?

Para configuraciones multi-nube que deben cubrir más que AWS y GCP, sí. Para rutas puras AWS-GCP, el Interconnect nativo se convertirá en la opción por defecto en nuevas instalaciones. Los contratos existentes con Megaport o Equinix, con integración de soporte en curso, suelen seguir siendo útiles, ya que el cambio genera trabajo operativo. No obstante, conviene replantear el cálculo de comparación de costes.

¿Cuándo se incorporará Microsoft Azure?

Microsoft fue mencionado explícitamente en el anuncio conjunto de AWS y Google del 1 de diciembre de 2025 como candidato a unirse a la especificación abierta de interoperabilidad de redes para 2026. Microsoft no ha comunicado hasta ahora fechas concretas en su hoja de ruta. Para arquitecturas de tres nubes con rutas nativas entre hyperscalers, la planificación estratégica es el formato adecuado, no la implementación productiva.

¿Qué cambios concretos implica esto para los equipos de compliance en DACH?

La ruta de red entre AWS y GCP ahora puede documentarse claramente en los registros de auditoría de ambos hyperscalers, sin necesidad de incluir por separado un contrato con un tercero en la recopilación de evidencias. Esto simplifica la presentación de pruebas para auditorías de la BaFin, requisitos de resiliencia DORA o exigencias de portabilidad del EU Data Act. Quienes ya tengan una política multi-nube por escrito deberían actualizar las secciones de red en mayo.

Más del MBF Media Network

Fuente de la imagen de portada: Pexels / Brett Sayles (px:4330787)