AWS y Google conectan sus nubes para limitar los apagones

Amazon Web Services y Google Cloud han puesto en marcha una interconexión multicloud para que sus clientes puedan enlazar ambas plataformas mediante caminos privados, gestionados y de alta capacidad. La iniciativa puede limitar el impacto de determinados fallos si una empresa ha preparado sus aplicaciones para funcionar en las dos nubes, pero no impide que haya averías ni garantiza que cualquier servicio cambie de proveedor sin interrupciones.

La diferencia importa: este enlace no hace que Internet deje de depender de infraestructuras compartidas. Reduce una barrera técnica para distribuir cargas entre dos grandes proveedores y facilita que una organización construya redundancia entre ellos. El sistema se presentó en vista previa pública desde el 1 de diciembre de 2025, con una hoja de ruta que anunciaba la incorporación de Microsoft Azure durante 2026. El puente facilita la conexión; la resiliencia sigue dependiendo, en buena medida, del diseño de cada servicio.

Qué han acordado AWS y Google Cloud

La conexión combina AWS Interconnect Multicloud con Google Cloud Cross-Cloud Interconnect. En vez de obligar a cada cliente a coordinar por separado circuitos, equipos y configuraciones de red, los proveedores ofrecen un mecanismo gestionado para establecer enlaces entre sus entornos. La empresa selecciona las regiones y la capacidad que necesita y configura la conexión desde las herramientas de cada plataforma, sin tener que construir por su cuenta toda la infraestructura física que las une.

El propósito es que el tráfico entre redes de AWS y Google Cloud no tenga que recorrer la Internet pública. El enlace se plantea como una vía privada y cifrada, con opciones de redundancia y supervisión, para que las compañías puedan mover datos o mantener comunicados servicios alojados en nubes distintas. La novedad está tanto en la coordinación entre los proveedores como en simplificar el aprovisionamiento, una tarea que antes podía implicar acuerdos con operadores y una configuración específica para cada conexión.

La disponibilidad inicial descrita para la vista previa incluye regiones de Estados Unidos, como Norte de Virginia y Oregón, y de Europa, como Londres y Fráncfort. El despliegue parte de capacidades de 1 Gbps y contempla escalones superiores de 10, 40 y 100 Gbps, según la evolución prevista del servicio. Estas cifras se refieren a la capacidad de los enlaces, no a una velocidad que todas las aplicaciones vayan a alcanzar en cualquier circunstancia: la distancia entre regiones, la carga y la arquitectura de cada empresa también influyen en el rendimiento.

Un puente privado no es un botón contra los cortes

Una interconexión de alta capacidad puede hacer más directa y previsible la comunicación entre dos nubes, pero por sí sola no mueve una aplicación de un entorno a otro. Para que el cambio ocurra cuando algo falla, la empresa debe disponer de una segunda instancia operativa, decidir qué tráfico se redirige y mantener los datos necesarios para continuar el servicio. La conexión resuelve una parte de la red; no replica automáticamente los sistemas ni su información.

El ejemplo más sencillo sería una aplicación que mantiene una copia funcional en AWS y otra en Google Cloud. Si una región de la primera plataforma queda indisponible, el servicio podría seguir desde la segunda, siempre que los datos estén al día y el tráfico pueda encaminarse hacia allí. En cambio, si la aplicación solo existe en AWS, o depende de una base de datos que no se replica fuera de esa nube, el nuevo enlace no crea de repente un sustituto listo para entrar en funcionamiento.

También hay diferencias entre una arquitectura activa-activa y otra activa-pasiva. En la primera, los dos entornos atienden trabajo al mismo tiempo; en la segunda, uno permanece preparado para asumirlo si el principal falla. El enlace puede servir a ambos modelos, pero no elimina sus decisiones técnicas: cómo se resuelven las escrituras simultáneas, qué copia se considera válida y qué ocurre con las operaciones que estaban en marcha durante el incidente. La continuidad no se mide solo por tener una segunda nube, sino por poder usarla sin perder coherencia.

