Los centros de datos de AWS en Oriente Medio perdieron datos de clientes tras los ataques, quebrando el modelo de resiliencia regional
AWS ha comunicado a sus clientes que los datos almacenados exclusivamente en dos ubicaciones dañadas no pueden recuperarse, más de seis meses después de que ataques iraníes alcanzaran su infraestructura. La admisión transforma la crisis de los centros de datos de AWS en Oriente Medio, que pasó de ser una interrupción prolongada a un evento permanente de pérdida de datos.
La infraestructura afectada incluye toda la región de Oriente Medio (Bahréin) y una Zona de disponibilidad en la región de los EAU. Amazon Web Services había instado anteriormente a los clientes a migrar los recursos accesibles y restaurar las cargas de trabajo no disponibles desde copias de seguridad remotas.
AWS afirma ahora que agotó sus opciones de recuperación para los recursos que los clientes no habían trasladado antes de que la infraestructura dejara de estar disponible. Ha ofrecido apoyo para la migración, pero no un calendario para restaurar la región afectada de Bahréin o la zona de los EAU.
El cambio es relevante porque las regiones de nube se comercializan en torno a la separación física y la redundancia. Los clientes siguen controlando la arquitectura de sus aplicaciones, pero el proveedor opera los edificios, los sistemas eléctricos, las redes y el hardware de almacenamiento que la sustentan.
Esa división de responsabilidades funcionó hasta que ataques físicos coordinados afectaron varios centros dentro del mismo teatro geográfico. Los ataques revelaron un riesgo que la planificación convencional de disponibilidad no estaba diseñada para absorber: una campaña militar sostenida contra infraestructura comercial de nube.
Para bancos, servicios de pago, organismos gubernamentales y empresas de software, la lección práctica es incómoda. Varias Zonas de disponibilidad dentro de una región no equivalen a un entorno de recuperación independiente fuera de esa región.
Los centros de datos de AWS en Oriente Medio han pasado de afectados a irrecuperables
AWS ya no describe todos los recursos afectados como retrasados o temporalmente inaccesibles. Algunos datos de clientes se consideran ahora irrecuperables.
AWS reveló la última evaluación el 15 de septiembre, según informaciones regionales y los avisos de estado del servicio de la empresa. Sus ingenieros habían examinado las instalaciones dañadas mientras intentaban recuperar recursos que nunca se replicaron en otro lugar.
La compañía señaló que no pudo restaurar el acceso a los recursos y datos alojados exclusivamente en la región de Bahréin. Llegó a la misma conclusión para los recursos confinados a la Zona de disponibilidad mec1-az2 afectada en los EAU.
Una Zona de disponibilidad es una ubicación de infraestructura aislada dentro de una región de AWS. Las aplicaciones pueden distribuir las cargas de trabajo entre varias zonas para reducir su dependencia de una sola instalación.
Las regiones de AWS normalmente contienen al menos tres zonas. Están separadas por una distancia física significativa, pero siguen lo bastante cerca como para admitir conexiones de baja latencia.
Esa estructura protege frente a muchos fallos, incluidos defectos de equipos, interrupciones eléctricas y desastres localizados. No garantiza la supervivencia cuando varias instalaciones afrontan ataques coordinados o una disrupción regional prolongada.
Los ataques iniciales se produjeron el 1 de marzo. AWS indicó que dos instalaciones de los EAU fueron alcanzadas directamente, mientras que un ataque con drones cercano afectó físicamente a infraestructura en Bahréin.
Los ataques provocaron daños estructurales e interrumpieron el suministro eléctrico. Las labores de extinción también produjeron daños por agua en algunas instalaciones, según las actualizaciones de la empresa.
Dos de las tres Zonas de disponibilidad de la región de los EAU quedaron gravemente afectadas. Una instalación de Bahréin se vio afectada inicialmente, pero ataques posteriores y la inestabilidad regional agravaron la disrupción.
Las interrupciones afectaron servicios esenciales, incluidos la computación EC2, el almacenamiento S3, las funciones sin servidor Lambda, las bases de datos DynamoDB y la AWS Management Console. Varios bancos y plataformas de consumo informaron de problemas de servicio.
AWS describió inicialmente la recuperación como gradual debido a los daños físicos. También aconsejó a los clientes activar sus planes de recuperación ante desastres y migrar las cargas de trabajo fuera de las regiones afectadas.
La conclusión más reciente cierra la vía de recuperación para los datos que existían únicamente en la infraestructura destruida o inaccesible. AWS Support sigue disponible para orientar a los clientes hacia regiones alternativas.
La distinción entre restaurar el servicio y restaurar los datos es fundamental. AWS puede reparar o reemplazar edificios con el tiempo sin reconstruir información de clientes que no tenía ninguna copia superviviente.
Ese resultado da un significado diferente al plazo de seis meses. La demora no fue simplemente una ventana de reparación extendida. También fue una investigación prolongada para determinar si podían recuperarse los medios de almacenamiento y la infraestructura.
AWS afirma que esa investigación ha agotado ya todas las opciones disponibles. Por tanto, su aviso regional de recuperación representa un juicio técnico definitivo para los recursos afectados, no otra estimación provisional de interrupción.
La información original describía a AWS dirigiendo a los clientes hacia infraestructura más segura en otros lugares. La conclusión más firme y verificada es que la migración es obligatoria para los clientes afectados que quieran reanudar sus operaciones.
Algunas cargas de trabajo en los EAU siguen funcionando, y no se ha declarado la pérdida permanente de toda la región de los EAU. Sin embargo, AWS aún no puede respaldar de forma fiable las aplicaciones normales de los clientes en toda la huella regional dañada.
La situación de Bahréin es más grave. Los recursos alojados exclusivamente allí ya no están a la espera de restauración. Los clientes deben reconstruirlos a partir de copias conservadas en otro lugar, suponiendo que esas copias existan.
Por qué la redundancia regional falló ante un ataque coordinado
AWS diseñó las Zonas de disponibilidad para aislar fallos habituales de infraestructura, pero los ataques generaron una amenaza que atravesó esos límites de aislamiento.
La arquitectura de nube suele dividir los fallos en unidades gestionables. Un servidor puede fallar sin derribar su rack, mientras que un rack puede fallar sin inutilizar una instalación completa.
Las Zonas de disponibilidad extienden esa lógica a varias instalaciones. Utilizan sistemas separados de alimentación, refrigeración y red, lo que reduce la probabilidad de que un problema operativo alcance todas las copias de una aplicación.
Sin embargo, las zonas dentro de la misma región siguen conectadas geográficamente. AWS afirma que, por lo general, se encuentran a menos de 100 kilómetros entre sí porque los clientes requieren redes privadas y rápidas entre ellas.
Esa proximidad aporta ventajas de rendimiento. También significa que varias zonas pueden permanecer expuestas al mismo conflicto, espacio aéreo, sistema de servicios públicos o crisis política.
Los ataques de marzo ilustraron ese límite. Dos de las tres zonas de los EAU quedaron afectadas durante la misma campaña, mientras que la infraestructura regional de Bahréin también sufrió daños.
No se trató del patrón de fallo habitual de un despliegue de software, un error de configuración o un componente de red defectuoso. Fue destrucción física seguida de riesgos de seguridad continuados y condiciones de recuperación restringidas.
AWS reconoció que el entorno operativo más amplio seguía siendo impredecible incluso mientras avanzaban las tareas de reparación. Esa incertidumbre puede afectar al acceso del personal, los equipos de sustitución, la restauración eléctrica y los calendarios de construcción.
Los equipos de emergencia también afrontan prioridades que van más allá de recuperar hardware de nube. Los incendios, la inestabilidad estructural y las armas sin explotar pueden convertir una reparación técnica en una operación de seguridad.
El sector suele describir las Zonas de disponibilidad como físicamente separadas. Los clientes pueden interpretar razonablemente ese lenguaje como protección frente a un desastre a nivel de instalación.
La arquitectura funcionó según lo previsto solo cuando las cargas de trabajo se distribuyeron entre infraestructura que sobrevivió. No pudo preservar los recursos almacenados exclusivamente dentro de una zona inaccesible.
AWS documenta un modelo de responsabilidad compartida en el que la empresa protege la nube subyacente, mientras los clientes protegen y configuran lo que ejecutan dentro de ella. La recuperación ante desastres se sitúa a ambos lados de esa frontera.
Amazon opera los centros de datos físicos y los servicios regionales. Los clientes deciden si replicar bases de datos, copias de seguridad, imágenes de aplicaciones, claves de cifrado y dependencias de identidad en otras regiones.
Los ataques no eliminaron esa división. Mostraron hasta qué punto sus consecuencias se vuelven costosas cuando un fallo regional se mide en meses en lugar de horas.
Una empresa podría ejecutar una aplicación en tres zonas y considerar razonablemente que tiene alta disponibilidad. Ese diseño aún carece de recuperación geográfica si todos sus datos persistentes permanecen dentro de una región.
La replicación entre regiones aborda este riesgo al mantener una copia utilizable en otra región geográfica. Puede aumentar la latencia, los cargos de red, la complejidad operativa y la exposición regulatoria.
Esas compensaciones explican por qué las organizaciones a veces mantienen los datos en el ámbito local. Las instituciones financieras y los organismos públicos pueden enfrentarse a normas de residencia de datos que limitan dónde puede viajar la información de los clientes.
La baja latencia también importa para los pagos, las operaciones bursátiles, las comunicaciones y los servicios interactivos. Una región de recuperación distante puede preservar la disponibilidad al tiempo que reduce el rendimiento de la aplicación.
Antes de los ataques, algunas organizaciones podían considerar esos costes como motivos para posponer un despliegue multirregional. La pérdida permanente de datos cambia ese cálculo.
La primera evaluación de los ataques señaló que los daños produjeron una disrupción localizada, en lugar de mundial. Ese radio de impacto limitado fue positivo para la red global de AWS.
Fue un escaso consuelo para los clientes cuya única copia de un recurso se encontraba dentro de la infraestructura dañada. La escala global de la nube no crea automáticamente resiliencia global para las aplicaciones.
Un cliente obtiene ese beneficio solo después de configurar réplicas, copias de seguridad, credenciales, rutas de red y procedimientos de recuperación más allá de la región principal. El proveedor no puede inferir ni crear esas copias de forma retroactiva.
El cambio fundamental está entre la resiliencia de la nube y la concentración geográfica
La nube sacó los servidores de las oficinas de los clientes, pero no los sacó de la geografía, la política o la guerra.
Los centros de datos de AWS en Oriente Medio ampliaron el acceso a computación de baja latencia y almacenamiento local de datos en todo el Golfo. Esas ventajas animaron a las organizaciones a mantener cargas de trabajo importantes más cerca de los usuarios regionales.
Los ataques invirtieron esa propuesta de valor para los clientes afectados. La proximidad, antes una ventaja de cumplimiento normativo y rendimiento, se convirtió en un riesgo compartido de concentración.
Esto no significa que la computación en la nube sea intrínsecamente menos resiliente que la infraestructura privada. Pocas empresas individuales podrían operar instalaciones mejor protegidas o recuperar hardware dañado con mayor rapidez que un proveedor de hiperescala.
El problema reside en confundir la escala de la infraestructura con la distribución de las cargas de trabajo. AWS puede operar cientos de instalaciones sin distribuir automáticamente los datos de cada cliente entre ellas.
El cliente elige dónde se ejecuta una base de datos. También determina si sus copias de seguridad salen de la región y si las aplicaciones pueden iniciarse en otra ubicación.
Esto genera un incómodo conflicto entre promesa y realidad. La nube simplifica el acceso a infraestructura redundante, pero los clientes aún deben construir la arquitectura que la utilice de forma segura.
Los despliegues multizona resuelven una clase importante de problemas. No sustituyen la recuperación multirregional cuando la amenaza puede alcanzar varias instalaciones cercanas.
La distinción se entendía antes de marzo, pero a menudo parecía teórica. Las interrupciones de la nube solían terminar después de que los ingenieros corrigieran fallos de software, enrutamiento, alimentación eléctrica o refrigeración.
La destrucción física cambia el límite de la recuperación. Los equipos de almacenamiento dañados pueden no volver nunca, independientemente de cuánto tiempo los ingenieros los investiguen.
El incidente de AWS también muestra por qué las copias de seguridad necesitan su propio límite de fallo. Una copia de seguridad almacenada en la misma región afectada puede desaparecer junto con la carga de trabajo de producción.
Las copias útiles para la recuperación deben ser accesibles sin depender de la región dañada. También necesitan credenciales probadas, claves de cifrado, configuraciones de red y dependencias de aplicaciones.
Una copia de la base de datos por sí sola podría no restaurar un servicio. Los equipos también necesitan definiciones de infraestructura, imágenes de contenedores, paquetes de software, controles de dominio y sistemas de monitorización.
Es probable que las organizaciones que se recuperaron rápidamente hubieran preparado estos elementos antes de los ataques. Los equipos que solo tenían réplicas locales descubrieron que la redundancia técnica y la resiliencia geográfica son productos distintos.
La actualización de seis meses sitúa esa brecha en el centro de la historia. AWS no ofrece un regreso a la normalidad a corto plazo para las ubicaciones inaccesibles.
En cambio, está ayudando a los clientes a trasladarse a regiones operativas. Europa, Estados Unidos y Asia Pacífico figuraban entre las alternativas identificadas en orientaciones anteriores.
Cada elección introduce nuevas limitaciones. Las regiones europeas pueden ofrecer menor latencia que las ubicaciones norteamericanas, pero las normas legales y sectoriales específicas siguen requiriendo revisión.
Trasladar una aplicación también modifica las rutas de red, las dependencias de fallo y los procedimientos operativos. Los clientes deben confirmar que los sistemas de identidad, seguridad y observabilidad funcionen desde el entorno de recuperación.
También deben decidir si la reubicación es temporal. Reconstruir en el Golfo podría recuperar las ventajas de latencia y soberanía de datos, pero reintroduciría la misma exposición geopolítica.
Por eso el evento es más que una lección sobre recuperación ante desastres. Cuestiona la suposición de que una región de nube reparada recupera naturalmente su valor estratégico previo.
Los clientes ahora saben que la infraestructura ha sido atacada deliberadamente. Deben evaluar no solo si AWS puede reconstruirla, sino si los atacantes pueden volver a atacarla.
Los medios estatales iraníes y fuentes vinculadas al ejército describieron la infraestructura tecnológica como parte del conjunto de objetivos durante el conflicto. AWS no confirmó las afirmaciones sobre la justificación militar de instalaciones específicas.
Los centros de datos comerciales pueden alojar a miles de clientes no relacionados. Tratarlos como objetivos vinculados al ámbito militar transfiere el riesgo del conflicto a bancos, minoristas, empresas de logística, proveedores de software y usuarios comunes.
Los competidores de AWS afrontan la misma exposición subyacente. Microsoft, Google, Oracle y los operadores regionales dependen todos de instalaciones identificables, conexiones eléctricas, rutas de fibra y sistemas de refrigeración.
Cambiar de proveedor dentro de la misma zona de amenaza geográfica no resuelve automáticamente el problema. Una región de nube competidora puede reducir la dependencia de un proveedor, pero seguir expuesta a riesgos militares similares.
La alternativa más sólida es una recuperación geográfica independiente. Puede implicar otra región de AWS, un proveedor de nube distinto, infraestructura privada o una combinación de las tres.
El diseño adecuado depende de los límites regulatorios y de la tolerancia empresarial. El incidente no ofrece un destino universal, pero hace más difícil defender la dependencia de una única presencia regional.
Las instalaciones subterráneas abordan solo una parte del riesgo
Ubicar los centros de datos bajo tierra puede reducir la exposición a drones, pero los edificios reforzados no pueden resolver todas las dependencias que rodean a una región de nube.
Los ataques contra AWS han reavivado el debate sobre centros de datos reforzados y subterráneos en el Golfo. La construcción subterránea puede proporcionar protección física y, al mismo tiempo, ofrecer posibles ventajas de refrigeración.
Este enfoque no sustituye rápidamente a la infraestructura dañada. La excavación, el refuerzo estructural, la ventilación, el drenaje, el control de incendios y el acceso seguro plantean exigentes requisitos de ingeniería.
Los centros de datos también consumen enormes cantidades de electricidad. Una sala de computación subterránea sigue dependiendo de generación, subestaciones, combustible, líneas de transmisión y energía de respaldo.
Los atacantes no necesitan penetrar cada sala de servidores si pueden interrumpir la electricidad que la alimenta. Las fuentes de energía redundantes ayudan, pero un conflicto regional puede amenazar varias fuentes a la vez.
La conectividad presenta otra limitación. Las instalaciones en la nube dependen de fibra terrestre, interconexiones de operadores y rutas de cables submarinos que no pueden permanecer íntegramente dentro de estructuras reforzadas.
Los sistemas de refrigeración también requieren equipos y energía externos. La ubicación subterránea puede moderar las condiciones ambientales, pero la computación de alta densidad sigue generando calor que debe salir de la instalación.
Las entradas, los conductos de ventilación, las zonas de carga y las rutas de red siguen siendo posibles puntos débiles. Un edificio reforzado modifica la superficie de ataque sin volver invulnerable al servicio.
Los Emiratos Árabes Unidos también deben sopesar el coste de construcción frente a la capacidad utilizable. Los proveedores de nube necesitan grandes campus que puedan ampliarse a medida que crece la demanda, especialmente para cargas de trabajo de inteligencia artificial.
Una instalación tipo búnker puede ser adecuada para determinados sistemas críticos. Replicar bajo tierra una capacidad a escala hiperescalar requeriría un programa de construcción e infraestructura mucho más amplio.
Por tanto, la cuestión estratégica no es si los centros de datos subterráneos son útiles. Es qué cargas de trabajo justifican la protección adicional y qué dependencias requieren defensas independientes.
Las ambiciones de nube del Golfo no han desaparecido. Los gobiernos y las empresas tecnológicas siguen considerando importante la capacidad informática regional para la IA, los servicios digitales y la diversificación económica.
Sin embargo, el modelo de riesgo ha cambiado. Los nuevos proyectos deben tener en cuenta ataques deliberados, no solo el calor, la disponibilidad de agua, los fallos de equipos y las interrupciones accidentales.
Un análisis regional de políticas identificó la ubicación subterránea como una opción que ya se estaba considerando. También señaló el posible atractivo de lugares más alejados de Irán.
La distancia puede reducir la exposición a algunas armas y presiones estratégicas. No puede garantizar la seguridad durante un conflicto más amplio que involucre misiles, drones, fuerzas intermediarias o sabotaje de infraestructura.
Las defensas aéreas activas ofrecen otra capa, pero las instalaciones comerciales pasarían entonces a depender de protección militar. Esa relación podría difuminar aún más la línea entre infraestructura civil y estratégica.
Las aseguradoras y los clientes plantearán preguntas similares. Un proveedor puede reforzar un emplazamiento, pero los compradores aún necesitan pruebas de que todo el servicio puede sobrevivir a los fallos a su alrededor.
Esas pruebas deberían incluir diversidad energética, diversidad de red, acceso para reparaciones, replicación entre regiones y pruebas de recuperación realistas. Los diagramas de arquitectura por sí solos no pueden demostrar resiliencia en tiempos de guerra.
La visión escéptica es que la construcción subterránea puede convertirse en un símbolo visible sin resolver la concentración operativa. Los servidores reforzados siguen siendo vulnerables si sus líneas vitales externas convergen.
Tampoco existe un calendario público de AWS para reconstruir la capacidad regional perdida. La empresa no ha detallado si las instalaciones de sustitución utilizarán diseños subterráneos o significativamente reforzados.
Esa ausencia no prueba que AWS carezca de un plan. Las preocupaciones de seguridad harían poco probables las divulgaciones públicas detalladas sobre nuevas instalaciones y medidas defensivas.
Por tanto, los clientes se enfrentan a decisiones antes de que la hoja de ruta de infraestructura quede clara. Esperar una región de Bahréin reparada no es una estrategia de recuperación cuando AWS afirma que los recursos exclusivos no pueden restaurarse.
La suposición inmediata más segura es que los datos inaccesibles seguirán siendo inaccesibles. Las futuras instalaciones deben evaluarse como nueva capacidad, no como una vía para recuperar esos recursos perdidos.
Tres señales mostrarán si AWS puede reconstruir la confianza
La próxima prueba no es un anuncio de construcción. Es si AWS puede proporcionar capacidad recuperable, protección creíble y una razón para que los clientes regresen.
La primera señal es un plan específico de restauración regional. Los clientes necesitan saber si AWS pretende reabrir Bahréin, sustituir la capacidad dañada en los EAU o rediseñar su presencia en el Golfo.
Un plan útil distinguiría entre restaurar servicios disponibles y sustituir infraestructura perdida. También explicaría qué servicios regresan primero y cómo han cambiado las dependencias regionales.
Si AWS publica un calendario creíble, demostraría que la reconstrucción ha avanzado más allá de la evaluación. El silencio continuado reforzaría la migración como la única suposición operativa fiable.
La segunda señal es el comportamiento de los clientes. Bancos, empresas de pagos, organismos públicos y grandes plataformas de software revelarán si la confianza regresa mediante sus decisiones de despliegue.
Una región reparada puede seguir debilitada comercialmente si los principales clientes mantienen sus sistemas primarios en otros lugares. Una vez que los equipos completan una migración costosa, podrían resistirse a regresar.
Los requisitos de latencia y residencia de datos aún podrían atraer cargas de trabajo al Golfo. Sin embargo, es probable que los clientes exijan recuperación entre regiones como condición para cualquier retorno.
Ese cambio modificaría los patrones de gasto en nube. Las organizaciones pagarían por almacenamiento duplicado, computación en espera, redes más amplias y pruebas de recuperación más frecuentes.
Las empresas más pequeñas afrontan la disyuntiva más difícil. Se benefician de la latencia regional, pero pueden carecer del personal y los presupuestos necesarios para operaciones sofisticadas en múltiples regiones.
Los proveedores de nube pueden reducir esa carga mediante servicios más sencillos de replicación y recuperación. No pueden eliminar el coste de mantener capacidad independiente en otra geografía.
La tercera señal es cómo se diseñan y regulan las nuevas instalaciones del Golfo. La construcción subterránea, los sistemas eléctricos reforzados y una mayor separación geográfica demostrarían que la seguridad física ahora condiciona la planificación de la nube.
Los gobiernos también podrían revisar los requisitos de resiliencia para la banca y la infraestructura crítica. Esas normas podrían exigir copias de seguridad o entornos de recuperación operativos fuera de una única región nacional de nube.
Estas políticas reforzarían la resiliencia, pero generarían tensión con los objetivos de soberanía de datos. Los reguladores tendrían que decidir cuándo la disponibilidad prevalece sobre una localización geográfica estricta.
Los competidores influirán en esta decisión. Microsoft, Google, Oracle y los operadores locales pueden diferenciar sus ofertas mediante opciones de recuperación geográfica y divulgaciones sobre riesgos físicos.
La industria debería evitar convertir los daños de AWS en una comparación limitada entre proveedores. Cualquier proveedor con infraestructura concentrada en una zona de conflicto activo afronta riesgos relacionados.
Una estrategia multicloud puede reducir la dependencia de un operador, pero no ayuda cuando ambos proveedores ocupan la misma zona de amenaza. La geografía sigue siendo la variable esencial.
Las pruebas satelitales de ataques posteriores ya han mostrado que el riesgo no terminó con el primer incidente de marzo. Los daños posteriores en el emplazamiento debilitaron la idea de tratar los ataques originales como hechos aislados.
Ese historial debería determinar cómo interpretan los clientes los futuros anuncios de recuperación. Una instalación reabierta es capacidad operativa, no una prueba de que la amenaza circundante haya desaparecido.
Para los responsables técnicos, la acción inmediata consiste en mapear cada dependencia que exista solo dentro de una región. Ese inventario debería incluir datos, claves, sistemas de identidad, herramientas de despliegue e integraciones de proveedores.
Los equipos deberían comprobar después si pueden reconstruir en otro lugar sin ayuda de la región que falló. Un plan de recuperación que requiere acceso a infraestructura inaccesible no es independiente.
Los responsables empresariales también deben definir la pérdida de datos y el tiempo de inactividad aceptables. Esos objetivos determinan si las copias de seguridad son suficientes o si es necesario un entorno secundario en funcionamiento continuo.
La crisis de los centros de datos de AWS en Oriente Medio ha dejado las consecuencias especialmente claras. La redundancia regional preservó algunos servicios, pero no pudo recuperar la información alojada únicamente en infraestructura destruida.
Los próximos tres meses deberían traer un escrutinio más estrecho de los planes de reconstrucción de AWS, las decisiones de migración de los clientes y la política de infraestructura del Golfo. En conjunto, esas señales mostrarán si puede recuperarse la confianza en la nube regional.
Las organizaciones no deberían esperar ese veredicto antes de poner a prueba sus propios sistemas. ¿Puede su carga de trabajo más importante reiniciarse fuera de su región actual, con sus datos y dependencias intactos?
