6 min de lectura
El 1 de diciembre de 2025, AWS y Google Cloud hicieron algo que nunca antes había ocurrido: presentaron un producto de red desarrollado conjuntamente. Conexiones privadas cifradas mediante MACsec entre ambas nubes, provisionadas mediante API en minutos en lugar de semanas a través de proveedores externos. Fráncfort es una de las cinco regiones de lanzamiento. Para las arquitecturas multicloud en DACH, esto representa un punto de inflexión.
En resumen
- 🔗 AWS Interconnect (multicloud) y Google Cross-Cloud Interconnect conectan por primera vez de forma nativa ambas nubes (AWS/Google, 01.12.2025).
- 🇩🇪 Fráncfort (eu-central-1 / europe-west3) es una de las cinco regiones de lanzamiento en fase de vista previa (Preview) (Documentación de AWS).
- ⚡ Provisionamiento en minutos mediante API. Hasta ahora, la configuración de conexiones privadas entre nubes requería semanas o incluso meses (InfoQ).
- 🔒 Cifrado mediante MACsec (IEEE 802.1AE) sobre la línea física. Ningún tráfico atraviesa Internet público (AWS).
- 📊 A nivel mundial, el 89 % de las empresas utilizan varios proveedores de servicios en la nube (Flexera State of the Cloud, 2024).
Qué han construido AWS y Google Cloud
El anuncio tuvo lugar el 1 de diciembre de 2025, un día antes del inicio de la conferencia AWS re:Invent en Las Vegas. Por primera vez, dos hyperscalers han desarrollado conjuntamente una infraestructura de red que conecta directamente sus nubes. Técnicamente, se trata de dos productos: AWS Interconnect – multicloud en el lado de AWS y Cross-Cloud Interconnect en el lado de Google Cloud. Ambos emplean una especificación de API desarrollada conjuntamente.
El resultado: los clientes pueden establecer conexiones privadas y dedicadas entre sus VPC de AWS y sus redes VPC de Google Cloud. El tráfico circula a través de líneas físicas dedicadas entre los routers perimetrales de ambos proveedores, cifrado mediante MACsec (IEEE 802.1AE). Ningún paquete atraviesa Internet público.
En la práctica, esto significa lo siguiente: una empresa que ejecuta una base de datos en Google Cloud y la lógica de su aplicación en AWS puede conectar ahora ambos cargas de trabajo con latencias bajas y ancho de banda completo. Sin túneles VPN, sin proveedores de tránsito y sin provisionamiento manual.
Por qué Fráncfort como región de lanzamiento es decisiva
Las cinco regiones de lanzamiento de la vista previa son US-East (Northern Virginia), US-West (Oregon), US-West (N. California), Europe (London) y Europe (Frankfurt). Que Fráncfort esté incluida desde el principio no es casualidad. La región eu-central-1 (AWS) y europe-west3 (Google Cloud) constituye el emplazamiento en la nube más importante de Europa continental.
Para las empresas de DACH, esto elimina uno de los mayores puntos dolorosos de las arquitecturas multicloud: la latencia de red entre nubes. Hasta ahora, las empresas que deseaban distribuir sus cargas de trabajo entre AWS y Google Cloud tenían que optar bien por enrutarlas a través de Internet público (con todos los riesgos de seguridad y rendimiento asociados), bien por intercalar un proveedor externo como Megaport o Equinix Fabric. Esto requería semanas, generaba costes adicionales y, con frecuencia, el ancho de banda estaba limitado.
Con el interconector nativo desaparece el intermediario. El provisionamiento se realiza mediante API, la conexión está disponible en minutos y el cifrado es estándar. Para sectores regulados en Alemania, que deben demostrar un tratamiento de datos conforme al Reglamento General de Protección de Datos (RGPD), la garantía de que ningún tráfico atraviesa Internet público representa una ventaja tangible en materia de cumplimiento normativo.
La especificación abierta: un estándar industrial en desarrollo
Un detalle fácil de pasar por alto: AWS ha publicado la especificación subyacente de la API Connection Coordinator como OpenAPI 3.0 en GitHub. No se trata de un protocolo propietario, sino de una especificación abierta que otros proveedores de servicios en la nube pueden implementar.
Según InfoQ, Microsoft Azure debería ser el próximo proveedor en integrarse. AWS ha anunciado su intención de incorporar a otros proveedores de nube. Si Azure efectivamente se une en 2026, se creará un interconector nativo entre los tres grandes hyperscalers. Esto supondría un cambio fundamental: el networking multicloud dejaría de ser un proyecto complejo de infraestructura para convertirse en una simple llamada a una API.
Para los arquitectos de nube, cambia la ecuación costo-beneficio en las decisiones multicloud. Hasta ahora, la complejidad de la red era uno de los argumentos más contundentes contra el modelo multicloud. Si dicha complejidad desaparece, cobran mayor relevancia otros factores: servicios best-of-breed, comparación de precios, zonas de disponibilidad y requisitos regulatorios.
«Establecer conexiones entre nubes, que hasta ahora requerían semanas o meses, ahora se puede hacer en minutos.»
– AWS/Google Cloud, Comunicado conjunto, diciembre de 2025 (texto parafraseado)
Qué puede y qué no puede hacer técnicamente el interconector
El interconector resuelve el problema de la red. Pero el modelo multicloud tiene más dimensiones que la mera conectividad.
Qué puede hacer: Conexiones privadas y cifradas de capa 3 entre VPC de AWS y redes VPC de Google Cloud. Provisionamiento mediante API con anchos de banda definidos (10 Gbps, 100 Gbps). Enrutamiento automático mediante BGP. Supervisión a través de las respectivas consolas de nube.
Qué no puede hacer: Facturación unificada entre nubes. Políticas IAM unificadas. Observabilidad multicloud desde una única consola. Migración automática de cargas de trabajo. El interconector es una línea de red, no un sistema operativo multicloud.
Esto implica que los equipos siguen necesitando herramientas para la gestión transversal de nubes. Terraform o Pulumi para Infrastructure as Code, Datadog o Grafana para supervisión, y procesos organizativos para la gobernanza en múltiples cuentas de nube. El interconector elimina la complejidad de la red, pero no la complejidad operativa.
Seguridad y cumplimiento normativo: qué significa el interconector para sectores regulados
Para entidades financieras, empresas sanitarias y otros sectores regulados en DACH, el interconector representa mucho más que una mejora de rendimiento. La garantía de que ningún tráfico atraviesa Internet público simplifica considerablemente la documentación del RGPD. Los delegados de protección de datos pueden demostrar que los datos personales se transfieren exclusivamente a través de líneas dedicadas y cifradas entre dos proveedores de nube.
En el contexto de la Directiva NIS2, esto también resulta relevante. Las empresas sujetas a la Ley de Transposición de NIS2 deben documentar la seguridad de su infraestructura de red. Un interconector nativo con cifrado MACsec es más sencillo de documentar que un túnel VPN a través de Internet público. Las responsabilidades están claras: AWS cifra en un extremo, Google Cloud en el otro, y la línea física intermedia es dedicada.
No obstante, persiste una pregunta abierta: ¿cómo afecta el interconector a la soberanía de los datos? Las líneas físicas entre los routers perimetrales recorren infraestructura que ni AWS ni Google Cloud poseen. Quién opera dicha infraestructura y dónde exactamente transitan los datos en su trayecto entre Fráncfort (AWS) y Fráncfort (Google Cloud) no está documentado de forma totalmente transparente.
Impacto en configuraciones multicloud existentes
A nivel mundial, el 89 % de las empresas utilizan varios proveedores de servicios en la nube, según muestra el Informe Flexera State of the Cloud 2024. La mayoría lo hace no por convicción estratégica, sino porque distintos equipos han elegido distintas nubes. Hasta ahora, la conexión entre estas nubes solía improvisarse: túneles VPN, puntos finales públicos con listas blancas de direcciones IP o conexiones directas costosas a través de proveedores de colocation.
El interconector nativo cambia las reglas del juego para tres escenarios:
Escenario 1: Canalización de datos. Una empresa utiliza BigQuery en Google Cloud para análisis y S3 en AWS para almacenamiento de datos. Hasta ahora, los datos debían transferirse a través de Internet o de un proveedor de tránsito. Ahora fluyen a través de una línea dedicada y cifrada. Más rápido, más seguro y más económico en términos de egresos.
Escenario 2: Recuperación ante desastres. Cargas de trabajo principales en AWS, conmutación a respaldo en Google Cloud. El interconector permite replicación síncrona o asíncrona con latencia garantizada. Nada que ver con la replicación basada en VPN hasta ahora habitual.
Escenario 3: Mejor servicio disponible. Kubernetes en GKE (Google), inferencia de modelos de IA en SageMaker (AWS) y base de datos en Cloud SQL (Google). En lugar de aceptar compromisos arquitectónicos, cada equipo puede utilizar el mejor servicio disponible y dejar la integración de red al interconector.
Qué deben hacer ahora los proveedores externos como Megaport y Equinix
Para empresas como Megaport, Equinix Fabric y PacketFabric, el interconector nativo representa una amenaza estratégica. Su modelo de negocio se basa en conectar nubes que hasta ahora no podían hacerlo por sí mismas. Si AWS y Google Cloud ofrecen esta funcionalidad de forma nativa y Azure sigue su ejemplo, el mercado potencial se reducirá considerablemente.
Los proveedores externos deberán centrarse en añadir valor: gestión multicloud, visibilidad, informes de cumplimiento normativo y conexión con proveedores de nube menores que no forman parte del interconector nativo. Para empresas que confían en proveedores de nube europeos como IONOS, OVHcloud o STACKIT, los proveedores externos seguirán siendo, por el momento, la única opción para conexiones privadas.
Conclusión
El interconector AWS-Google Cloud es más que un nuevo producto de red. Es una señal: los hyperscalers han reconocido que el modelo multicloud es una realidad y comienzan a abrir sus infraestructuras. El hecho de que Fráncfort sea una región de lanzamiento hace que esta oferta sea inmediatamente relevante para las empresas de DACH.
Los arquitectos de nube deberían evaluar ya la versión de vista previa. No para migrar inmediatamente, sino para comprender cómo cambia la ecuación costo-beneficio de las arquitecturas multicloud. Si Azure se integra en 2026 y la especificación abierta se convierte en un estándar industrial, la complejidad de la red dejará de ser un argumento válido contra el modelo multicloud.
Entonces la cuestión ya no será si adoptar un modelo multicloud, sino cuál combinación de proveedores y servicios ofrece la mejor arquitectura para la propia empresa.
Preguntas frecuentes
¿Ya está listo para producción el interconector AWS-Google Cloud?
El interconector se encuentra actualmente en fase de vista previa (a partir de marzo de 2026). Es funcional y puede someterse a pruebas, pero AWS y Google Cloud recomiendan no utilizarlo aún para cargas de trabajo productivas críticas para el negocio. Se prevé su disponibilidad general (GA, General Availability) para 2026.
¿Cuál es el coste del interconector?
La estructura de precios aún no está definitivamente fijada durante la fase de vista previa. Ambos proveedores suelen aplicar típicamente una tarifa por puerto (según el ancho de banda) más los costes de egreso por el tráfico de datos transferido. Se espera que los costes de egreso sean inferiores a los correspondientes a transferencias a través de Internet público.
¿Puedo combinar el interconector con configuraciones existentes de Direct Connect o Partner Interconnect?
Sí. El interconector complementa las conexiones existentes (AWS Direct Connect, Google Partner Interconnect). No las sustituye, sino que añade una nueva opción para el tráfico entre nubes.
¿Se integrará también Azure?
AWS ha anunciado su intención de incorporar a otros proveedores de nube, entre ellos Microsoft Azure. Aún no se ha fijado una fecha concreta, pero la especificación de API abierta hace posible técnicamente dicha integración. La comunidad espera que tenga lugar en 2026.
¿Sigo necesitando Megaport o Equinix Fabric?
Para la conexión directa entre AWS y Google Cloud en las regiones de vista previa, ya no es necesario. Para conexiones con Azure, proveedores de nube europeos o centros de datos locales (on-premises), los proveedores externos siguen siendo relevantes.
Artículos relacionados
- Lavado de soberanía – Por qué un centro de datos de la UE no equivale automáticamente a soberanía de los datos (cloudmagazin)
- Trampa de costes de VMware 2026 – Por qué los equipos de TI deben decidir ya sobre alternativas (cloudmagazin)
- Costes de la nube impulsados por la IA fuera de control – Por qué las cargas de trabajo GPU agotarán los presupuestos de TI en 2026 (cloudmagazin)
Más contenido del ecosistema mediático MBF Media
- Computación en el borde – Por qué la nube no siempre es suficiente para las pymes (MyBusinessFuture)
- Repatriación a la nube 2026 – Por qué los directores de información recuperan cargas de trabajo (Digital Chiefs)
Fuente de imagen: Brett Sayles / Pexels