Por qué esta colaboración puede reducir el alcance de una avería

Un corte en un proveedor no siempre deja fuera de servicio todo Internet, aunque la experiencia del usuario pueda parecerlo. Muchas páginas y aplicaciones dependen de una combinación de alojamiento, bases de datos, redes de distribución, sistemas de identidad y otros servicios compartidos. Si una pieza común falla, las consecuencias pueden propagarse a empresas distintas que, en apariencia, no tienen relación entre sí. La concentración de servicios en unas pocas plataformas convierte una incidencia localizada en un problema visible a gran escala.

Distribuir componentes entre proveedores puede reducir esa dependencia de una sola infraestructura. Si una nube sufre un fallo y la otra conserva los componentes necesarios, una compañía podría mantener funciones esenciales o recuperar el servicio antes. La interconexión directa ayuda a que las dos partes se comuniquen sin depender de soluciones montadas íntegramente sobre conexiones públicas o configuraciones especiales. Su efecto potencial es contener daños en servicios preparados para diversificarse, no proteger por igual a toda la red.

La distinción explica por qué la alianza no debe presentarse como una cura para los apagones masivos. Puede ayudar a evitar que un fallo en un proveedor se convierta en una caída completa para una empresa que ha distribuido su sistema, pero no corrige la avería original ni neutraliza las dependencias que sigan concentradas en un único lugar. Un problema en el software de la propia aplicación, en sus credenciales o en un servicio utilizado por ambas nubes también puede afectar a las dos copias a la vez.

La red es solo una capa de la continuidad

La redundancia funciona mejor cuando se construye en varios niveles. En la capa de red, el enlace privado ofrece una ruta entre los proveedores; en la de infraestructura, hacen falta recursos disponibles en más de una región; y en la aplicación, el programa debe tolerar que una parte desaparezca y continuar con las demás. La replicación de datos, el control del estado de las sesiones y la forma de dirigir a los usuarios son piezas distintas, aunque todas intervengan en la misma recuperación.

El servicio anunciado incluye mecanismos de redundancia y seguimiento del estado de la conexión, con rutas diseñadas para reducir puntos únicos de fallo. También se describen cifrado MACsec, métricas y acuerdos de nivel de servicio asociados al enlace. Son medidas relevantes para proteger el transporte y detectar degradaciones, pero un compromiso de disponibilidad de la conexión no equivale a una garantía de que una aplicación concreta permanezca operativa de extremo a extremo. Un enlace puede estar sano mientras el servicio que depende de él está caído.

La conmutación exige además decidir qué condición activa el cambio y cómo se evita que los dos entornos acepten órdenes incompatibles. Si una aplicación procesa pagos, por ejemplo, no basta con redirigir nuevas solicitudes: también debe saber qué transacciones llegaron a completarse y cuáles deben reintentarse. Si gestiona sesiones de usuario, tiene que resolver si estas se mantienen o se reinician al cambiar de entorno. Son problemas de funcionamiento de la aplicación, no cuestiones que una conexión entre nubes pueda resolver por sí sola.

Qué aporta el cifrado y dónde termina su protección

Un canal privado reduce la exposición del tráfico frente a la ruta habitual por Internet, mientras que MACsec cifra la comunicación en la capa de enlace. La protección resulta útil cuando se intercambian datos entre infraestructuras y se busca limitar la posibilidad de que el tráfico viaje sin cifrar por los tramos cubiertos. También permite a los equipos de operación observar una conexión gestionada y coordinada en lugar de mantener por separado cada pieza de una red construida a medida.

Eso no significa que todos los datos queden protegidos de cualquier riesgo. La interconexión no sustituye el cifrado de la información dentro de la aplicación, el control de quién puede acceder a ella ni la gestión de claves y permisos. Al extender una arquitectura a dos proveedores, también se amplía el número de entornos, identidades y configuraciones que deben revisarse. La privacidad del trayecto no corrige un permiso mal asignado ni una vulnerabilidad en el programa.

