# Planificación de la recuperación de desastres (DR)
Disponer de copias de seguridad y de componentes de cargas de trabajo redundantes es el principio de su estrategia de DR. [El RTO y el RPO son los objetivos](disaster-recovery-dr-objectives.md) de restauración de las cargas de trabajo. Estos se definen en función de las necesidades del negocio. Implemente una estrategia para satisfacer estos objetivos teniendo en cuenta las ubicaciones y la función de los recursos de las cargas de trabajo y los datos. La probabilidad de una interrupción y el costo de recuperación son también factores clave que ayudan a conocer el valor empresarial de proporcionar recuperación de desastres para una carga de trabajo.
Tanto la disponibilidad como la recuperación de desastres se basan en las mismas prácticas recomendadas, como la supervisión de los fallos, la implementación en varias ubicaciones y la conmutación por error automática. Sin embargo, la disponibilidad se centra en los componentes de la carga de trabajo, mientras que la recuperación de desastres se centra en las copias independientes de toda la carga de trabajo. La recuperación de desastres tiene objetivos diferentes a los de la disponibilidad y se centra en el tiempo de recuperación después de un desastre.
**Topics**
+ [REL13-BP01 Definición de objetivos de recuperación para el tiempo de inactividad y la pérdida de datos](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Uso de estrategias de recuperación definidas para cumplir los objetivos de recuperación](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Prueba de la implementación de recuperación de desastres para validarla](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Administración de la desviación de la configuración en el sitio o región de DR](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Automatización de la recuperación](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Definición de objetivos de recuperación para el tiempo de inactividad y la pérdida de datos
Los errores pueden afectar a su empresa de varias maneras. En primer lugar, los errores pueden provocar la interrupción del servicio (tiempo de inactividad). En segundo lugar, pueden provocar la pérdida de datos, su incoherencia o su obsolescencia. Para orientar la forma de responder y recuperarse ante los errores, defina un objetivo de tiempo de recuperación (RTO) y un objetivo de punto de recuperación (RPO) para cada carga de trabajo. El *objetivo de tiempo de recuperación (RTO)* es el tiempo máximo aceptable entre la interrupción del servicio y su restablecimiento. El *objetivo de punto de recuperación (RPO)* es el tiempo máximo aceptable tras el último punto de recuperación de datos.
**Resultado deseado:** cada carga de trabajo tiene un RTO y un RPO designados en función de las circunstancias técnicas y de repercusión para la empresa.
**Patrones comunes de uso no recomendados:**
+ No ha designado objetivos de recuperación.
+ Selecciona objetivos de recuperación arbitrarios.
+ Selecciona objetivos de recuperación demasiado permisivos que no cumplen los objetivos de la empresa.
+ No ha evaluado las consecuencias del tiempo de inactividad y la pérdida de datos.
+ Selecciona objetivos de recuperación poco realistas, como un tiempo de recuperación nulo o una pérdida de datos nula, que la configuración de la carga de trabajo tal vez no pueda alcanzar.
+ Selecciona objetivos de recuperación más estrictos que los objetivos empresariales reales. Esto obliga a hacer implementaciones de recuperación más costosas y complejas que lo que necesita la carga de trabajo.
+ Selecciona objetivos de recuperación incompatibles con los de una carga de trabajo dependiente.
+ No tiene en cuenta los requisitos normativos y de cumplimiento.
**Beneficios de establecer esta práctica recomendada:** al definir los RTO y los RPO para sus cargas de trabajo, establece objetivos de recuperación claros y medibles en función de las necesidades de su empresa. Una vez que haya establecido esos objetivos, puede crear planes de recuperación ante desastres (DR) para alcanzar dichos objetivos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Elabore una matriz o una hoja de trabajo que le sirva de guía para planificar la recuperación ante desastres. En su matriz, cree diferentes categorías o niveles de carga de trabajo en función de cómo afecten a su empresa (de nivel crítico, alto, medio y bajo, por ejemplo) y los RTO y RPO asociados a los que desee asignar cada uno de ellos. En la siguiente matriz se muestra un ejemplo (tenga en cuenta que los valores de RTO y RPO pueden diferir) que puede seguir:
![\[Gráfico en el que se muestra la matriz de recuperación de desastres\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/disaster-recovery-matrix.png)
Para cada carga de trabajo, debe comprender como afectan el tiempo de inactividad y la pérdida de datos a su empresa. Por lo general, el impacto aumenta con el tiempo de inactividad y la pérdida de datos, pero la forma del impacto puede variar según el tipo de carga de trabajo. Por ejemplo, un tiempo de inactividad de hasta una hora puede tener un impacto mínimo, pero después ese impacto podría aumentar rápidamente. Puede afectar de muchas maneras; por ejemplo, a nivel financiero (como la pérdida de ingresos), operativo (como la falta de nóminas o la disminución de la productividad) o normativo, así como en la reputación (incluida la pérdida de la confianza de los clientes). Una vez completado, asigne la carga de trabajo al nivel adecuado.
Tenga en cuenta las siguientes preguntas al analizar el impacto de un error:
1. ¿Durante cuánto tiempo se puede desactivar la carga de trabajo como máximo antes de que afecte gravemente a la empresa?
1. ¿En qué medida afecta a la empresa una interrupción de la carga de trabajo y de qué modo? Tenga en cuenta todos los tipos de impacto, a nivel financiero, operativo, normativo y en la reputación.
1. ¿Cuántos datos se pueden perder como máximo antes de que la empresa se vea gravemente afectada?
1. ¿Se pueden volver a crear los datos perdidos a partir de otras fuentes (también conocidos como datos *derivados*)? Si es así, incluya también los RPO de todos los datos de origen utilizados para volver a crea los datos de la carga de trabajo.
1. ¿Cuáles son los objetivos de recuperación y las expectativas de disponibilidad de las cargas de trabajo de las que depende (en sentido descendente)? Los objetivos de su carga de trabajo deben poder alcanzarse gracias a las capacidades de recuperación de sus dependencias posteriores. Puede usar soluciones alternativas o mitigaciones de las dependencias posteriores que puedan mejorar la capacidad de recuperación de esta carga de trabajo.
1. ¿Cuáles son los objetivos de recuperación y las expectativas de disponibilidad de las cargas de trabajo de las que depende (en sentido ascendente)? Los objetivos de la carga de trabajo anterior pueden requerir que esta carga de trabajo tenga capacidades de recuperación más estrictas de lo que parece a primera vista.
1. ¿Existen diferentes objetivos de recuperación en función del tipo de incidente? Por ejemplo, puede haber diferentes RTO y RPO en función de que el incidente afecte a una zona de disponibilidad o a toda una región.
1. ¿Cambian sus objetivos de recuperación durante determinados eventos o épocas del año? Por ejemplo, es posible que tenga diferentes RTO y RPO en función de las temporadas de compras navideñas, los eventos deportivos, las rebajas especiales y los lanzamientos de nuevos productos.
1. ¿Cómo se acompasan los objetivos de recuperación con las posibles estrategias de recuperación ante desastres de su línea de negocio y de su organización?
1. ¿Hay que tener en cuenta las ramificaciones legales o contractuales? Por ejemplo, ¿tiene una obligación contractual de prestar un servicio con un RTO o RPO determinado? ¿A qué sanciones podría enfrentarse por no cumplirlas?
1. ¿Tiene obligación de mantener la integridad de los datos para cumplir con los requisitos normativos o de conformidad?
La siguiente hoja de trabajo puede ayudarlo a evaluar cada carga de trabajo. Puede modificar esta hoja de trabajo para adaptarla a sus necesidades específicas, por ejemplo, agregar otras preguntas.
![\[Hoja de trabajo\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/worksheet.png)
### Pasos para la implementación
1. Identifique cuáles son las partes interesadas de la empresa y los equipos técnicos responsables de cada carga de trabajo y contacte con ellos.
1. Cree categorías o niveles de importancia crítica del impacto de la carga de trabajo en su organización. Entre las categorías de ejemplo se incluyen las siguientes: crítico, alto, medio y bajo. Para cada categoría, elija un RTO y un RPO que reflejen los objetivos y requisitos de su empresa.
1. Asigne una de las categorías de impacto que ha creado en el paso anterior a cada carga de trabajo. Para decidir cómo se asigna una carga de trabajo a una categoría, tenga en cuenta la importancia de la carga de trabajo para la empresa y el impacto de la interrupción o la pérdida de datos. Las preguntas anteriores pueden guiarle. De este modo, obtendrá un RTO y un RPO para cada carga de trabajo.
1. Tenga en cuenta el RTO y el RPO para cada carga de trabajo determinada en el paso anterior. Incluya a los equipos técnicos y empresariales de la carga de trabajo para determinar si se deben ajustar los objetivos. Por ejemplo, las partes interesadas de la empresa podrían determinar que se requieren objetivos más estrictos. Si lo prefiere, los equipos técnicos podrían determinar si los objetivos deberían modificarse para que se puedan alcanzar con los recursos disponibles y las limitaciones tecnológicas.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL09-BP04 Recuperación periódica de los datos para verificar la integridad de la copia de seguridad y los procesos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html)
+ [REL12-BP01 Uso de manuales de estrategias para investigar los errores](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL13-BP02 Uso de estrategias de recuperación definidas para cumplir los objetivos de recuperación](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Prueba de la implementación de recuperación ante desastres para validarla](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Documentos relacionados:**
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperación de desastres de cargas de trabajo en AWS: recuperación en la nube (documento técnico de AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Administrar las políticas de resiliencia con AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [Socio de APN: socios que pueden ayudar con la recuperación ante desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: productos que pueden usarse para la recuperación ante desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Videos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [Disaster Recovery of Workloads on AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 Uso de estrategias de recuperación definidas para cumplir los objetivos de recuperación
Defina una estrategia de recuperación de desastres (DR) que se ajuste a los objetivos de recuperación de su carga de trabajo. Elija una estrategia como copia de seguridad y restauración, estado de espera (activa/pasiva) o activa/activa.
**Resultado deseado:** para cada carga de trabajo, hay una estrategia de DR definida e implementada que permite que la carga de trabajo alcance los objetivos de DR. Las estrategias de DR entre cargas de trabajo emplean patrones reutilizables (como las estrategias descritas anteriormente).
**Patrones comunes de uso no recomendados:**
+ Implementar procedimientos de recuperación incoherentes para cargas de trabajo con objetivos de DR similares.
+ Dejar la estrategia de DR para implementarla ad hoc cuando se produzca un desastre.
+ No tener un plan de recuperación de desastres.
+ Depender de las operaciones del plano de control durante la recuperación.
**Beneficios de establecer esta práctica recomendada:**
+ El uso de estrategias de recuperación definidas le permite emplear herramientas y procedimientos de prueba comunes.
+ El uso de estrategias de recuperación definidas mejora el intercambio de conocimiento entre equipos y la implementación de la DR en las cargas de trabajo que se encuentran bajo su responsabilidad.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto. Sin una estrategia de DR planificada, implementada y probada, es poco probable que consiga sus objetivos de recuperación en caso de desastre.
## Guía para la implementación
Una estrategia de DR depende de la capacidad de poner en marcha su carga de trabajo en un sitio de recuperación si su ubicación principal deja de estar disponible para la ejecución de dicha carga de trabajo. Los objetivos de recuperación más comunes son el RTO y el RPO, como explicamos en [REL13-BP01 Definición de objetivos de recuperación para el tiempo de inactividad y la pérdida de datos](rel_planning_for_recovery_objective_defined_recovery.md).
Una estrategia de DR en varias zonas de disponibilidad (AZ) en una única Región de AWS puede ofrecer mitigación contra eventos de desastres como incendios, inundaciones y cortes de suministro eléctrico considerables. Si es necesario implementar medidas de protección contra un evento poco probable que evite que su carga de trabajo pueda ejecutarse en una Región de AWS determinada, puede seguir una estrategia de DR que abarque múltiples regiones.
A la hora de diseñar una estrategia de DR en varias regiones, debe elegir una de las siguientes estrategias. Se enumeran en orden ascendente de costo y complejidad, y en orden descendente de RTO y RPO. La *región de recuperación* se refiere a una Región de AWS distinta de la principal que se utiliza para la carga de trabajo.
![\[Diagrama en el que se muestran estrategias de DR\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/disaster-recovery-strategies.png)
+ **Copia de seguridad y restauración** (RPO en horas, RTO en 24 horas o menos): haga una copia de seguridad de los datos y aplicaciones en la región de recuperación. El uso de copias de seguridad automatizadas o continuas permitirá la recuperación en un momento dado (PITR), lo que puede reducir el RPO a hasta 5 minutos en algunos casos. En caso de desastre, implementará la infraestructura (mediante la infraestructura como código para reducir el RTO), implementará el código y restaurará los datos desde la copia de seguridad para recuperarse del desastre en la región de recuperación.
+ **Luz piloto** (RPO en minutos, RTO en decenas de minutos): aprovisione una copia de la infraestructura de carga de trabajo principal en la región de recuperación. Replique los datos en la región de recuperación y cree allí copias de seguridad de estos. Los recursos necesarios para permitir la replicación y copia de seguridad de los datos, como el almacenamiento de bases de datos y objetos, están siempre disponibles. Otros elementos, como los servidores de aplicaciones o la computación sin servidor, no se implementan, pero pueden crearse cuando sea necesario con la configuración y el código de aplicación pertinentes.
+ **Espera semiactiva** (RPO en segundos, RTO en minutos): mantenga una versión reducida, pero completamente funcional de la carga de trabajo que se ejecute siempre en la región de recuperación. Los sistemas críticos se duplican en su totalidad y siempre están activos, pero con una flota reducida. Los datos se replican y están activos en la región de recuperación. Cuando llegue el momento de la recuperación, el sistema se ampliará rápidamente para asumir la carga de producción. Cuanto mayor sea la escala de la espera semiactiva, menor será el RTO y la fiabilidad del plano de control. Cuando se amplía por completo, esto se conoce como *espera activa*.
+ **Activo-activo en varias regiones (varios sitios)** (RPO cercano a cero, RTO potencialmente nulo): la carga de trabajo se implementa en varias Regiones de AWS y atiende de manera activa el tráfico procedente de estas. Esta estrategia requiere que sincronice datos entre regiones. Los posibles conflictos causados por escrituras en el mismo registro en dos réplicas regionales diferentes deben evitarse o gestionarse, lo que puede resultar complejo. La replicación de datos es útil para la sincronización de datos y es una protección ante algunos tipos de desastres, pero no ante el daño o la destrucción de datos, a no ser que su solución incluya también opciones para una recuperación en un momento dado.
**nota**
La diferencia entre la luz piloto y la espera semiactiva a veces puede ser difícil de comprender. Ambos métodos incluyen un entorno en su región de recuperación con copias de los activos de su región principal. La distinción es que la luz piloto no puede procesar solicitudes sin tomar primero medidas adicionales, mientras que la espera semiactiva puede gestionar el tráfico (a niveles de capacidad reducidos) inmediatamente. La luz piloto exige que active servidores, posiblemente que implemente infraestructura adicional (no principal) y que escale verticalmente, mientras que la espera semiactiva solo requiere que escale verticalmente (ya está todo implementado y en ejecución). Elija una de estas opciones en función de sus necesidades de RTO y RPO.
Cuando el costo sea una preocupación y desee alcanzar unos objetivos de RPO y RTO similares a los definidos en la estrategia de espera semiactiva, podría plantearse soluciones nativas en la nube, como AWS Elastic Disaster Recovery, que adoptan el enfoque de luz piloto y ofrecen objetivos de RPO y RTO mejorados.
**Pasos para la implementación**
1. **Determine una estrategia de recuperación de desastres que satisfaga los requisitos de recuperación de esta carga de trabajo.**
La selección de una estrategia de DR requiere alcanzar un punto de equilibrio entre la reducción del tiempo de inactividad y la pérdida de datos (RTO y RPO) y los costos y la complejidad de implementar la estrategia. Debe evitar implementar una estrategia que sea más exigente de lo necesario, ya que esto supone costos innecesarios.
Por ejemplo, en el siguiente diagrama, la empresa ha determinado su RTO máximo permisible y el límite de gasto en su estrategia de restauración del servicio. Dados los objetivos de la empresa, las estrategias de DR de luz piloto o espera semiactiva satisfarán tanto el RTO como los criterios de costo.
![\[Gráfico en el que se muestra la elección de una estrategia de DR en función del RTO y costo\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/choosing-a-dr-strategy.png)
Para más información, consulte el [Plan de continuidad del negocio (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **Revise los patrones de cómo se puede implementar la estrategia de DR seleccionada.**
Este paso implica comprender cómo implementará la estrategia seleccionada. Las estrategias se explican mediante las Regiones de AWS para determinar un sitio principal y otro de recuperación. Sin embargo, también puede decidir utilizar zonas de disponibilidad en una única región como estrategia de DR, que utiliza los elementos de varias de estas estrategias.
En los siguientes pasos, puede aplicar la estrategia a su carga de trabajo específica.
**Copia de seguridad y restauración**
La *copia de seguridad y restauración* son la estrategia menos compleja de implementar, pero requerirán más tiempo y esfuerzo para restaurar la carga de trabajo, lo que generará un RTO y un RPO más altos. Se recomienda hacer siempre copias de seguridad de los datos y copiarlas en otro sitio (por ejemplo, otra Región de AWS).
![\[Diagrama en el que se muestra una arquitectura de copia de seguridad y restauración\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/backup-restore-architecture.png)
Para obtener más información sobre esta estrategia, consulte [Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**Luz piloto**
Con el enfoque de *luz piloto*, se replican los datos de la región principal a la región de recuperación. Los recursos principales utilizados para la infraestructura de la carga de trabajo se implementan en la región de recuperación; sin embargo, se siguen necesitando recursos adicionales y las dependencias pertinentes para que esta pila sea funcional. Por ejemplo, en la figura 20 no se implementan instancias de computación.
![\[Diagrama que muestra una arquitectura de luz piloto\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/pilot-light-architecture.png)
Para obtener más información sobre esta estrategia, consulte [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Espera semiactiva**
El enfoque de *espera semiactiva* implica garantizar que haya una copia reducida, pero completamente funcional, del entorno de producción en otra región. Este enfoque extiende el concepto de luz piloto y reduce el tiempo de recuperación, ya que su carga de trabajo tiene disponibilidad permanente en otra región. Si la región de recuperación se implementa al máximo de su capacidad, esto se conoce como modo de *espera activa*.
![\[Diagrama en el que se muestra la figura 21 con arquitectura de espera semiactiva\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/warm-standby-architecture.png)
El uso de los enfoques de espera semiactiva o luz piloto requiere escalar verticalmente los recursos en la región de recuperación. Para comprobar que la capacidad esté disponible cuando sea necesaria, considere la posibilidad de utilizar [reservas de capacidad](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) para las instancias de EC2. Si se utiliza AWS Lambda, la [simultaneidad aprovisionada](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) puede proporcionar entornos de tiempo de ejecución para que estén preparados para responder a las invocaciones de la función.
Para obtener más información sobre esta estrategia, consulte [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Activa-activa multisitio**
Puede ejecutar la carga de trabajo de forma simultánea en varias regiones como parte de una estrategia *activa-activa multisitio*. La estrategia activa-activa multisitio suministra tráfico desde todas las regiones en las que se implementa. Los clientes podrían seleccionar esta estrategia por motivos ajenos a la DR. Se puede utilizar para aumentar la disponibilidad o cuando se implementa una carga de trabajo para una audiencia global (para colocar el punto de conexión más cerca de los usuarios o para implementar pilas localizadas para la audiencia de esa región). Como estrategia de DR, si la carga de trabajo no es compatible en una de las Regiones de AWS en la que se implemente, esa región se evacúa y las regiones restantes se utilizar para mantener la disponibilidad. La estrategia activa-activa multisitio es la más compleja de las estrategias de DR a nivel operativo y solo se debe seleccionar cuando los requisitos empresariales lo exijan.
![\[Diagrama en el que se muestra una arquitectura activa-activa multisitio\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/multi-site-active-active-architecture.png)
Para obtener más información sobre esta estrategia, consulte [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**AWS Elastic Disaster Recovery**
Si está considerando la posibilidad de adoptar la estrategia de luz piloto o espera semiactiva en caso de recuperación de desastres, AWS Elastic Disaster Recovery podría proporcionar un enfoque alternativo con mejores beneficios. La Recuperación de desastres elástica puede ofrecer un objetivo de RPO y RTO similar al de los sistemas de espera semiactiva, pero mantiene el enfoque de bajo costo de luz piloto. La Recuperación de desastres elástica replica los datos de la región principal a la región de recuperación y utiliza una protección de datos continua para lograr un RPO medido en segundos y un RTO que se puede medir en minutos. En la región de recuperación se implementan solo los recursos necesarios para replicar los datos, lo que mantiene los costos bajos, de forma similar a la estrategia de luz piloto. Al utilizar Recuperación de desastres elástica, el servicio coordina y organiza la recuperación de los recursos de computación cuando se inicia como parte de una conmutación por error o un simulacro.
![\[Diagrama de la arquitectura en el que se describe cómo opera AWS Elastic Disaster Recovery.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/drs-architecture.png)
**Prácticas adicionales para la protección de los datos**
Con todas las estrategias, también debe mitigar los posibles desastres de datos. La replicación de datos continua le brindará protección ante algunos tipos de desastres, pero no ante el daño o la destrucción de datos, a no ser que su estrategia incluya también control de versiones para una recuperación en un momento dado. También debe hacer una copia de seguridad de los datos replicados en el sitio de recuperación para crear copias de seguridad en un momento dado además de las réplicas.
**Uso de varias zonas de disponibilidad (AZ) en una sola Región de AWS**
Al usar varias AZ en una única región, la implementación de DR utiliza varios elementos de las estrategias anteriores. Primero, debe crear una arquitectura de alta disponibilidad con varias AZ, como se muestra en la figura 23. Esta arquitectura utiliza un enfoque activo-activo multisitio, ya que las [instancias de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) y el [equilibrador de carga elástico](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) tienen recursos implementados en varias zonas de disponibilidad y gestionan las solicitudes de forma activa. La arquitectura también muestra el modo de espera activa, donde, si se produce un error en la instancia principal de [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) (o se produce un error en la propia AZ), la instancia en espera pasa a ser principal.
![\[Diagrama en el que se muestra la figura 24 con arquitectura multi-AZ\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/multi-az-architecture2.png)
Además de esta arquitectura de alta disponibilidad, debe agregar copias de seguridad con todos los datos necesarios para ejecutar la carga de trabajo. Esto es especialmente importante para los datos que están restringidos a una sola zona, como los [volúmenes de Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) o los [clústeres de Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Si se produce un error en una AZ, tendrá que restaurar estos datos en otra AZ. Siempre que sea posible, deberá copiar las copias de seguridad de los datos en otra Región de AWS como capa de protección adicional.
Un enfoque alternativo menos común para la DR de una sola región de varias zonas de disponibilidad se ilustra en la entrada del blog [Building highly resilient applications using Amazon Application Recovery Controller, Part 1: Single-Region stack](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/). Aquí, la estrategia es mantener la máxima cantidad posible de aislamiento entre las AZ, tal y como funcionan las regiones. Al utilizar esta estrategia alternativa, puede elegir un enfoque activo-activo o activo-pasivo.
**nota**
Algunas cargas de trabajo tienen requisitos normativos de residencia de datos. Si esto se aplica a su carga de trabajo en una ubicación que actualmente tenga solo una Región de AWS, el enfoque multirregión no se adaptará a sus necesidades empresariales. Las estrategias de multi-AZ ofrecen una buena protección contra la mayoría de los desastres.
1. **Evalúe los recursos de la carga de trabajo y cuál será su configuración en la región de recuperación antes de la conmutación por error (durante el funcionamiento normal).**
Para la infraestructura y los recursos de AWS, utilice la infraestructura como código, por ejemplo, [AWS CloudFormation](https://aws.amazon.com/cloudformation) o herramientas de terceros, como Hashicorp Terraform. Para efectuar la implementación en varias cuentas y regiones en una sola operación, puede utilizar [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). En el caso de las estrategias activa-activa multisitio o espera activa, la infraestructura implementada en la región de recuperación tiene los mismos recursos que la región principal. En las estrategias de luz piloto y espera semiactiva, la infraestructura implementada requerirá acciones adicionales para prepararse para la producción. Con los [parámetros](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) y la [lógica condicional](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html) de CloudFormation, puede controlar si una pila implementada está activa o en espera con [una sola plantilla](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). Al utilizar la Recuperación de desastres elástica, el servicio replicará y orquestará la restauración de las configuraciones de las aplicaciones y los recursos de computación.
Todas las estrategias de DR requieren que se haga una copia de seguridad de los orígenes de datos en la Región de AWS y, a continuación, que esas copias de seguridad se copien en la región de recuperación. [AWS Backup](https://aws.amazon.com/backup/) proporciona una vista centralizada en la que se pueden configurar, programar y supervisar las copias de seguridad de estos recursos. Para los enfoques de luz piloto, espera semiactiva y activo-activo multisitio, también debe replicar los datos de la región principal en los recursos de datos de la región de recuperación, como las instancias de bases de datos de [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) o las tablas de [Amazon DynamoDB](https://aws.amazon.com/dynamodb). De esta forma, estos recursos de datos estarán activos y preparados para responder a solicitudes en la región de recuperación.
Para más información sobre el funcionamiento de los servicios de AWS en las regiones, consulte esta serie de blogs en [Creating a Multi-Region Application with AWS Services](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Determine e implemente cómo preparará la región de recuperación para la conmutación por error cuando sea necesario (durante un desastre).**
En el caso de la opción activa-activa multisitio, la conmutación por error implica evacuar una región y recurrir a las regiones activas restantes. En general, esas regiones están listas para aceptar tráfico. En las estrategias de luz piloto y espera semiactiva, las acciones de recuperación tendrán que implementar los recursos faltantes, como las instancias de EC2 en la figura 20, además de otros recursos faltantes.
En todas las estrategias anteriores, es posible que tenga que promover instancias de solo lectura de bases de datos para que se conviertan en la instancia de lectura y escritura principal.
En copias de seguridad y restauración, la restauración de datos desde una copia de seguridad crea recursos para esos datos, como volúmenes de EBS, instancias de bases de datos de RDS y tablas de DynamoDB. También tiene que restaurar la infraestructura e implementar el código. Puede utilizar AWS Backup para restaurar datos en la región de recuperación. Consulte [REL09-BP01 Identificación de todos los datos de los que se debe hacer una copia de seguridad, creación de la copia de seguridad o reproducción de los datos a partir de los orígenes](rel_backing_up_data_identified_backups_data.md) para obtener más detalles. Volver a crear la infraestructura incluye la creación de recursos, como instancias de EC2, además de [Amazon Virtual Private Cloud (Amazon VPC](https://aws.amazon.com/vpc)), las subredes y los grupos de seguridad necesarios. Puede automatizar gran parte del proceso de restauración. Consulte [esta entrada de blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/) para obtener más información.
1. **Determine e implemente cómo redirigirá el tráfico a la conmutación por error cuando sea necesario (durante un desastre).**
Esta operación de conmutación por error se puede iniciar automática o manualmente. La conmutación por error iniciada automáticamente en función de comprobaciones de estado o alarmas se debe utilizar con cuidado, ya que una conmutación por error innecesaria (falsa alarma) supone ciertos inconvenientes, como la falta de disponibilidad y la pérdida de datos. Por tanto, la conmutación por error iniciada manualmente es la que se suele utilizar. En este caso, debe seguir automatizando los pasos de la conmutación por error, de modo que la iniciación manual sea como pulsar un botón.
Hay varias opciones de administración del tráfico que tener en cuenta al utilizar servicios de AWS. Una opción es utilizar [Amazon Route 53](https://aws.amazon.com/route53). Al utilizar Amazon Route 53, puede asociar varios puntos de conexión de IP en una o varias Regiones de AWS a un nombre de dominio de Route 53. Para implementar la conmutación por error iniciada manualmente, puede utilizar el [Controlador de recuperación de aplicaciones de Amazon](https://aws.amazon.com/application-recovery-controller/), que proporciona una API de plano de datos de alta disponibilidad para redirigir el tráfico a la región de recuperación. Al implementar la conmutación por error, utilice las operaciones del plano de datos y evite las del plano de control, como se describe en [REL11-BP04 Confianza en el plano de datos y no en el plano de control durante la recuperación](rel_withstand_component_failures_avoid_control_plane.md).
Para más información sobre esta y otras opciones, consulte [esta sección del documento técnico sobre recuperación de desastres](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **Diseñe un plan sobre cómo se recuperará su carga de trabajo.**
La conmutación por recuperación se produce cuando se devuelve la operación de una carga de trabajo a la región principal una vez disminuido un desastre. Por lo general, el aprovisionamiento de la infraestructura y el código en la región principal sigue los mismos pasos que se utilizaron inicialmente y se basa en la infraestructura como código y en las canalizaciones de implementación del código. El reto que plantea la conmutación por recuperación es restaurar los almacenes de datos y garantizar que sean coherentes con la región de recuperación en funcionamiento.
En el estado de conmutación por error, las bases de datos en la región de recuperación están activas y tienen los datos actualizados. El objetivo es volver a efectuar la sincronización desde la región de recuperación a la región principal, lo que garantiza que está actualizada.
Algunos servicios de AWS harán esto automáticamente. Si utiliza las [tablas globales de Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/), aunque la tabla de la región principal no esté disponible, cuando vuelva a estar en línea, DynamoDB reanudará la propagación de las escrituras pendientes. Si utiliza la [Base de datos global de Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) y la [conmutación por error planificada administrada](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), se mantiene la topología de reproducción existente de la base de datos global de Aurora. Por tanto, la instancia de lectura y escritura anterior en la región principal se convertirá en una réplica y recibirá actualizaciones desde la región de recuperación.
En los casos en los que esto no se haga automáticamente, tendrá que restablecer la base de datos en la región principal como una réplica de la base de datos en la región de recuperación. En muchos casos, esto supondrá eliminar la antigua base de datos principal y crear nuevas réplicas.
Tras una conmutación por error, si puede seguir operando en su región de recuperación, considere la posibilidad de convertir esta región en la nueva región principal. Seguiría completando los pasos anteriores para hacer que la antigua región principal fuera una región de recuperación. Algunas organizaciones llevan a cabo una rotación programada y cambian sus regiones principal y de recuperación periódicamente (por ejemplo, cada tres meses).
Todos los pasos necesarios para la conmutación por error y conmutación por recuperación deben mantenerse en una guía de estrategias disponible para todos los miembros del equipo que se revise periódicamente.
Al utilizar la Recuperación de desastres elástica, el servicio ayudará a organizar y automatizar el proceso de conmutación por recuperación. Para obtener más información, consulte [Performing a failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html).
**Nivel de esfuerzo para el plan de implementación:** alto
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL09-BP01 Identificación de todos los datos de los que se debe hacer una copia de seguridad, creación de la copia de seguridad o reproducción de los datos a partir de los orígenes](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Confianza en el plano de datos y no en el plano de control durante la recuperación](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 Definición de objetivos de recuperación para el tiempo de inactividad y la pérdida de datos](rel_planning_for_recovery_objective_defined_recovery.md)
**Documentos relacionados:**
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperación de desastres de cargas de trabajo en AWS: recuperación en la nube (documento técnico de AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Opciones de recuperación de desastres en la nube](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Build a serverless multi-region, active-active backend solution in an hour](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Multi-region serverless backend — reloaded](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: replicación de una réplica de lectura entre regiones](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: Configuring DNS Failover](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: replicación entre regiones](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [Qué es AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [What is Amazon Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: Get Started - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [Socio de APN: socios que pueden ayudar con la recuperación de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: productos que pueden usarse para la recuperación ante desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Videos relacionados:**
+ [Disaster Recovery of Workloads on AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Get Started with AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
# REL13-BP03 Prueba de la implementación de recuperación de desastres para validarla
Compruebe periódicamente la conmutación por error de su sitio de recuperación para verificar que funcione adecuadamente y que se cumplan el RTO y el RPO.
**Patrones comunes de uso no recomendados:**
+ No llevar a cabo nunca conmutaciones por error en producción.
**Beneficios de establecer esta práctica recomendada:** las pruebas periódicas del plan de recuperación de desastres verifican que el plan funcione cuando llegue el momento y que su equipo sepa cómo llevar a cabo la estrategia.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Un patrón que debe evitarse es el desarrollo de rutas de recuperación que se pongan en práctica pocas veces. Por ejemplo, puede tener un almacén de datos secundario que se utilice para consultas de solo lectura. Cuando escribe en un almacén de datos y se produce un error del almacén principal, es posible que quiera conmutar por error al almacén de datos secundario. Si no se prueba frecuentemente esta conmutación por error, es posible que sus suposiciones sobre las capacidades del almacén de datos secundario sean incorrectas. Es posible que la capacidad del almacén de datos secundario, que quizás fuera suficiente cuando se probó por última vez, ya no pueda tolerar la carga en esta situación. Nuestra experiencia ha demostrado que la única forma de recuperación de errores que funciona es aquella que se prueba constantemente. Por ello, es mejor tener un número reducido de rutas de recuperación. Puede establecer patrones de recuperación y probarlos con frecuencia. Si tiene una ruta de recuperación compleja o crítica, todavía debe llevar a efecto ese error en producción periódicamente para asegurarse de que la ruta funcione. En el ejemplo que acabamos de comentar, se debe conmutar por error al modo de espera con regularidad, sin importar si es necesario.
**Pasos para la implementación**
1. Diseñe sus cargas de trabajo para que se puedan recuperar. Pruebe regularmente sus rutas de recuperación. La computación orientada a la recuperación identifica las características de los sistemas que mejoran la recuperación: aislamiento y redundancia, capacidad en todo el sistema para revertir los cambios, capacidad para supervisar y determinar el estado, capacidad para proporcionar diagnósticos, recuperación automatizada, diseño modular y capacidad para reiniciar. Ponga en práctica la ruta de recuperación para verificar que pueda llevar a cabo la recuperación en el tiempo especificado para el estado especificado. Use sus manuales de procedimientos durante esta recuperación para documentar los problemas y encontrar soluciones para estos antes de la próxima prueba.
1. En el caso de las cargas de trabajo basadas en Amazon EC2, utilice [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) para implementar y lanzar instancias de simulacro para la estrategia de DR. AWS Elastic Disaster Recovery ofrece la posibilidad de ejecutar simulacros de forma eficiente, lo que ayuda a prepararse para un evento de conmutación por error. También puede lanzar con frecuencia sus instancias mediante Recuperación de desastres elástica para hacer pruebas y simulacros sin redirigir el tráfico.
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudar con la recuperación de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: productos que pueden usarse para la recuperación de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [Recuperación de desastres de cargas de trabajo en AWS: recuperación en la nube (documento técnico de AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [AWS Elastic Disaster Recovery Preparing for Failover](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)
+ [The Berkeley/Stanford recovery-oriented computing project](http://roc.cs.berkeley.edu/)
+ [What is AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Videos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS](https://youtu.be/7gNXfo5HZN8)
# REL13-BP04 Administración de la desviación de la configuración en el sitio o región de DR
Para llevar a cabo un procedimiento de recuperación ante desastres (DR) correctamente, su carga de trabajo debe poder reanudar las operaciones normales de manera oportuna sin pérdida relevante de funcionalidad o datos una vez que el entorno de DR se haya puesto en funcionamiento. Para lograr este objetivo, es esencial mantener una infraestructura, datos y configuraciones consistentes entre el entorno de DR y el entorno principal.
**Resultado deseado:** la configuración y los datos de su sitio de recuperación ante desastres son iguales a los del sitio principal, lo que facilita una recuperación rápida y completa cuando es necesario.
**Patrones comunes de uso no recomendados:**
+ No se actualizan las ubicaciones de recuperación cuando se realizan cambios en las ubicaciones principales, lo que se traduce en configuraciones desactualizadas que podrían dificultar los esfuerzos de recuperación.
+ No tiene en cuenta las posibles limitaciones, como las diferencias de los servicios entre las ubicaciones principales y de recuperación, que pueden provocar fallos inesperados durante la conmutación por error.
+ Confía en los procesos manuales para actualizar y sincronizar el entorno de recuperación ante desastres, lo que aumenta el riesgo de errores humanos e incoherencias.
+ No se detectan desviaciones en la configuración, lo que genera una falsa sensación de que el sitio de recuperación ante desastres está preparado antes de que se produzca un incidente.
**Beneficios de establecer esta mejor práctica:** la coherencia entre el entorno de recuperación ante desastres y el entorno principal mejora considerablemente las probabilidades de una recuperación satisfactoria tras un incidente y reduce el riesgo de que se produzca un error en el procedimiento de recuperación.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Un enfoque integral de la administración de la configuración y la preparación para la conmutación por error puede ayudarlo a comprobar que el sitio de recuperación ante desastres se actualiza constantemente y está preparado para asumir el control en caso de que se produzca un fallo en el sitio principal.
Para lograr la coherencia entre su entorno principal y el de recuperación ante desastres (DR), compruebe que sus canales de entrega distribuyen las aplicaciones tanto en el sitio principal como en el de recuperación ante desastres. Despliegue los cambios en los sitios de recuperación ante desastres después de un periodo de evaluación adecuado (también conocido como *despliegues escalonados*) para detectar problemas en el sitio principal y detener la implementación antes de que se propaguen. Implemente la supervisión para detectar desviaciones en la configuración y lleve un seguimiento de los cambios y el cumplimiento en todos sus entornos. Realice correcciones automatizadas en el sitio de recuperación ante desastres para mantener la máxima coherencia y que esté listo para funcionar en caso de que se produzca un incidente.
### Pasos para la implementación
1. Valide que la región de recuperación ante desastres contenga los servicios y las características de AWS necesarios para ejecutar correctamente el plan de recuperación ante desastres.
1. Utilice infraestructura como código (IaC). Mantenga la precisión de sus plantillas de configuración de aplicaciones e infraestructura de producción y aplíquelas periódicamente a su entorno de recuperación ante desastres. [AWS CloudFormation](https://aws.amazon.com/cloudformation/)puede detectar una desviación entre lo que especifican las plantillas de CloudFormation y lo que realmente se implementa.
1. Configure las canalizaciones de CI/CD para implementar aplicaciones y actualizaciones de infraestructura en todos los entornos, incluidos los sitios principales y de recuperación ante desastres. Las soluciones de CI/CD, como [AWS CodePipeline](https://aws.amazon.com/codepipeline/), pueden automatizar el proceso de implementación, lo que reduce el riesgo de cambios en la configuración.
1. Distribuya las implementaciones entre el entorno principal y el de recuperación ante desastres. Este enfoque permite implementar y probar las actualizaciones inicialmente en el entorno principal, lo que aísla los problemas en el sitio principal antes de que se propaguen al sitio de DR. Así se evita que los defectos se transmitan simultáneamente a la planta de producción y al centro de recuperación ante desastres y mantiene la integridad del entorno de recuperación ante desastres.
1. Supervise continuamente las configuraciones de los recursos en los entornos principal y de DR. Soluciones como [AWS Config](https://aws.amazon.com/config/) pueden ayudar a garantizar el cumplimiento de la configuración y detectar desviaciones, lo que ayuda a mantener la coherencia de las configuraciones en todos los entornos.
1. Implemente mecanismos de alerta para rastrear y notificar cualquier cambio en la configuración o interrupción o retraso en la replicación de datos.
1. Automatice la corrección de las desviaciones de configuración detectadas.
1. Programe auditorías y comprobaciones de conformidad periódicas para verificar la alineación continua entre las configuraciones principal y de recuperación ante desastres. Las revisiones periódicas ayudan a mantener el cumplimiento de las normas definidas e identificar cualquier discrepancia que deba abordarse.
1. Compruebe si hay discrepancias en la capacidad aprovisionada, las cuotas de servicio, los límites de aceleración y las discrepancias de configuración y versión de AWS.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL01-BP01 Conocimiento de las cuotas y restricciones del servicio](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_aware_quotas_and_constraints.html)
+ [REL01-BP02 Administración de cuotas de servicio en cuentas y regiones](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_limits_considered.html)
+ [REL01-BP04 Supervisión y administración de cuotas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html)
+ [REL13-BP03 Prueba de la implementación de recuperación ante desastres para validarla](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Documentos relacionados:**
+ [Remediating Noncompliant AWS Resources by Reglas de AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS CloudFormation: Detección de cambios de configuración no administrados en pilas y recursos](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)
+ [AWS CloudFormation: Detección de desviaciones en una pila de CloudFormation completa](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Recuperación de desastres de cargas de trabajo en AWS: recuperación en la nube (documento técnico de AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [How do I implement an Infrastructure Configuration Management solution on AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Remediating Noncompliant AWS Resources by Reglas de AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Videos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
**Ejemplos relacionados:**
+ [CloudFormation Registro](https://aws.amazon.com/blogs/devops/identify-regional-feature-parity-using-the-aws-cloudformation-registry/)
+ [Monitor de cuotas para AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [Implemente la corrección automática de desviaciones para AWS CloudFormation mediante Amazon CloudWatch y AWS Lambda](https://aws.amazon.com/blogs/mt/implement-automatic-drift-remediation-for-aws-cloudformation-using-amazon-cloudwatch-and-aws-lambda/)
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: productos que pueden usarse para la recuperación ante desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [Automatización de implementaciones seguras y sin intervención](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
# REL13-BP05 Automatización de la recuperación
Implemente mecanismos de recuperación comprobados y automatizados que sean fiables, observables y reproducibles para reducir el riesgo y el impacto empresarial de los fallos.
**Resultado deseado:** ha implementado un flujo de trabajo de automatización bien documentado, estandarizado y probado exhaustivamente para los procesos de recuperación. La automatización de la recuperación corrige automáticamente los problemas menores que suponen un bajo riesgo de pérdida de datos o de falta de disponibilidad. Puede invocar rápidamente a los procesos de recuperación en caso de incidentes graves, observar el comportamiento de corrección mientras están en funcionamiento y finalizar los procesos si observa situaciones peligrosas o fallos.
**Patrones comunes de uso no recomendados:**
+ Como parte de su plan de recuperación, depende de los componentes o mecanismos que se encuentran en un estado defectuoso o degradado.
+ Los procesos de recuperación requieren una intervención manual, como el acceso a la consola (también conocido como *operaciones de clic*).
+ Los procedimientos de recuperación se inician automáticamente en situaciones que presentan un alto riesgo de pérdida de datos o de falta de disponibilidad.
+ No incluye un mecanismo para interrumpir un procedimiento de recuperación (similar a un *sistema Andon* o a un *botón rojo de parada de emergencia*) que no funciona o que plantea riesgos adicionales.
**Beneficios de establecer esta práctica recomendada:**
+ Mayor fiabilidad, previsibilidad y consistencia de las operaciones de recuperación.
+ Capacidad para cumplir objetivos de recuperación más estrictos, como el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO).
+ Menor probabilidad de fallos en la recuperación durante un incidente.
+ Reducción del riesgo de fallos asociados a los procesos de recuperación manual que son propensos a errores humanos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Para implementar la recuperación automatizada, necesita un enfoque integral que utilice los servicios de AWS y las prácticas recomendadas. Para empezar, identifique los componentes críticos y los posibles puntos de fallo de su carga de trabajo. Desarrolle procesos automatizados que puedan recuperar sus cargas de trabajo y datos en caso de fallos sin intervención humana.
Desarrolle la automatización de la recuperación mediante los principios de la infraestructura como código (IaC). Esto hace que su entorno de recuperación sea coherente con el entorno de origen y permita controlar las versiones de sus procesos de recuperación. Para organizar flujos de trabajo de recuperación complejos, puede usar soluciones como [AWSSystems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) o [AWS Step Functions](https://aws.amazon.com/step-functions/).
La automatización de los procesos de recuperación ofrece beneficios importantes y puede ayudar a alcanzar el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) con mayor facilidad. Sin embargo, pueden encontrarse con situaciones inesperadas que tal vez provoquen fallos o creen nuevos riesgos por su parte, como un mayor tiempo de inactividad y la pérdida de datos. Para mitigar este riesgo, ofrezca la posibilidad de detener rápidamente una automatización de la recuperación en curso. Una vez detenida, puede investigar y tomar medidas correctivas.
En el caso de las cargas de trabajo compatibles, puede probar soluciones como la recuperación elástica ante desastres de AWS (AWS DRS) para proporcionar una conmutación por error automatizada. AWS DRS replica continuamente las máquinas (incluido el sistema operativo, la configuración del estado del sistema, las bases de datos, las aplicaciones y los archivos) en un área provisional de su cuenta de Cuenta de AWS de destino y en la región preferida. Si se produce un incidente, AWS DRS automatiza la conversión de los servidores replicados en cargas de trabajo totalmente aprovisionadas en la región de recuperación en AWS.
El mantenimiento y la mejora de la recuperación automática son un proceso continuo. Pruebe y perfeccione continuamente sus procedimientos de recuperación en función de las lecciones aprendidas y manténgase al tanto de los nuevos servicios y características de AWS que pueden mejorar sus capacidades de recuperación.
### Pasos para la implementación
1. **Planifique una recuperación automatizada**
1. Realice una revisión exhaustiva de la arquitectura, los componentes y las dependencias de su carga de trabajo para identificar y planificar los mecanismos de recuperación automatizados. Clasifique las dependencias de su carga de trabajo en dependencias *estrictas* y *flexibles*. Las dependencias estrictas son imprescindibles y sin ellas la carga de trabajo no puede funcionar; además, no se puede ofrecer ninguna alternativa. Las dependencias flexibles son aquellas que suele utilizar la carga de trabajo, pero que pueden sustituirse por sistemas o procesos alternativos de manera temporal o que pueden gestionarse mediante una [degradación estable](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation).
1. Establezca procesos para identificar y recuperar los datos dañados o ausentes.
1. Defina los pasos para confirmar un estado estable recuperado una vez finalizadas las acciones de recuperación.
1. Considere cualquier acción necesaria para que el sistema recuperado esté listo para funcionar plenamente, como precalentar y llenar las cachés.
1. Considere los problemas que podrían surgir durante el proceso de recuperación y cómo detectarlos y solucionarlos.
1. Plantéese situaciones en las que no se pueda acceder al sitio principal y a su plano de control. Compruebe que las acciones de recuperación se puedan realizar de forma independiente sin depender del sitio principal. Puede usar soluciones como el [controlador de recuperación de aplicaciones de Amazon (ARC)](https://aws.amazon.com/application-recovery-controller/) para redirigir el tráfico sin necesidad de mutar manualmente los registros de DNS.
1. **Desarrolle un proceso de recuperación automatizado**
1. Implemente mecanismos automatizados de detección de fallos y conmutación por error para una recuperación sin intervención manual. Cree paneles de control, como [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/), para informar sobre el progreso y el estado de los procedimientos de recuperación automatizados. Incluya procedimientos para validar una recuperación correcta. Proporcione un mecanismo para interrumpir una recuperación en curso.
1. Cree [guías de estrategia](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency) como un proceso alternativo para los errores que no permitan una recuperación automática y tenga en cuenta su [plan de recuperación ante desastres](https://aws.amazon.com/disaster-recovery/faqs/#Core_concepts).
1. Pruebe los procesos de recuperación tal y como se describe en [REL13-BP03.](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html)
1. **Prepárese para la recuperación**
1. Evalúe el estado de su sitio de recuperación e implemente los componentes críticos en él con antelación. Para obtener más información, consulte [REL13-BP04.](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)
1. Defina funciones, responsabilidades y procesos de toma de decisiones claros para las operaciones de recuperación, con la participación de las partes interesadas y los equipos pertinentes de toda la organización.
1. Defina las condiciones para iniciar los procesos de recuperación.
1. Cree un plan para revertir el proceso de recuperación y vuelva a su sitio principal si es necesario o después de considerarlo seguro.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL07-BP01 Uso de la automatización al obtener o escalar recursos](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 Supervisión de todos los componentes de la carga de trabajo para detectar errores](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_withstand_component_failures_monitoring_health.html)
+ [REL13-BP02 Uso de estrategias de recuperación definidas para cumplir los objetivos de recuperación](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Prueba de la implementación de recuperación ante desastres para validarla](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html)
+ [REL13-BP04 Administración de la desviación de la configuración en el sitio o región de DR](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)
**Documentos relacionados:**
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperación de desastres de cargas de trabajo en AWS: recuperación en la nube (documento técnico de AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Orchestrate Disaster Recovery Automation using Amazon Route 53 ARC and AWS Step Functions](https://aws.amazon.com/blogs/networking-and-content-delivery/orchestrate-disaster-recovery-automation-using-amazon-route-53-arc-and-aws-step-functions/)
+ [Build AWS Systems Manager Automation runbooks using AWS CDK](https://aws.amazon.com/blogs/mtbuild-aws-systems-manager-automation-runbooks-using-aws-cdk/)
+ [AWS Marketplace: productos que pueden usarse para la recuperación ante desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [Using Elastic Disaster Recovery for Failover and Failback](https://docs.aws.amazon.com/drs/latest/userguide/failback.html)
+ [AWS Elastic Disaster Recovery Resources](https://aws.amazon.com/disaster-recovery/resources/)
+ [Socio de APN: socios que pueden ayudar con la recuperación ante desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
**Videos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2022: AWS On Air ft. AWS Failback for AWS Elastic Disaster Recovery](https://youtu.be/Ok-vpV8b1Hs)