En abril de 2026, AWS y Google Cloud han puesto en preview un servicio conjunto de multicloud networking. El anuncio en re:Invent posiciona a los dos hyperscalers inusualmente cerca y apunta a un problema que muchas empresas DACH conocen desde hace años: interconexiones complejas entre clouds que duelen en la operación. Microsoft Azure se sumaría a finales de 2026. Fecha de referencia: 14 de abril de 2026.

En concreto, se trata de un control plane común para conexiones privadas entre VPCs de AWS y Google Cloud. El servicio arranca en tres regiones, entre ellas Frankfurt. Los clientes pueden conectar subnets a través de un workflow unificado, sin tener que gestionar Direct Connect y Cloud Interconnect en paralelo.

Para los platform teams que operan setups multicloud bajo carga desde 2024, es un desplazamiento relevante. Los detalles separan la promesa de marketing del beneficio operativo. Para la planificación 2026 conviene una mirada sobria a lo que ya funciona hoy.

Lo esencial en resumen

• Estado preview desde abril de 2026: tres regiones, incluida Frankfurt. El uso productivo para cargas core es prematuro, pero tiene sentido empezar a probar ahora.
• Público DACH: las empresas con setups existentes de AWS como primario y Google como secundario son las que más rápido se benefician. Especialmente en arquitecturas de data lake con analítica BigQuery sobre datos en S3.
• Azure llega a finales de 2026: quien apueste por tres clouds tiene que esperar hasta entonces. Mientras Microsoft no se sume, la operación se queda a dos vías.
• Relevancia CIO: el riesgo de vendor lock-in baja, pero solo a nivel de red. La portabilidad de bases de datos y cargas sigue siendo un tema aparte.
• Definición: multicloud networking describe la gestión centralizada de conexiones privadas entre varias public clouds a través de un control plane único, en lugar de mantener configuraciones propias de gateway, BGP y VPN por cada pareja de clouds.

Qué han anunciado en concreto AWS y Google

La colaboración, según el anuncio, simplifica el montaje de conexiones privadas entre las dos clouds. En vez de configurar Direct Connect y Partner Interconnect por separado, una capa de networking común abstrae ambos lados. La preview arranca en tres regiones. Según información de CIO Dive, junto a Frankfurt son dos regiones de EE. UU.

Técnicamente, el valor está en la reducción del overhead de configuración. Hasta hoy, los platform teams tenían que gestionar por separado sesiones BGP, AS paths y túneles VPN a ambos lados. El nuevo servicio agrupa eso en una abstracción común. Para la primera tanda vale: soporte para connectivity de capa 3, pero aún sin sincronización automática de políticas entre AWS Security Groups y Google Cloud Firewall Rules.

Importante para encuadrar: el anuncio se suma a una serie de movimientos que AWS y Google Cloud vienen haciendo en el mercado alemán desde finales de 2025. El interconnect de Frankfurt de marzo fue el precursor técnico. La preview actual añade encima el control plane. Quien lea las novedades de infraestructura de los últimos seis meses en orden cronológico ve una dirección clara: ambos hyperscalers ya no quieren que el multicloud se entienda como una solución de emergencia, sino como estándar.

Según Info-Tech Research Group, AWS tiene a nivel global alrededor del 32 por ciento de cuota de mercado, Azure el 23 por ciento y Google Cloud el 11 por ciento. La colaboración tiene justamente por eso sentido: AWS no tiene que ceder mercado a Google y Google gana acceso a los despliegues existentes nativos de AWS. Para las empresas DACH, el ecosistema de centros de datos de Frankfurt es así el beneficiado directo.

Qué de esto es hoy real y qué sigue siendo marketing

Tres cosas conviene tener claras antes de decidir. Primera: preview significa preview. No hay SLA, la disponibilidad por región puede cambiar, las cifras de clientes son confidenciales. Quien apueste por este servicio para pipelines de datos multicloud en producción asume un riesgo difícil de asegurar operativamente.

Segunda: la abstracción afecta a la red, no a la identidad. Las políticas IAM siguen teniendo que modelarse por separado en cada cloud. Quien quiera montar Single Sign-On y cross-cloud service accounts limpiamente acaba rápido otra vez en Terraform o en capas dedicadas de Identity Federation. El anuncio no cambia eso. Reduce el overhead hasta la capa 3, no hasta la capa 7.

Tercera: Azure no está. La línea de tiempo oficial habla de finales de 2026 para la integración de Microsoft. Hasta entonces, el caso con tres clouds sigue siendo un proceso separado. Quien reparta cargas entre AWS, Azure y Google Cloud tiene que seguir planificando a dos vías. Para empresas con cargas existentes pesadas en Azure (Office 365, Dynamics, muchas integraciones SaaS) eso significa: la ventaja de red de la nueva preview sigue siendo teórica hasta que Azure se integre.