La telemetría y las alertas pueden ayudar a distinguir entre una interrupción de red y un problema en la aplicación, pero el valor práctico depende de cómo se integren en la supervisión de la empresa. Si las señales de AWS y Google Cloud se analizan por separado, el equipo puede tardar en reconstruir lo ocurrido. La coordinación técnica reduce parte de esa fricción, aunque sigue haciendo falta entender qué componente falló primero y qué sistemas quedaron afectados como consecuencia.

Multicloud: flexibilidad con más piezas que coordinar

Las empresas llevan tiempo usando más de una nube, pero una estrategia multicloud no consiste simplemente en contratar dos proveedores. Puede responder a necesidades concretas, como separar cargas, disponer de capacidad alternativa o elegir servicios distintos según el trabajo. A cambio, obliga a gestionar dos conjuntos de herramientas y a resolver diferencias en redes, permisos, almacenamiento y servicios administrados. El nuevo enlace busca reducir parte del trabajo de conectividad, no hacer idénticas las plataformas.

Una aplicación que utiliza una base de datos o un sistema de colas propio de una nube puede no tener un equivalente que se comporte exactamente igual en la otra. Migrar o replicar ese componente requiere adaptar la aplicación y comprobar qué pasa con los datos, las operaciones pendientes y los usuarios durante un cambio. Por eso, la posibilidad de conectar AWS con Google Cloud puede resultar más sencilla para ciertos servicios que para otros. La interoperabilidad de la red no garantiza la interoperabilidad de todo el software.

El enfoque también puede interesar a compañías que quieran desplegar una carga en un proveedor y mantener otra parte en el segundo, sin que cada intercambio dependa de una configuración improvisada. En ámbitos con servicios críticos, reducir el tiempo necesario para establecer conectividad puede facilitar pruebas de continuidad y planes de recuperación. Pero la conveniencia de mantener recursos duplicados depende del coste, de la complejidad y del nivel de interrupción que la organización esté dispuesta a tolerar; no hay una arquitectura universal que sirva a todos.

La incorporación de Azure ampliaría la red de opciones

Amazon señaló que Microsoft Azure se incorporaría al programa durante 2026. Si esa integración se materializa conforme a la hoja de ruta anunciada, las empresas tendrían una vía más para conectar nubes de distintos proveedores bajo un modelo común. La ampliación sería significativa porque reduciría la necesidad de diseñar cada enlace como un proyecto aislado y permitiría plantear arquitecturas que incluyan a los tres grandes actores del mercado.

Sin embargo, que tres plataformas puedan conectarse no significa que una aplicación salte entre ellas sin trabajo adicional ni que todas las regiones y capacidades estén disponibles de inmediato. Cada ampliación debe aterrizar en servicios concretos, configuraciones compatibles y acuerdos operativos claros. La existencia de una especificación abierta, planteada para facilitar la interoperabilidad, puede ayudar a evitar que cada pareja de proveedores adopte mecanismos completamente distintos, pero el estándar por sí solo no elimina las diferencias técnicas ni comerciales.

La cooperación resulta llamativa porque AWS, Google y Microsoft compiten por los mismos clientes. Aun así, las empresas que usan sus nubes necesitan comunicarlas y mantener operativos sistemas que pueden estar repartidos entre varias. En este caso, colaborar en la conectividad no supone renunciar a la competencia en otros servicios: crea una capa de relación entre plataformas que puede hacer más viable la estrategia de los clientes. La rivalidad comercial y la necesidad de interoperar pueden convivir.

El coste real incluye operación y pruebas

Una conexión gestionada puede evitar parte del trabajo de contratar circuitos, coordinar operadores y mantener equipos propios. Esa simplificación tiene un valor operativo, sobre todo para organizaciones que antes debían resolver cada integración con soluciones específicas. No obstante, el uso de enlaces y recursos en más de una nube también puede generar costes de transporte, capacidad y operación. La información de referencia no permite fijar una tarifa general aplicable a todos los casos, y el gasto dependerá del uso y de la configuración elegida.

