AWS y GCP:Cross-Cloud Interconnect disponible:arquitectosdecidan
Tras cinco meses de versión preliminar, el Partner Cross-Cloud Interconnect entre AWS y Google Cloud está disponible generalmente desde el 16.04.2026. Los arquitectos empresariales están recalculando ahora los caminos multi-nube.
Después de cinco meses en preview, Partner Cross-Cloud Interconnect para AWS con VPC Network Peering en Google Cloud está disponible de forma general desde el 16.04.2026. Para los arquitectos empresariales, este es el primer camino multi-cloud construido de forma nativa por dos proveedores de hyperscale y listo para producción, sin que un proveedor tercero como Megaport o Equinix esté en la cadena. Esto no cambia la cuestión fundamental de por qué las empresas operan en multi-cloud. Cambia la economía de ejecución de los próximos dos trimestres, porque la transferencia de datos, la latencia y los caminos de soberanía ahora se pueden calcular de manera diferente a como se hacía en el cuarto trimestre de 2025.
Lo más importante en resumen
- Disponible desde el 16 de abril de 2026. Partner Cross-Cloud Interconnect para AWS con VPC Network Peering está listo para producción en Google Cloud. El camino a través de AWS Direct Connect más Transit Gateway a un VPC de GCP funciona ahora sin una capa de proveedor tercero.
- La integración de NCC sigue en preview. Network Connectivity Center con Partner Cross-Cloud Interconnect aún no está disponible de forma general. Quien desee agregar Hub-and-Spoke a través de varias cuentas de cloud, planea un uso productivo a partir del tercer trimestre de 2026.
- El 84 por ciento opera multi-cloud de forma intencionada. El informe Kyndryl Cloud Readiness Report 2025 muestra que las estrategias multi-cloud intencionadas son mainstream. La cuestión en 2026 ya no es si se utiliza multi-cloud, sino cuánto cuesta el camino entre las clouds.
- Azure anunció su participación para 2026. La especificación abierta de interoperabilidad de red, presentada conjuntamente por AWS y Google en diciembre de 2025, se espera que Microsoft se una más adelante en el año. Las arquitecturas de tres clouds con conexión nativa entre hyperscalers están a la vista.
RelacionadoFinOps en el Maturity-Check 2026 / Platform Engineering 2026 con Backstage y Golden Paths
Qué es GA, qué permanece 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 una puerta de enlace AWS Direct Connect se conecta directamente a una VPC de GCP a través de un enrutador de socio certificado. El tráfico no pasa por Internet público y no requiere un contrato de colocación propio con un operador de intercambio. Desde el 16.04.2026, la variante con VPC Network Peering en Google Cloud está en GA, y la integración con Network Connectivity Center permanece en Preview.
El anuncio del 01.12.2025 fue una señal. La liberación del 16.04.2026 es la realidad operativa. Lo que Google Cloud eleva concretamente a GA en las notas de lanzamiento es Partner Cross-Cloud Interconnect para AWS con VPC Network Peering. Esto significa en la práctica: una puerta de enlace AWS Direct Connect en la propia cuenta ahora puede conectarse directamente a una VPC de GCP a través de un nodo de red de socio certificado por Google, sin que el tráfico toque el camino de Internet público o sea necesario un contrato de colocación propio con un operador de intercambio.
Lo que deliberadamente aún no es GA es la integración con Google Cloud Network Connectivity Center. NCC es el servicio con el que Google representa una topología hub-and-spoke a través de múltiples nubes, ubicaciones y límites de VPC. La variante NCC-Spoke para Partner Cross-Cloud Interconnect permanece en Preview. Para los equipos que desean operar un nivel de enrutamiento multi-cloud central, esto significa: el uso productivo es realista a partir del tercer trimestre de 2026, probablemente con la ola GA de otoño.
El tercer nivel es la especificación abierta de interoperabilidad de red. 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 plan. Microsoft Azure fue mencionado explícitamente como candidato para unirse en 2026. Microsoft aún no ha publicado datos concretos de la hoja de ruta. Para los equipos de arquitectura, esto significa: la opción de dos nubes es ahora productiva, la opción de tres nubes sigue siendo planificación estratégica.
Por qué se calcula de manera diferente el networking de Multi-Cloud ahora
La razón clásica en contra de los setups productivos de Multi-Cloud no eran las decisiones de arquitectura, sino los precios de transferencia de datos entre los hyperscalers. Egress de AWS a Google, Egress de Google a AWS: dependiendo de la región, esto oscila entre alrededor de 0,07 y 0,10 de euros por GB, y con volúmenes de empresa en el rango de petabytes por mes, esto se traduce en partidas significativas. Partner Cross-Cloud Interconnect cambia la facturación estructuralmente. El tráfico basado en Direct Connect se ejecuta a tasas de Egress reducidas, típicamente entre alrededor de 0,02 y 0,04 de euros por GB según la región y el volumen comprometido. Para una carga de trabajo de datos seria entre Analytics de AWS y BigQuery de Google, esto puede significar una reducción a la mitad de los OpEx de red.
Factores de coste antes de GA
- Ruta de Egress pública: alrededor de 0,07 – 0,10 de euros/GB
- Contrato de colocation propio (Equinix/Megaport)
- Facturación separada en AWS y Google
- Gestión manual de sesiones BGP
Qué se recalcula con GA
- Egress de Direct Connect: alrededor de 0,02 – 0,04 de euros/GB
- Integración nativa BGP de ambos hyperscalers
- Red de partners como paso a través, sin contrato
- Activación con un clic según el proveedor
La latencia es el segundo factor que se desplaza. Una ruta de AWS a GCP a través de Internet público se encuentra entre 12 y 40 milisegundos de Round-Trip, dependiendo de la región. Con Partner Cross-Cloud Interconnect, esto se reduce a 2-8 milisegundos, porque los paquetes se transmiten directamente entre los routers de Interconnect. Para acoplamientos sensibles a la latencia, por ejemplo, entre sistemas de transacciones basados en AWS y pipelines de Analytics basados en Google, esto abre la puerta a arquitecturas que antes eran difíciles de operar.
El tercer punto es la soberanía. Los clientes empresariales alemanes y europeos a menudo implementan Multi-Cloud no por razones de arquitectura, sino por razones contractuales y de cumplimiento. Los institutos regulados por BaFin necesitan rutas de salida demostrables, y la Ley de Datos de la UE exige portabilidad documentada. Partner Cross-Cloud Interconnect simplifica esta documentación, porque la ruta de red entre las nubes está claramente definida contractualmente y aparece en el registro de auditoría de ambos hyperscalers. La mera existencia de un Interconnect nativo entre AWS y Google es así un argumento en conversaciones de cumplimiento que antes pertenecía a una solución de terceros.
Cinco decisiones que los arquitectos empresariales deberían tomar esta semana
El anuncio no es trivial de evaluar. No todas las arquitecturas empresariales se benefician de inmediato. No todos los departamentos de arquitectura tienen la capacidad de realizar una reevaluación. De las conversaciones con arquitectos de DACH en las últimas dos semanas, se cristalizan cinco momentos de decisión concretos en los que Partner Cross-Cloud Interconnect cambia el modelo de cálculo.
La primera decisión afecta a los setups multi-cloud existentes con ruta de terceros. Quien actualmente opera de manera productiva a través de Megaport, Equinix Fabric o PCCW Console Connect entre AWS y GCP debería realizar una comparación de costos técnicos en el segundo trimestre. La capa de terceros a menudo sigue siendo útil por razones organizativas (contratos existentes, procesos de soporte establecidos), pero la suposición predeterminada cambia. En nuevas instalaciones, la ruta nativa se ha convertido en la opción predeterminada. Para los consejos de arquitectura, esto significa concretamente: cada nuevo proyecto multi-cloud comienza con la pregunta de si Partner Cross-Cloud Interconnect cumple con el requisito. Solo entonces entra en juego la opción de terceros como variante complementaria o sustitutiva, según el contexto regulatorio y operativo del proyecto.
La segunda decisión afecta a las migraciones planificadas de análisis de datos. Los equipos que actualmente planean cambiar de AWS Redshift a Google BigQuery o viceversa pueden calcular ahora el componente de red con cifras fiables. Los modelos de costos en los casos de negocio que en el Q4 2025 aún tenían que trabajar con suposiciones conservadoras de salida (egress) obtienen una nueva base. Para la decisión de aprobación en dos o tres semanas, esto puede mejorar significativamente la rentabilidad del capital. Esto es especialmente relevante si el equipo de migración ha considerado hasta ahora el componente de red como una fricción fija. Tan pronto como el número se vuelve flexible, los escenarios que antes estaban en segundo plano debido a razones de salida (egress) avanzan.
La tercera decisión afecta a las topologías de recuperación ante desastres. Cross-Cloud-DR fue hasta 2025 una de las variantes más costosas porque la ruta de recuperación generalmente se ejecutaba a través de salida (egress) pública. Con el interconect nativo, una configuración activa-activa entre una región de AWS y una región de Google se vuelve más realista en términos de cálculo. Los equipos con setups de DR de una sola nube existentes deberían al menos realizar un esbozo arquitectónico de cómo se vería Cross-Cloud-DR bajo las nuevas suposiciones de costos. 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 de inferencia especializado, AWS por Trainium2 y sus propias integraciones Bedrock. Para los equipos que trabajan en ambos stacks, la cuestión de la red no es trivial: los modelos se entrenan en GCP, la inferencia se ejecuta en AWS Edge. El interconect nativo reduce los costos de movimiento de datos lo suficiente como para que tales arquitecturas divididas pasen de la zona de factibilidad a la zona predeterminada. Para los equipos de plataformas de ML, este es el cambio más fürte de los últimos doce meses, porque la división entre el stack de entrenamiento y el stack de inferencia anteriormente fallaba en la facturación de la red y no en la idea arquitectónica en sí.
La quinta decisión afecta al lado de la gobernanza. La conectividad cross-cloud fue en muchos contextos empresariales alemanes el punto en el que la gobernanza y la seguridad de la red decían no conjuntamente, porque el flujo de tráfico entre dominios de nube estaba mal documentado. Con una ruta nativa que aparece en ambas consolas de hiperescaladores, el esfuerzo de documentación disminuye notablemente. Quien ya ha escrito una estrategia multi-cloud como política debería actualizar las secciones de gobernanza en mayo. Para la revisión interna, esto significa: una ruta multi-cloud que aparece en ambos audit trails es auditable, una ruta gestionada por terceros requiere evidencia adicional. Esta distinción tenía poco peso en la conversación de gobernanza hasta ahora porque no había alternativa. Ahora la hay.
Paralelamente a estas cinco decisiones, queda una sexta consideración que es menos operativa y más estratégica: ¿cómo cambia la posición negociadora frente a los hiperescaladores si el cambio entre AWS y GCP se vuelve técnicamente más fácil? Los compradores empresariales que renegocian sus contratos de nube en los próximos doce meses obtienen un argumento adicional en las discusiones de precios porque los costos de salida (exit) disminuyen de manera mensurable. Este no es un argumento que funcione el primer día después de GA, pero se hará visible en la próxima ronda de contratos.
Lo que todas estas decisiones tienen en común: no son temas de un solo sprint. Una recalculación de los costos de salida (egress) a través de dos cuentas de nube generalmente tarda dos o tres semanas porque la telemetría de ambos lados debe combinarse. Una reevaluación de DR puede costar un trimestre completo. La apuesta que AWS y Google están haciendo con la GA el 16 de abril no es la adopción en cuatro semanas, sino el cambio en las suposiciones predeterminadas en dos o tres trimestres. Para los equipos de arquitectura que trabajan de manera planificada, ahora es el momento adecuado para verificar sus propias suposiciones. Para los equipos que operan de manera reactiva, la presión desde el lado financiero y de cumplimiento llegará a más tardar en otoño.
Preguntas frecuentes
¿Qué se convirtió en GA el 16 de abril de 2026?
Partner Cross-Cloud Interconnect para AWS con VPC Network Peering en Google Cloud. Este es el camino a través de un router de socio certificado desde una puerta de enlace de AWS Direct Connect hasta un VPC de GCP. La integración con el Centro de Conectividad de Red de Google (NCC) como Spoke sigue en versión preliminar. Para escenarios de dos nubes AWS-GCP, el GA es productivamente utilizable. Para Hub-and-Spoke a través de múltiples nubes, se planea a más tardar en el tercer trimestre de 2026.
¿Qué reducción de costos es realista?
Para la transferencia de datos pura entre AWS y GCP, típicamente una reducción a la mitad de los costos de salida, dependiendo de la región y el volumen de compromiso. El Egress de Internet público oscila entre alrededor de 0,07 y 0,10 de euros por GB, el Egress de Direct Connect se reduce a alrededor de 0,02 a 0,04 de euros por GB. El ahorro real depende del patrón de tráfico. En cargas de análisis bursty, el impacto es mayor; en conexiones de streaming continuas, es menor.
¿Megaport o Equinix siguen siendo relevantes como proveedores terceros?
Para configuraciones multi-cloud que deben cubrir más que AWS y GCP, sí. Para rutas puras AWS-GCP, el interconnect nativo se convertirá en la opción predeterminada en nuevas instalaciones. Los contratos existentes con Megaport o Equinix con integración de soporte en curso a menudo siguen siendo útiles, ya que cambiar genera trabajo operativo. Sin embargo, se debe reevaluar la cuenta de comparación de costos.
¿Cuándo seguirá Microsoft Azure?
Microsoft fue mencionado explícitamente como candidato a unirse a la especificación abierta de interoperabilidad de red en el anuncio conjunto de AWS-Google del 1 de diciembre de 2025. Microsoft aún no ha comunicado datos concretos del roadmap. Para arquitecturas de tres nubes con una ruta inter-hyperscaler nativa, la planificación estratégica es el formato adecuado, no la implementación productiva.
¿Qué cambia concretamente para los equipos de cumplimiento de DACH?
La ruta de red entre AWS y GCP ahora se puede documentar claramente en los registros de auditoría de ambos hyperscalers, sin que un contrato de terceros deba incluirse separadamente en la recopilación de evidencias. Esto simplifica la presentación de pruebas para auditorías de BaFin, pruebas de resiliencia de DORA o requisitos de portabilidad del EU Data Act. Quien haya redactado una política de multi-cloud por escrito debe actualizar los pasajes de red en mayo.
Más del MBF Media Netzwerk
Fuente de la imagen: generada por IA (Juli 2026)