Operativamente, para la mayoría de las organizaciones IT de DACH esto significa: la nueva preview es interesante como señal y como campo de pruebas, no como pieza de producción. Quien planifique en 2026 una estrategia de dos clouds con AWS y Google Cloud puede incluir la abstracción en la reflexión de arquitectura. Quien tenga Azure en el mix sigue planificando con terceros establecidos como Megaport o Equinix Fabric.

Qué deben revisar ahora los platform teams en DACH

Para la mayoría de las organizaciones IT de habla alemana merecen la pena tres pasos concretos. El primero es un inventario: qué cargas operan hoy a través de conexiones multicloud y cuánto esfuerzo de configuración les cuestan. Si eso está por debajo del 10 por ciento del tiempo del equipo de plataforma, la preview no es prioridad. Si está por encima, merece la pena un setup de pruebas en Frankfurt.

El segundo paso es una comparación con las alternativas existentes. Megaport, Equinix Fabric y Console Connect ofrecen cross-cloud interconnects desde hace años. La diferencia con la nueva colaboración AWS-Google está en el modelo de precios y en la capa de gestión, no en una tecnología radicalmente nueva. La comparativa DACH de los tres hyperscalers muestra las diferencias más importantes en features de red y en pricing.

El tercer paso afecta a la estrategia de cargas. Una capa multicloud simplificada baja los costes operativos de las arquitecturas distribuidas. Pero no hace superflua la cloud repatriation. Quien se pregunte en 2026 qué cargas tienen que volver a centros de datos propios encontrará en el análisis del modelo TCO de cloud repatriation un marco estructurado para ello.

Un cuarto tema aparece cada vez más a menudo en las conversaciones de proyecto: compliance. Quien sea evaluado conforme a NIS2 o DORA tiene que discutir la abstracción de red con los auditores. La responsabilidad de las notificaciones de incidentes sigue siendo de cada cloud por separado. Un control plane común no cambia los canales de notificación, solo añade una capa de abstracción adicional que la IT governance tiene que valorar.

Comparación con las ofertas existentes de multicloud interconnect

El anuncio no llega al vacío. Desde hace al menos cinco años existe un mercado para cross-cloud interconnects que se puede dividir en tres categorías. Brokers de red como Megaport y Equinix Fabric ofrecen conexiones directas virtuales entre todos los grandes hyperscalers. Están físicamente en los carrier hotels y venden connectivity de capa 2 como servicio. Colocation providers como NTT o Interxion amplían eso con conexiones físicas cage-to-cage. Servicios SD-WAN cloud-native como Cisco Multicloud Defense o Aviatrix construyen encima una capa software y traen sus propios motores de políticas.

La colaboración AWS-Google cae en una cuarta categoría: cooperación nativa entre hyperscalers. La diferencia está en la profundidad de integración y en el precio. Un setup Megaport cuesta para una empresa DACH típica con dos regiones cloud entre 2.000 y 4.000 euros al mes, según ancho de banda y redundancia. Es probable que la colaboración AWS-Google quede por debajo, porque no hay un tercero que cobre. Por ahora faltan cifras concretas.

Para empresas con contratos Megaport o Equinix existentes no cambia nada a corto plazo. Los contratos siguen, la funcionalidad sigue siendo más amplia. Pero quien monte en 2026 una nueva estrategia multicloud y solo tenga AWS más Google Cloud en el plan debería evaluar también la opción nativa en cuanto llegue a GA.

Qué es realista a continuación

Los próximos tres a seis meses mostrarán si la preview aguanta técnicamente. Son determinantes tres puntos de observación. Estabilidad de la disponibilidad por región: si una de las tres regiones iniciales cae, la confianza en la arquitectura global baja notablemente. Ampliación a más dependencias de Frankfurt: ¿se suma eu-central-2 (Zúrich) o se queda en eu-central-1? La respuesta decide si los clientes suizos con requisitos de residencia de datos pueden jugar. Claridad en el timing de Azure: si se mantiene el plazo de finales de 2026 para Microsoft, el trío de abstracción de red es realista. Si no, la preview sigue siendo una herramienta AWS-Google con radio de uso limitado.

Para medianas empresas alemanas con una estrategia cloud dominada por AWS, la preview se ofrece como campo de aprendizaje. Un VPC de pruebas en Frankfurt con su contraparte en Google Cloud, unidos a través del nuevo servicio, no cuesta presupuestos reseñables y muestra en operación cuánto overhead de operaciones ahorra realmente la abstracción. Los resultados alimentan las decisiones de arquitectura para 2027, en el que Azure ya estará en juego.

