Amazon Web Services sometió este sábado 24 de octubre a su nube soberana europea a una situación poco habitual para un proveedor cuya principal ventaja competitiva procede precisamente de la escala y la interconexión de su infraestructura mundial. Durante varias horas, AWS European Sovereign Cloud debía operar sin conexión a la red troncal privada global de la compañía y con determinados intercambios de información operativa con sistemas exteriores a la Unión Europea completamente desactivados, una prueba diseñada para demostrar que la plataforma puede mantener su funcionamiento sin depender de recursos críticos situados fuera del territorio comunitario.
A 25 de octubre, AWS todavía no había publicado resultados técnicos detallados sobre el desarrollo del ejercicio. La compañía había adelantado que compartiría posteriormente una actualización con clientes y reguladores, por lo que aún falta conocer si la desconexión se produjo exactamente según lo previsto, qué incidencias aparecieron durante los cambios de ruta y qué evidencias obtuvo el equipo responsable. Esa ausencia de resultados limita cualquier conclusión sobre la ejecución concreta de la prueba, pero no impide analizar su alcance, porque AWS había definido de antemano con bastante precisión qué quería demostrar y, sobre todo, qué dimensiones de la soberanía quedaban fuera.
El interés del ejercicio está precisamente ahí. La nube soberana se está desplazando desde una discusión centrada casi exclusivamente en la ubicación física de los datos hacia un modelo mucho más exigente, en el que cuentan también quién opera la infraestructura, qué sistemas externos necesita, bajo qué jurisdicciones se encuentran las entidades que la controlan y qué capacidad tiene una organización para seguir funcionando cuando desaparecen determinadas dependencias. La Unión Europea ya está intentando traducir ese concepto a criterios comparables mediante su Cloud Sovereignty Framework, que distribuye la evaluación entre 48 requisitos agrupados en ocho ámbitos diferentes, desde la autonomía operativa hasta la soberanía jurídica, tecnológica, estratégica o de cadena de suministro.
La desconexión realizada por AWS encaja de forma directa en una de esas dimensiones. También sirve para comprobar hasta qué punto una prueba técnica, por ambiciosa que sea, puede acreditar solo una parte de una promesa de soberanía mucho más amplia.
Qué desconectó realmente AWS
La prueba requiere cierta precisión porque AWS European Sovereign Cloud no se quedó aislada de Internet ni dejó de ofrecer conectividad exterior. Lo que AWS retiró durante varias horas fue la conexión con AWS Global Network, la red privada que enlaza las distintas ubicaciones del proveedor y permite transportar determinados datos operativos entre ellas sin recurrir a Internet pública. Durante el ejercicio, el tráfico debía utilizar exclusivamente conexiones proporcionadas por operadores europeos de Internet, manteniendo así la conectividad con el exterior sin apoyarse en la red troncal privada global de AWS.
La compañía había advertido de que podían producirse breves interrupciones de conectividad al principio y al final de la maniobra, cuando las distintas redes actualizasen sus rutas para reflejar el cambio de camino. Ese proceso de convergencia forma parte del comportamiento normal de Internet y no implicaba, según AWS, una pérdida general de disponibilidad de los servicios. Tampoco estaba previsto que la prueba afectara al resto de regiones del proveedor ni a las conexiones privadas mediante AWS Direct Connect.
Más relevante desde el punto de vista de la autonomía era la segunda desconexión prevista. En funcionamiento ordinario, AWS European Sovereign Cloud dispone de un sistema específico para gestionar determinadas transferencias limitadas de información operativa fuera de la UE. AWS sostiene que ese mecanismo no transporta contenido de clientes ni metadatos creados por ellos y que permanece bajo control y supervisión del equipo europeo. Entre sus funciones figuran la recepción de código fuente previamente validado, actualizaciones de software y el intercambio de una cantidad reducida de información rutinaria necesaria para determinadas operaciones corporativas.
Durante la prueba, ese sistema también debía quedar completamente desactivado. El equipo operativo, formado por residentes de la UE y situado dentro del territorio comunitario, debía gestionar el ejercicio utilizando exclusivamente el hardware, el software y los recursos disponibles dentro de AWS European Sovereign Cloud. La infraestructura mantiene además una copia local del código fuente que, según la compañía, permite continuar operando aunque desaparezcan los vínculos con sistemas externos. (aws.amazon.com)
El alcance, por tanto, estaba claramente delimitado: AWS quería demostrar que dos sistemas utilizados en la operación ordinaria, aunque aporten ventajas de rendimiento, seguridad o eficiencia, no son dependencias críticas para mantener activa la plataforma europea.
De la residencia del dato a la autonomía operativa
Durante buena parte de la última década, el debate europeo sobre soberanía cloud estuvo estrechamente ligado a la residencia de los datos. La pregunta principal era dónde se almacenaba la información y si podía garantizarse que permaneciera dentro de las fronteras de la Unión Europea. Ese criterio continúa siendo relevante, especialmente en sectores regulados, pero las arquitecturas cloud actuales han hecho evidente que la localización física explica solo una parte de la dependencia tecnológica.
Una aplicación desplegada en Frankfurt puede almacenar todos sus datos dentro de Alemania y, al mismo tiempo, depender de sistemas de identidad gestionados desde otro país, herramientas administrativas comunes al conjunto del proveedor, repositorios de software externos, equipos de soporte situados fuera de la UE o plataformas corporativas compartidas. También puede necesitar servicios de control, monitorización o actualización que no forman parte del entorno local aunque la carga de trabajo y sus datos sí permanezcan físicamente allí.
AWS ha diseñado European Sovereign Cloud alrededor de esa objeción. La infraestructura opera como una partición separada de las regiones comerciales convencionales de AWS y dispone de componentes propios para funciones críticas de administración. Entre ellos se encuentran servicios específicos de identidad, consola, endpoints y gestión operativa, con una arquitectura pensada para reducir la necesidad de recurrir a sistemas globales.
Los centros de datos están física y lógicamente separados del resto de regiones de la compañía, mientras que AWS afirma que el contenido de los clientes y los metadatos creados por ellos permanecen dentro de la Unión Europea. La operación cotidiana también está restringida a personal residente en la UE, lo que añade una capa de control administrativo que va más allá de la mera localización de servidores.
Este diseño responde a una necesidad cada vez más visible entre administraciones públicas, bancos, aseguradoras, operadores de infraestructuras críticas y otras organizaciones sometidas a requisitos estrictos de continuidad y cumplimiento. Para ellas, saber dónde reside una base de datos ya no basta si no pueden determinar quién tiene capacidad para administrar los sistemas, qué recursos externos son imprescindibles, qué dependencias aparecen durante un incidente o qué ocurriría si una infraestructura situada fuera de Europa dejara de estar disponible.
El ejercicio del 24 de octubre intenta convertir una parte de esas garantías arquitectónicas en evidencia observable. Si la plataforma permaneció operativa cuando desaparecieron las conexiones previstas, AWS podrá demostrar que determinadas dependencias globales no resultan críticas para mantener el servicio. Si durante la prueba aparecieron llamadas inesperadas a sistemas externos, problemas de enrutamiento o limitaciones operativas, esos hallazgos también serían relevantes porque permitirían identificar dependencias que una revisión teórica de la arquitectura podría no haber detectado.
Europa empieza a convertir la soberanía en un criterio medible
La capacidad de aportar evidencias adquiere más importancia a medida que la soberanía deja de ser una etiqueta comercial y empieza a incorporarse a procesos formales de contratación tecnológica. La Comisión Europea ha desarrollado un Cloud Sovereignty Framework que evita tratar el concepto como una condición binaria y propone, en su lugar, evaluar diferentes grados de autonomía según múltiples dimensiones.
El modelo utiliza los denominados Sovereignty Effectiveness Assurance Levels, o SEAL, junto con una puntuación basada en 48 criterios. Esos criterios se distribuyen entre ocho objetivos: soberanía estratégica; legal y jurisdiccional; de datos e inteligencia artificial; operativa; de cadena de suministro; tecnológica; de seguridad y cumplimiento; y sostenibilidad medioambiental.
La separación entre categorías resulta importante porque impide asumir que una única característica puede resolver toda la discusión. Un proveedor puede disponer de una infraestructura técnicamente aislada dentro de Europa y, al mismo tiempo, presentar un perfil distinto cuando se analiza su estructura corporativa, las jurisdicciones a las que está sujeto o el origen de determinados componentes tecnológicos. Del mismo modo, una compañía europea por propiedad y gobierno corporativo puede depender de hardware, software o servicios críticos desarrollados y controlados desde terceros países.
AWS ha vinculado expresamente el ejercicio del 24 de octubre con esta forma de evaluar la soberanía. La compañía asegura que pretende generar evidencia alineada con los objetivos del marco de la Comisión y con los criterios C3A de la Oficina Federal de Seguridad de la Información alemana, dos iniciativas que intentan trasladar conceptos amplios de autonomía a controles que puedan revisarse y documentarse.
La relación entre estos marcos y la contratación pública ya es tangible. En abril de 2026, la Comisión adjudicó contratos por 180 millones de euros para facilitar a instituciones, organismos y agencias europeas el acceso a servicios cloud soberanos, utilizando criterios que incorporan esta visión multidimensional de la soberanía.
Para el mercado, el cambio es relevante porque desplaza el debate desde las declaraciones del proveedor hacia requisitos que pueden aparecer en una licitación, una auditoría o una evaluación de riesgos. Una organización puede empezar a exigir evidencias concretas sobre quién administra la plataforma, qué sistemas exteriores necesita, cómo se gestionan las actualizaciones, qué jurisdicciones tienen capacidad efectiva de intervención o cuánto tiempo podría mantenerse el servicio si desapareciera una determinada dependencia.
Qué puede demostrar una desconexión de varias horas
Una prueba controlada como la realizada por AWS permite responder a cuestiones técnicas muy concretas. Puede comprobar si los servicios continúan funcionando al eliminar una conexión considerada prescindible, si existen comunicaciones inesperadas con sistemas exteriores, si el personal europeo dispone de todas las herramientas necesarias para mantener la plataforma y cómo responde la conectividad cuando una red privada global es sustituida temporalmente por enlaces públicos proporcionados por operadores europeos.
También puede generar registros, métricas y trazas que después revisen clientes, auditores o reguladores, algo especialmente relevante en un mercado en el que las garantías de soberanía empiezan a necesitar respaldo documental. AWS está construyendo alrededor de European Sovereign Cloud una capa adicional de aseguramiento mediante su Sovereign Reference Framework, que vincula criterios de soberanía con controles técnicos y operativos y prevé mecanismos de validación independientes.
Para una organización regulada, ese nivel de trazabilidad resulta mucho más útil que una declaración genérica de independencia. Un responsable de riesgos puede incorporar controles documentados a sus propios procedimientos internos, mientras que un auditor puede analizar qué mecanismos concretos sustentan cada garantía.
El alcance temporal del ejercicio, sin embargo, establece una frontera clara. Varias horas sin determinados sistemas globales permiten comprobar continuidad operativa durante ese periodo, pero no reproducen un escenario de aislamiento prolongado durante semanas o meses. En una situación de larga duración entrarían en juego otras variables, entre ellas la distribución de parches, la evolución del software, la respuesta ante nuevas vulnerabilidades, la sustitución de componentes, el acceso a conocimiento especializado y la continuidad de la cadena de suministro.
AWS reconoce que European Sovereign Cloud utiliza normalmente AWS Global Network porque esa infraestructura aporta ventajas de rendimiento, capacidad, seguridad, fiabilidad y costes. La posibilidad de operar temporalmente sin ella demuestra resiliencia frente a una determinada dependencia, pero no significa que una operación permanente bajo esas mismas condiciones ofreciera idénticos niveles de servicio o eficiencia.
Esta diferencia importa para cualquier empresa que evalúe una oferta de nube soberana. Poder continuar funcionando durante una contingencia y disponer de autonomía tecnológica completa a largo plazo son propiedades distintas y requieren evidencias diferentes.
La jurisdicción queda fuera del alcance del experimento
La dimensión jurídica introduce un límite todavía más evidente, porque ningún ejercicio de conectividad puede resolver por sí mismo cómo respondería un proveedor ante obligaciones legales contradictorias entre distintas jurisdicciones.
El debate afecta especialmente a compañías tecnológicas estadounidenses por el alcance del CLOUD Act. La legislación establece que determinados proveedores sometidos a jurisdicción de Estados Unidos deben responder a requerimientos legales válidos respecto a información que se encuentre bajo su «posesión, custodia o control», incluso cuando esa información esté almacenada fuera del país. Así lo describe el propio Departamento de Justicia estadounidense en su documentación sobre la norma.
La expresión «posesión, custodia o control» resulta esencial porque evita reducir la discusión a la nacionalidad del proveedor o al país en el que se encuentra físicamente un servidor. La estructura corporativa, los permisos administrativos, la capacidad efectiva de acceder a los sistemas, los mecanismos criptográficos y las obligaciones aplicables a cada entidad condicionan el análisis.
AWS ha intentado limitar parte de ese riesgo mediante una estructura de gobierno específica para European Sovereign Cloud, con administradores europeos, controles locales, servicios separados y restricciones sobre quién puede ejecutar determinadas operaciones. También mantiene el compromiso de que el contenido de los clientes y los metadatos creados por ellos permanezcan dentro de la UE.
Estas medidas pueden reducir las situaciones en las que una entidad externa dispone de control técnico efectivo sobre los datos, pero la desconexión del 24 de octubre no estaba diseñada para demostrar cómo se resolvería un eventual conflicto legal. El propio marco europeo trata la soberanía operativa y la legal y jurisdiccional como categorías diferentes, lo que impide extrapolar el éxito de una prueba técnica al conjunto de las garantías de soberanía.
La autonomía tecnológica se mide también en el tiempo
Otro límite aparece cuando se observa la dependencia tecnológica con una perspectiva más larga. European Sovereign Cloud utiliza tecnología desarrollada por AWS y buena parte de su atractivo para los clientes reside precisamente en mantener compatibilidad con servicios, APIs y modelos de operación conocidos. Esa continuidad puede reducir costes de migración y aprendizaje, pero también vincula la plataforma a la evolución tecnológica del proveedor.
AWS asegura que mantiene dentro de la Unión Europea los recursos necesarios para operar la infraestructura de forma independiente y que dispone de una copia local del código fuente. Durante la prueba se desactivó además el sistema utilizado, entre otras funciones, para recibir código validado y actualizaciones de software.
Durante unas horas, esa dependencia tiene una relevancia limitada. En periodos mucho más prolongados, la situación sería distinta porque mantener una plataforma cloud implica corregir vulnerabilidades, evolucionar servicios, actualizar componentes y responder a nuevas amenazas. La autonomía deja entonces de consistir únicamente en conservar la infraestructura encendida y pasa a depender de la capacidad para mantenerla técnicamente vigente.
El factor temporal introduce así una diferencia que las empresas deberían incorporar a sus evaluaciones. Una arquitectura capaz de continuar prestando servicio durante una interrupción ofrece una garantía concreta de resiliencia; una infraestructura capaz de evolucionar durante un periodo indefinido sin recurrir a tecnología, conocimiento o componentes externos exigiría un grado de autonomía mucho mayor. El marco europeo intenta capturar precisamente esta diferencia al separar soberanía operativa, tecnológica y de cadena de suministro.
De la etiqueta «soberana» a una evaluación de riesgos
La principal consecuencia para las empresas es que la expresión «nube soberana» empieza a perder utilidad como categoría autosuficiente. La decisión relevante para un CIO, un CISO o un responsable de cumplimiento consiste en determinar qué dimensiones de soberanía necesita cada carga de trabajo y qué controles permiten demostrar que esas condiciones se cumplen.
Una administración que gestione información especialmente sensible puede exigir residencia completa, operación europea, restricciones jurisdiccionales y un grado elevado de autonomía tecnológica. Una empresa industrial puede considerar prioritarias la continuidad de servicio, el control de las claves de cifrado y la capacidad de mantener operaciones en caso de interrupción externa. Otra organización puede aceptar determinadas dependencias globales si obtiene a cambio acceso a un catálogo más amplio de servicios, mejores prestaciones o menores costes.
La lógica del Cloud Sovereignty Framework europeo encaja con esa diversidad porque permite evaluar niveles y dimensiones diferentes en lugar de imponer una definición única de soberanía para todas las cargas de trabajo.
También modifica las exigencias que los clientes pueden trasladar a sus proveedores. Junto a contratos y descripciones de arquitectura, empiezan a cobrar importancia las pruebas de continuidad, los informes de auditoría, los mapas de dependencias, los mecanismos de control administrativo y las evidencias sobre la procedencia y gestión de componentes críticos.
AWS ha dado un paso relevante al someter públicamente una de sus afirmaciones de autonomía a una desconexión deliberada. Todavía falta conocer el resultado detallado del ejercicio y, sobre todo, qué información estará disponible para clientes, auditores y reguladores, porque será esa documentación la que determine hasta qué punto la prueba puede incorporarse a procesos reales de cumplimiento y evaluación de riesgo.
Para las empresas europeas, el ejercicio del 24 de octubre deja mientras tanto una referencia útil: la soberanía cloud se está convirtiendo en una propiedad compuesta por controles diferenciados que deben poder demostrarse de forma independiente. La localización de los datos sigue formando parte de la ecuación, pero las decisiones sobre infraestructura dependerán cada vez más de saber quién controla los sistemas, de qué recursos externos dependen, durante cuánto tiempo podrían operar sin ellos y qué jurisdicciones conservan capacidad efectiva de intervención.
