Operaciones multicloud sin puntos de ruptura
AWS confirmó el 14 de abril la disponibilidad general de AWS Interconnect para multicloud.
El 14 de abril, AWS confirmó la disponibilidad general de AWS Interconnect – multicloud, con Google Cloud como primer socio de lanzamiento. Lo que importa para los arquitectos de la zona DACH: las operaciones de cargas de trabajo entre las dos nubes se ejecutan ahora a través de un puente nativo cifrado con MACsec – incluyendo Frankfurt y Londres entre las regiones disponibles desde el principio. Microsoft Azure y Oracle seguirán más tarde este año. Esto elimina una gran parte de las operaciones de «canalización» (plumbing) que definían hasta ahora los entornos multicloud.
Los puntos clave en resumen
- ¿Qué hay de nuevo: AWS Interconnect – multicloud está disponible desde el 14 de abril; Google Cross-Cloud Interconnect for AWS es su equivalente.
- Donde comienza: Cinco regiones de AWS, incluyendo Frankfurt y Londres – relevante para los flujos de datos compatibles con DACH sin tránsito por Estados Unidos.
- Cómo funciona: Un recurso de transporte en Google Cloud, una aceptación en AWS, cifrado MACsec siempre activado, configuración en unos minutos en lugar de días.
- Por qué es relevante ahora: Con Transit Gateway o Cloud WAN, el puente se extiende a toda la columna vertebral de AWS – el verdadero apalancamiento operativo.
- Qué queda pendiente: Microsoft Azure y Oracle Cloud están anunciados, pero aún no activos. Los temas de identidad y FinOps siguen siendo frentes de trabajo separados.
¿Qué es AWS Interconnect – multicloud? AWS Interconnect – multicloud es una conexión privada nativa y de alta velocidad entre Amazon VPC y otros entornos de hiperescaladores. A diferencia de los modelos de interconexión anteriores, esta solución no requiere una columna vertebral de terceros ni cableado separado en el lado del destinatario – la capa física, BGP y VLAN se abstraen. El ancho de banda evoluciona de 1 a 100 Gbit/s, el cifrado MACsec está activado por defecto.
Qué aporta realmente la disponibilidad general
El punto clave no es el tramo de fibra óptica, sino lo que sucede en el extremo de esta fibra. Hasta ahora, «operaciones multicloud» significaba para la mayoría de los equipos de la zona DACH: Direct Connect en AWS, Partner Interconnect en Google, un proveedor de colocation en el medio, BGP propio, cifrado propio, tickets abiertos en tres lugares en caso de problema. Esto funciona, pero representa un esfuerzo de «canalización» sin relación directa con la carga de trabajo ejecutada encima.
Con la disponibilidad general, AWS y Google reducen esta pila a un solo recurso de transporte. Según el blog de Google Cloud, el recurso de transporte se configura en Google Cloud, se acepta en AWS, y el resto – Cloud Router, VLAN, interconexiones físicas – se abstrae. Tiempo de configuración: unos minutos en lugar de días. El cifrado MACsec siempre está activado, la rotación de claves se gestiona automáticamente por ambos proveedores.
El anuncio de AWS del 14 de abril añade el segundo apalancamiento: Interconnect puede ahora conectarse a Transit Gateway o Cloud WAN. Así, una conexión no solo alcanza una VPC, sino toda la columna vertebral de AWS. Quien prevé mover una carga de trabajo entre GKE y EKS ya no verá una pesadilla de topología en estrella, sino un modelo de enrutamiento único. Esa es la diferencia entre canalización de red y operaciones de carga de trabajo.
Cronología: la evolución de las interconexiones entre hyperscalers
Qué implica concretamente para las arquitecturas híbridas DACH
La mayoría de las configuraciones multicloud en DACH no nacieron de una estrategia, sino de adquisiciones, suites SaaS acumuladas y un ecosistema SAP en AWS enriquecido por BigQuery. Quien mueve hoy datos o cargas de trabajo entre dos nubes utiliza generalmente dos pilas de red distintas y un disparador Excel para las pruebas de conmutación. Esto no es catastrófico, pero consume horas que nadie quiere planificar en reuniones operativas.
La versión GA se dirige precisamente a esta fricción operativa. Frankfurt y Londres significan que las cargas de trabajo DACH ya no necesitan ser enrutadas a través de regiones estadounidenses — esto no es solo una cuestión de latencia, sino también un argumento RGPD que los equipos de cumplimiento pueden utilizar sin dolores de cabeza. La especificación abierta en GitHub sugiere que Stackit, OVH u otros proveedores de nube locales podrían implementar este mismo mecanismo a medio plazo — un punto crucial para los arquitectos que, por razones regulatorias, no pueden depender al 100% de los hyperscalers estadounidenses.
Paralelamente: Google Cloud ha desplegado al mismo tiempo el caching Cross-Cloud para datos leídos desde AWS y Azure. Quien combina ambos dispone de un puente operativo y un puente de datos — pero esto es otra discusión, con sus propios compromisos en materia de soberanía de datos.
Ventajas y desventajas
Puntos positivos
- Tiempo de configuración reducido de días a minutos – las ganancias se producen en las fases de prueba y desarrollo, no en el túnel de producción.
- MACsec siempre activado, rotación de claves gestionada – un punto de auditoría menos por trimestre.
- Fráncfort y Londres como regiones permiten trayectos de datos conformes al DACH sin tránsito por Estados Unidos.
- El Free-Slot de 500 Mbit/s disponible desde mayo hace que los pilotos reales sean viables – no se requiere ningún caso de negocio interno.
- La conexión a través de Transit-Gateway y Cloud-WAN permite extender una conexión a todo el backbone de AWS.
Puntos negativos
- Azure y Oracle todavía faltan – quien gestiona una triple nube debe conservar la antigua arquitectura.
- El Bridge regula las operaciones de red, no la identidad. SCIM, la federación IAM y la identidad de las cargas de trabajo siguen siendo temas distintos.
- Tarificación basada en la banda ancha y la geolocalización – la modelización debe estar integrada en las tablas FinOps, de lo contrario, el Free-Slot cuesta más de lo que vale.
- El bloqueo del proveedor se vuelve más sutil: dos nubes, un solo modelo de Fabric – la salida es posible, pero más costosa que un simple desmontaje de una infraestructura VPN.
Tres palancas para los arquitectos en los próximos 60 días
Primero: el inventario. ¿Qué cargas de trabajo se ejecutan actualmente en las dos nubes, qué transferencias están activas y cuáles son vestigios de migraciones anteriores? Quien desee aprovechar la disponibilidad general (GA) debe conocer la lista real de puentes, no la diapositiva de la última revisión de arquitectura. Este inventario está estrechamente relacionado con el inventario de conformidad multi-nube bajo NIS2 y C5, que de todos modos ya es obligatorio.
Segundo: el modelo operativo. ¿Quién se encarga de la gestión? Un Operations-Bridge requiere una definición clara del propietario; de lo contrario, se quedará atascado entre la red, la plataforma en la nube y SRE. Tres tickets por incidente no es el estado deseado. Lo ideal es un funnel SRE multi-nube que canalice los tickets hacia las dos consolas y ofrezca una visión de extremo a extremo.
Tercero: la adaptación de IaC. Quien prevé un traslado de cargas de trabajo debería integrar el bloque de recursos de transporte en módulos Terraform; las actualizaciones de proveedores llegarán en las próximas semanas, y la gestión de versiones determinará si el piloto comienza en el Q3 o después de la próxima actualización.
Preguntas frecuentes
¿Cuándo estará disponible en general la interconnectividad multicloud de AWS?
AWS confirmó la disponibilidad general el 14 de abril de 2026. Google Cloud es el primer socio de lanzamiento, mientras que Microsoft Azure y Oracle Cloud Infrastructure llegarán, según ambos proveedores, más tarde en el año.
¿Qué regiones son relevantes para la zona DACH?
Fráncfort y Londres figuran entre las cinco regiones iniciales, a las que se suman N. Virginia y Oregón. Esto permite conectar las cargas de trabajo de la zona DACH sin rodeos transatlánticos, un factor clave tanto para la latencia como para la conformidad con el RGPD.
¿En qué se diferencia esto de la versión anterior de Cross-Cloud Interconnect?
Hasta ahora, Cross-Cloud Interconnect era una solución exclusiva de Google: Google aseguraba la conexión, y en el lado de AWS, había que implementar una conexión similar a Direct Connect. Con la disponibilidad general bilateral, un simple transporte de recursos en el lado de Google y una aceptación en el lado de AWS son suficientes; la capa física y el enrutamiento se abstraen así.
¿Cuál es el costo de la conexión durante las primeras semanas?
A partir de mayo de 2026, estará disponible una ranura local gratuita de 500 Mbit/s por región. Las bandas anchas superiores, que llegan hasta 100 Gbit/s, se facturarán según la banda ancha y la extensión geográfica; el cálculo deberá estar integrado en la próxima revisión de FinOps.
¿Qué servicios de AWS se pueden conectar a Interconnect?
Según AWS, Interconnect se puede asociar con AWS Transit Gateway y AWS Cloud WAN. Esto permite interconectar una sola conexión multicloud con varios VPC y regiones, constituyendo así un verdadero apalancamiento operativo.
¿El cifrado MACsec hace una diferencia medible en materia de conformidad?
Sí, porque el cifrado a nivel de la capa 2 siempre está activado, y ambos proveedores gestionan la rotación de claves. Por lo tanto, los equipos de auditoría ya no necesitan verificar si un túnel está correctamente configurado; hasta ahora, este punto volvía a aparecer regularmente durante las auditorías C5 e ISO 27001.
Recomendaciones de lectura de la redacción
- Google Cloud Cross-Cloud Caching: lo que cambia la opción de eliminación de tarifas de salida para la zona DACH (complemento para la Operations-Bridge)
- CloudFormation frente a Terraform: análisis práctico multicloud 2026
- La arquitectura determina el costo de la conformidad: BSI-KRITIS y uso del cloud bajo NIS2 y C5
Otros soportes del grupo MBF Media
- MyBusinessFuture – Digitalización, IA y estrategia empresarial para las PYME de la zona DACH
- SecurityToday – Ciberseguridad, NIS2 y conformidad desde un enfoque operativo
- Digital Chiefs – Visión de nivel C sobre la estrategia, la gobernanza y el consejo de administración
Imagen de portada: Pexels / Brett Sayles (px:4373997)
Traducido del original en alemán con inteligencia artificial. La versión alemana es la de referencia.