Riesgos y preguntas abiertas

Por muy agradable que sea la simplificación, quedan algunos riesgos. El primero afecta al vendor lock-in a nivel de red. Quien construya su arquitectura multicloud sobre un servicio orquestado por uno de los dos hyperscalers ha reducido la dependencia, pero no la ha disuelto. La abstracción solo funciona dentro de los límites que AWS y Google definen conjuntamente. Las features que solo existen en una de las dos clouds siguen separadas.

El segundo riesgo está en el modelo de soporte. Si surge un problema, se plantea la clásica pregunta multi-vendor: ¿qué soporte es competente? El anuncio menciona un modelo común de escalado. Cómo funciona eso en la práctica con incidentes P1 reales es la verdadera prueba de carga. Las experiencias de colaboraciones parecidas muestran que los procesos de soporte compartidos necesitan entre 6 y 12 meses para rodar de forma realmente fluida.

El tercer tema abierto es la mirada al roadmap. ¿Llegará en 2027 una integración IAM? ¿Se ampliarán la sincronización de políticas y la federación de network policies a capa 7? Sin esos añadidos, el servicio sigue siendo una herramienta de red, no una plataforma de gestión multicloud. No lo decimos en sentido negativo – es simplemente un posicionamiento claro que los IT architects tienen que conocer antes de apoyarse en él.

Recomendación de arquitectura para proyectos 2026

Quien esté planificando ahora un nuevo montaje cloud o refactorizando una arquitectura existente puede aplicar tres pautas. Primera: apoyar la capa de red en estándares abiertos. Las abstracciones de los hyperscalers son cómodas, pero una base Terraform o Crossplane sigue siendo el cimiento más estable. Segunda: separar la capa de identidad de la de red. Quien resuelva Single Sign-On mediante proveedores dedicados como Okta, Entra ID o Keycloak conserva flexibilidad ante cambios de proveedor cloud. Tercera: modelar los costes antes de que surjan. Una conexión multicloud simplificada baja los costes de operación, pero puede aumentar los costes de transferencia de datos si se usa con demasiada generosidad. Un modelo TCO bien calculado a 24 meses ofrece una base de decisión más sólida que cualquier anuncio de precios de los hyperscalers.

El cuarto punto afecta al monitoring. Quien una dos clouds a través de un control plane abstraído tiene que consolidar la observability de ambos lados. Los setups basados en Prometheus con Grafana como capa frontend unificada han demostrado ser muy viables en medianas empresas DACH. Una plataforma dedicada de multicloud observability como Datadog o Dynatrace solo compensa a partir de una complejidad de carga que la mayoría de las medianas empresas de todas formas no alcanzan.

Preguntas frecuentes

¿Cuándo podrá usarse en producción la colaboración multicloud AWS-Google?

Ahora mismo corre la preview; no se ha comunicado una fecha de GA. Para cargas core en producción es recomendable esperar a GA. Para entornos de pruebas, replicación de data lakes o flujos no críticos, el servicio ya se puede probar hoy.

¿Sustituye el servicio a Megaport o a Equinix Fabric?

A corto plazo, no. Megaport y Equinix ofrecen cross-cloud interconnects en más regiones, soportan a los tres hyperscalers y traen features propias de private network. La colaboración AWS-Google es más barata y está más directamente integrada para setups de dos clouds entre exactamente esos dos proveedores.

¿Qué significa esto para la evaluación de compliance según DORA y NIS2?

La abstracción de red no cambia la responsabilidad de los data controllers. Ambas clouds siguen siendo procesadores separados. La valoración regulatoria (ubicación del dato, logging, obligación de notificar incidentes) tiene que seguir haciéndose por cada cloud.

¿Llegará la colaboración también a la segunda región de Frankfurt (eu-central-2)?

Las tres regiones iniciales incluyen, según el anuncio, Frankfurt (eu-central-1). No se ha nombrado oficialmente una ampliación a la región de Zúrich (eu-central-2). Para clientes suizos con requisitos de residencia de datos, es un punto importante a revisar.

¿Cuánto cuesta el servicio en la fase preview?

Con el anuncio no se han publicado modelos de precios oficiales. La participación en la preview se gestiona vía registro de cuenta. Los aspectos de coste se comunican tras el enrollment. Con el lanzamiento GA cabe esperar un modelo de pricing específico que probablemente se oriente a las tarifas existentes de Direct Connect y Cloud Interconnect.

Fuente de la imagen de portada: Pexels / Brett Sayles