El coste de la redundancia no se limita al enlace. Mantener una copia de una aplicación, replicar datos y reservar capacidad en otra plataforma implica recursos que quizá permanezcan infrautilizados durante periodos normales. Frente a eso están las consecuencias de una interrupción, que varían mucho según el servicio y la empresa. La decisión no se reduce a comparar una factura con otra: también exige valorar cuánto tarda la recuperación y qué funciones deben seguir disponibles cuando hay una avería.

Las pruebas son parte de ese coste y de la propia fiabilidad. Un plan de recuperación que nunca se ensaya puede fallar justo cuando más se necesita, porque una clave ha caducado, los datos no están sincronizados o el cambio de tráfico no se comporta como se esperaba. La conexión facilita construir y comprobar el camino alternativo, pero cada empresa debe verificar qué aplicaciones sobreviven a un corte, cuánto tardan en recuperarse y qué información puede quedar pendiente. La redundancia que no se prueba es una hipótesis, no una garantía.

Por qué el cambio importa más allá de las empresas

Para el usuario final, la interconexión no suele ser visible. Su posible beneficio aparecería en forma de una interrupción más corta, una función que continúa disponible o una degradación menos severa cuando falle una parte de la infraestructura. También es posible que no note ningún cambio, porque muchas empresas no replican sus aplicaciones entre nubes o porque el incidente afecte a un componente que comparten los dos entornos.

Los efectos indirectos pueden ser importantes en servicios que dependen de sistemas digitales para operar sin pausa. Pagos, comercio electrónico, plataformas de contenidos y aplicaciones empresariales pueden necesitar que ciertas funciones sigan disponibles incluso si una región o proveedor atraviesa problemas. La interconexión añade una herramienta para construir esa continuidad, aunque no permite afirmar que todos esos sectores vayan a quedar protegidos por igual ni que un apagón general deje de ser posible.

El caso también muestra una característica menos visible de Internet: su aparente unidad descansa en acuerdos y dependencias entre redes privadas, centros de datos y proveedores de servicios. La red global no tiene un único interruptor que AWS y Google puedan apagar o mantener encendido. Lo que sí pueden hacer es mejorar cómo se conectan dos partes relevantes de esa infraestructura y ofrecer a sus clientes más opciones para diseñar sistemas resistentes. La resiliencia de Internet se construye con muchas decisiones distribuidas, no con un único enlace.

Una capa nueva de protección, no el fin de las caídas

La alianza entre AWS y Google Cloud puede contribuir a reducir el alcance de ciertos fallos y a simplificar la conexión privada entre dos plataformas rivales. Su utilidad será mayor para las organizaciones que mantengan aplicaciones y datos preparados en ambas, definan cómo dirigir el tráfico y hayan comprobado que la recuperación funciona. Sin ese trabajo, el enlace permanece disponible, pero no necesariamente hay un servicio alternativo listo para ocupar su lugar.

La vista previa iniciada el 1 de diciembre de 2025, las regiones y capacidades anunciadas y la posible ampliación a Azure durante 2026 dibujan una infraestructura más coordinada. El avance no elimina la concentración de servicios ni los errores de software, los fallos regionales o las dependencias compartidas. Sí puede ofrecer a las empresas una ruta más sencilla para diversificar y una oportunidad para ensayar una recuperación entre nubes que antes exigía más trabajo a medida.

El cambio de fondo es menos espectacular que la promesa de una Internet inmune a las averías, pero más útil: cuando una pieza falle, algunas organizaciones podrán contar con un camino alternativo mejor preparado. Que eso se traduzca en una página disponible o en una caída más breve dependerá de lo que haya detrás del enlace. La alianza no evita todos los apagones; puede impedir que algunos problemas se conviertan en una interrupción mayor.