# REL 13 ¿Cómo planifica 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 sus objetivos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) para la restauración de su carga 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 coste 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.
**Topics**
+ [REL13-BP01 Definir objetivos de recuperación para la inactividad y la pérdida de datos](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Usar estrategias de recuperación definidas para cumplir los objetivos de recuperación](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Probar la implementación de recuperación de desastres para validarla](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Administrar la desviación de la configuración en el sitio de o en la región de recuperación de desastres](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Automatizar la recuperación](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Definir objetivos de recuperación para la inactividad y la pérdida de datos
La carga de trabajo tiene un objetivo de tiempo de recuperación (RTO) y un objetivo de punto de recuperación (RPO).
*Objetivo de tiempo de recuperación (RTO)* es el retraso máximo aceptable entre la interrupción del servicio y su restablecimiento. Esto determina lo que se considera un intervalo de tiempo aceptable cuando el servicio no está disponible.
*Objetivo de punto de recuperación (RPO)* es el periodo de tiempo máximo aceptable desde el último punto de recuperación de datos. Determina lo que se considera una pérdida aceptable de datos entre el último punto de recuperación y la interrupción del servicio.
Los valores de RTO y RPO son consideraciones importantes a la hora de seleccionar una estrategia de recuperación de desastres (DR) adecuada para su carga de trabajo. Estos objetivos los determina la empresa y los utilizan los equipos técnicos para seleccionar e implementar una estrategia de recuperación de desastres.
**Resultado deseado:**
Cada carga de trabajo tiene un RTO y un RPO asignados, definidos en función del impacto empresarial. La carga de trabajo se asigna en un nivel predefinido, lo que define la disponibilidad del servicio y la pérdida de datos aceptable, con un RTO y un RPO asociados. Si no es posible esta jerarquización, se puede asignar de forma personalizada por carga de trabajo, con la intención de crear niveles más adelante. RTO y RPO se utilizan como una de las principales consideraciones para la selección de la implementación de una estrategia de recuperación de desastres para la carga de trabajo. Otras consideraciones a la hora de elegir una estrategia de recuperación de desastres son las restricciones de costes, las dependencias de la carga de trabajo y los requisitos operativos.
Para RTO, entienda el impacto basado en la duración de una interrupción. ¿Es lineal o hay implicaciones no lineales? (por ejemplo, después de cuatro horas, se cierra una línea de fabricación hasta el comienzo del siguiente turno).
Una matriz de recuperación de desastres, como la siguiente, puede ayudarle a entender cómo se relaciona la criticidad de la carga de trabajo con los objetivos de recuperación. (Tenga en cuenta que los valores reales de los ejes X e Y deben adaptarse a las necesidades de su organización).
![\[Gráfico que muestra la matriz de recuperación de desastres\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**Patrones de uso no recomendados comunes:**
+ No hay objetivos de recuperación definidos.
+ Seleccionar objetivos de recuperación arbitrarios.
+ Seleccionar objetivos de recuperación demasiado permisivos y no satisfacer los objetivos empresariales
+ No entender el impacto del tiempo de inactividad y la pérdida de datos.
+ Seleccionar objetivos de recuperación poco realistas, como el tiempo de recuperación cero y la pérdida de datos cero, que pueden no ser alcanzables para la configuración de su carga de trabajo.
+ Seleccionar objetivos de recuperación más estrictos que los objetivos empresariales reales Esto obliga a realizar implementaciones de recuperación de desastres más costosas y complejas de lo que necesita la carga de trabajo.
+ Seleccionar objetivos de recuperación incompatibles con los de una carga de trabajo dependiente.
+ Sus objetivos de recuperación no tienen en cuenta los requisitos de cumplimiento normativo.
+ RTO y RPO definidos para una carga de trabajo, pero nunca se han probado.
**Beneficios de establecer esta práctica recomendada:** Los objetivos de recuperación de tiempo y pérdida de datos son necesarios para guiar su implementación de DR.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
Para la carga de trabajo dada, debe entender el impacto del tiempo de inactividad y la pérdida de datos en su empresa. Por lo general, el impacto aumenta con un mayor tiempo de inactividad o pérdida de datos, pero la forma de este crecimiento puede variar en función del tipo de carga de trabajo. Por ejemplo, puede ser capaz de tolerar un tiempo de inactividad de hasta una hora con poco impacto, pero después el impacto aumenta rápidamente. El impacto en la empresa se manifiesta de muchas formas, como el coste económico (por ejemplo, la pérdida de ingresos), la confianza de los clientes (y el impacto en la reputación), los problemas operativos (por ejemplo, la pérdida de nóminas o la disminución de la productividad) y el riesgo normativo. Siga estos pasos para entender estos impactos y establecer RTO y RPO para su carga de trabajo.
**Pasos de implementación**
1. Determine las partes interesadas de su empresa para esta carga de trabajo y colabore con ellas para implementar estos pasos. Los objetivos de recuperación de una carga de trabajo son una decisión empresarial. Después, los equipos técnicos trabajan con las partes interesadas de la empresa para utilizar estos objetivos para seleccionar una estrategia de recuperación de desastres.
**nota**
Para los pasos 2 y 3, puede usar la [Hoja de trabajo de implementación](#implementation-worksheet).
1. Responda a las preguntas siguientes para reunir la información necesaria a fin de tomar una decisión.
1. ¿Tiene categorías o niveles de criticidad para el impacto de la carga de trabajo en su organización?
1. En caso afirmativo, asigne esta carga de trabajo a una categoría.
1. En caso contrario, establezca estas categorías. Cree un máximo de cinco categorías y ajuste el intervalo de su objetivo de tiempo de recuperación para cada una. Algunos ejemplos de categorías son: crítica, alta, media, baja. Para entender cómo se asignan las cargas de trabajo a las categorías, considere si la carga de trabajo es de misión crítica, importante para la empresa o no lo es.
1. Establezca el RTO y el RPO de la carga de trabajo en función de la categoría. Acceda a este paso para elegir siempre una categoría más estricta (RTO y RPO más bajos) que los valores sin procesar calculados. Si esto da lugar a un cambio de valor inadecuado, considere la posibilidad de crear una nueva categoría.
1. Según estas respuestas, asigne los valores de RTO y RPO a la carga de trabajo. Se puede hacer directamente o mediante la asignación de la carga de trabajo a un nivel de servicio predefinido.
1. Documente el plan de recuperación de desastres (DRP) de esta carga de trabajo, que forma parte del [plan de continuidad del negocio (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)de su organización, en una ubicación accesible al equipo de la carga de trabajo y las partes interesadas.
1. Registre el RTO y el RPO, así como la información utilizada para determinar estos valores. Incluya la estrategia que se utiliza para evaluar el impacto de la carga de trabajo en la empresa.
1. Registre otras métricas, además de RTO y RPO, de las que hace un seguimiento o planifica hacerlo para los objetivos de recuperación de desastres.
1. Agregará los detalles de su estrategia de recuperación de desastres y su runbook a este plan cuando los cree.
1. Si busca la criticidad de la carga de trabajo en una matriz como la de la figura 15, puede empezar a establecer los niveles de servicio predefinidos para su organización.
1. Después de haber implementado una estrategia de recuperación de desastres (o una prueba de concepto para una estrategia de este tipo) según [REL13-BP02 Usar estrategias de recuperación definidas para cumplir los objetivos de recuperación](rel_planning_for_recovery_disaster_recovery.md), pruebe esta estrategia para determinar la capacidad de tiempo de recuperación (RTC) y de punto de recuperación (RPC) reales de la carga de trabajo. Si no cumplen los objetivos de recuperación previstos, es posible colaborar con las partes interesadas de su empresa para ajustar dichos objetivos o realizar cambios en la estrategia de RD para cumplir los objetivos previstos.
**Preguntas principales**
1. ¿Cuál es el tiempo máximo que la carga de trabajo puede estar inactiva antes de que se produzca un impacto grave en la empresa?
1. Determine el coste económico (impacto financiero directo) para la empresa por minuto si se interrumpe la carga de trabajo.
1. Considere que el impacto no siempre es lineal. El impacto puede ser limitado al principio e ir aumentando rápidamente a partir de un punto crítico.
1. ¿Cuál es la cantidad máxima de datos que puede perderse antes de que se produzca un impacto grave en la empresa?
1. Considere este valor para su almacén de datos más crítico. Identifique la criticidad correspondiente de otros almacenes de datos.
1. ¿Se pueden recrear los datos de la carga de trabajo si se pierden? Si esto es operativamente más fácil que la copia de seguridad y la restauración, elija el RPO en función de la criticidad de los orígenes de los datos que se utilizan para recrear 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 esta (descendente), o de las cargas de trabajo que dependen de esta (ascendente)?
1. Elija objetivos de recuperación que permitan a esta carga de trabajo cumplir los requisitos de las dependencias ascendentes.
1. Elija objetivos de recuperación que sean alcanzables teniendo en cuenta las capacidades de recuperación de las dependencias descendentes. Se pueden excluir las dependencias descendentes no críticas (aquellas que puede «resolver»). O bien, trabaje con las dependencias críticas posteriores para mejorar sus capacidades de recuperación cuando sea necesario.
**Preguntas adicionales**
Considere estas preguntas y cómo pueden aplicarse a esta carga de trabajo:
1. ¿Tiene diferentes RTO y RPO en función del tipo de interrupción región con respecto a AZ, etc.)?
1. ¿Hay algún momento específico (estacionalidad, eventos de ventas, lanzamientos de productos) en el que pueda cambiar su RTO/RPO? Si es así, ¿cuál es el límite de medida y tiempo diferente?
1. ¿Cuántos clientes se verán afectados si se interrumpe la carga de trabajo?
1. ¿Cuál es el impacto en la reputación si se interrumpe la carga de trabajo?
1. ¿Qué otros impactos operativos pueden producirse si se interrumpe la carga de trabajo? Por ejemplo, el impacto en la productividad de los empleados si los sistemas de correo electrónico no están disponibles o si los sistemas de nómina no pueden enviar las transacciones.
1. ¿Cómo se alinean el RTO y el RPO de la carga de trabajo con la línea de negocio y la estrategia organizativa de recuperación de desastres?
1. ¿Existen obligaciones contractuales internas para la prestación de un servicio? ¿Existen sanciones por incumplirlas?
1. ¿Cuáles son las restricciones normativas o de cumplimiento con los datos?
## Hoja de trabajo de implementación
Puede utilizar esta hoja de trabajo para implementar los pasos 2 y 3. Puede ajustar esta hoja de trabajo para adaptarla a sus necesidades específicas, por ejemplo, puede agregar preguntas adicionales.
![\[Hoja de trabajo\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/worksheet.png)
**Nivel de esfuerzo para el plan de implementación: **Bajo
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL09-BP04 Realizar una recuperación periódica de los datos para verificar la integridad de la copia de seguridad y los procesos](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 Usar estrategias de recuperación definidas para cumplir los objetivos de recuperación](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Probar la implementación de recuperación de desastres para validarla](rel_planning_for_recovery_dr_tested.md)
**Documentos relacionados:**
+ [Blog de arquitectura de AWS: serie de recuperación de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperación de desastres de las 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)
+ [Managing resiliency policies with AWS Resilience Hub (Administración de 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 de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: productos que pueden usarse para la recuperación de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Patrones de arquitectura para aplicaciones activas-activas en varias regiones) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Disaster Recovery of Workloads on AWS (Recuperación de desastres de cargas de trabajo en AWS)](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 Usar 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.
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 Definir objetivos de recuperación para la 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) dentro de 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, debería elegir una de las siguientes estrategias. Se indican en orden ascendente de coste y complejidad y en orden descendente en cuanto al RTO y RPO. *Una región de recuperación* es una Región de AWS diferente a la principal que se usa para su carga de trabajo.
![\[Diagrama que muestra estrategias de DR\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **Generación de copias de seguridad y restauración** (RPO en horas, RTO en 24 horas o menos): cree una copia de seguridad de sus datos y aplicaciones en la región de recuperación. El uso de copias de seguridad automatizadas o continuas permitirá la recuperación a un momento dado, lo que puede reducir el RPO a hasta 5 minutos en algunos casos. En caso de desastre, desplegará su infraestructura (utilizando la infraestructura como código para reducir el RTO), desplegará su 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 principal de su carga de trabajo en la región de recuperación. Replique sus datos en la región de recuperación y cree copias de seguridad de estos allí. 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 despliegan, 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 totalmente funcional de su carga de trabajo ejecutándose continuamente 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 amplía 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 alcanza su plena escala, la espera pasa a denominarse **espera activa**.
+ **Activa-activa multirregión (multisitio)** (RPO próximo a cero, RTO potencial de cero): la carga de trabajo está desplegada en varias Regiones de AWS y entrega tráfico de forma activa desde estas regiones. Esta estrategia requiere que sincronice datos entre regiones. Los posibles conflictos causados por escrituras en el mismo registro en dos diferentes réplicas regionales deben evitarse o gestionarse, lo que puede resultar complejo. La replicación de datos es útil para la sincronización de datos y le protegerá 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 a 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 acciones 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 despliegue infraestructura adicional (no principal) y que escale verticalmente, mientras que la espera semiactiva solo requiere que escale verticalmente (ya está todo desplegado y en ejecución). Elija una de estas opciones en función de sus necesidades de RTO y RPO.
**Resultado deseado:**
Para cada carga de trabajo, existe una estrategia de DR definida e implementada que permite que esa 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 de uso no recomendados comunes:**
+ 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 plan de DR.
+ 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 permite un intercambio de conocimiento más eficiente entre equipos y una implementación más sencilla 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
Consulte más abajo los detalles de cada uno de estos pasos.
1. Determine una estrategia de DR que satisfaga los requisitos de recuperación de esta carga de trabajo.
1. Revise los patrones de implementación de la estrategia de DR seleccionada.
1. Evalúe los recursos de su 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 la operación normal).
1. Determine e implemente cómo preparará su región de recuperación para la conmutación por error cuando sea necesario (durante un evento de desastre).
1. Determine e implemente cómo redirigirá su tráfico a la conmutación por error cuando sea necesario (durante un evento de desastre).
1. Diseñe un plan para la recuperación tras error de su carga de trabajo.
**Pasos de implementación**
1. **Determine una estrategia de DR 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) por un lado, y los costes y la complejidad de implementar la estrategia por otro lado. Debería evitar implementar una estrategia que sea más exigente de lo necesario, ya que esto supone costes 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 coste.
![\[Gráfico que muestra una estrategia de DR basada en el RTO y el coste\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)
Para obtener 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 implementación de la estrategia de DR seleccionada.**
Este paso implica comprender cómo implementará la estrategia seleccionada. Las estrategias se explican utilizando 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 pasos posteriores a este, aplicará la estrategia a su carga de trabajo específica.
**Generación de copias de seguridad y restauración**
*Generación de copias de seguridad y restauración* es la estrategia menos compleja de implementar, pero requiere más tiempo y esfuerzo para restaurar la carga de trabajo, lo que genera un mayor RTO y RPO. Se recomienda realizar siempre copias de seguridad de los datos y copiarlas en otro sitio (por ejemplo, otra Región de AWS).
![\[Diagrama que muestra una arquitectura de copia de seguridad y restauración\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)
Para obtener más información sobre esta estrategia, consulte [Arquitectura de recuperación de desastres (DR) en AWS, parte II: copia de seguridad y restauración con recuperación rápida](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* , replica sus datos de la región principal en la región de recuperación. Los recursos principales utilizados para la infraestructura de la carga de trabajo se despliegan 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 despliegan instancias de computación.
![\[Diagrama que muestra una arquitectura de luz piloto\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
Para obtener más información sobre esta estrategia, consulte [Arquitectura de recuperación de desastres (DR) en AWS, parte III: luz piloto y espera semiactiva](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Espera semiactiva**
La *espera semiactiva* supone garantizar que exista una copia con desescalada vertical pero con plena funcionalidad de su 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 despliega a plena capacidad, esto se denomina *espera activa*.
![\[Diagrama que muestra la figura 21 con arquitectura de espera semiactiva\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)
El uso de la espera semiactiva o la luz piloto requiere escalar verticalmente los recursos en la región de recuperación. Para garantizar que la capacidad esté disponible cuando sea necesario, piense en usar [reservas de capacidad](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) para instancias EC2. Si usa AWS Lambda, la [concurrencia aprovisionada](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) puede garantizar los entornos de ejecución de modo que estén preparados para responder inmediatamente a las invocaciones de su función.
Para obtener más información sobre esta estrategia, consulte [Arquitectura de recuperación de desastres (DR) en AWS, parte III: luz piloto y espera semiactiva](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Activa-activa multisitio**
Puede ejecutar su carga de trabajo de forma simultánea en varias regiones como parte de una estrategia *activa-activa multisitio* . La estrategia activa-activa multisitio sirve tráfico desde todas las regiones en las que se despliega. Los clientes podrían seleccionar esta estrategia por motivos ajenos a la DR. Se puede usar para aumentar la disponibilidad o cuando se despliega una carga de trabajo para una audiencia global (para colocar el punto de conexión más cerca de los usuarios o para desplegar 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 esté desplegada, esa región se evacúa y las regiones restantes se usan para mantener la disponibilidad. La estrategia activa-activa multisitio es la más compleja operativamente de las estrategias de DR y solamente debería seleccionarse cuando los requisitos empresariales lo exijan.
![\[Diagrama que muestra una arquitectura activa-activa multisitio\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)
Para obtener más información sobre esta estrategia, consulte [Arquitectura de recuperación de desastres (DR) en AWS, parte IV: activa-activa multisitio](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**Prácticas adicionales para la protección de datos**
Con todas las estrategias, también debe mitigar los posibles desastres de datos. La replicación de datos continua le protegerá 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 a un momento dado. También debe realizar una copia de seguridad de los datos replicados en el sitio de recuperación para crear copias de seguridad a un momento dado además de las réplicas.
**Uso de varias zonas de disponibilidad (AZ) en una única Región de AWS**
Al usar varias AZ en una única región, su implementación de DR utiliza varios elementos de las estrategias anteriores. Primero, debe crear una arquitectura de alta disponibilidad utilizando varias AZ, como se muestra en la figura 23. Esta arquitectura emplea una estrategia activa-activa multisitio, ya que las [instancias Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) y el [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) tienen recursos desplegados en varias AZ y gestionan activamente las solicitudes. La arquitectura también demuestra espera activa, mediante la que si la instancia [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) principal falla (o si falla la AZ en sí), la instancia en espera pasa a ser la principal.
![\[Diagrama que muestra la figura 23 con arquitectura multi-AZ\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
Además de esta arquitectura de alta disponibilidad, necesita agregar copias de seguridad con todos los datos necesarios para ejecutar su carga de trabajo. Esto es especialmente importante para datos que estén limitados a una única zona, como los [volúmenes de Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) o bien [los clústeres de Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Si falla 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.
La DR multi-AZ es un enfoque alternativo menos habitual a la región única, y se ejemplifica en esta publicación de blog: [Crear aplicaciones altamente resilientes mediante Amazon Route 53 Application Recovery Controller, parte 1: pila de una sola región](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, igual que 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 los 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 multi-AZ ofrecen una buena protección contra la mayor parte de los desastres.
1. **Evalúe los recursos de su 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 la operación normal).**
Para la infraestructura y los recursos de AWS, use infraestructura como código, como [AWS CloudFormation](https://aws.amazon.com/cloudformation) , o herramientas de terceros, como Hashicorp Terraform. Para desplegar en varias cuentas y regiones con una única operación, puede usar [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). En las estrategias activa-activa multisitio o de espera activa, la infraestructura desplegada en su región de recuperación tiene los mismos recursos que su región principal. En las estrategias de luz piloto y espera semiactiva, la infraestructura desplegada requerirá acciones adicionales para prepararse para la producción. En CloudFormation, con sus [parámetros](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) y [su lógica condicional](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html), puede controlar si una pila desplegada está activa o en espera con una única plantilla. Un ejemplo de una de estas plantillas de CloudFormation se incluye en [esta publicación de blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
Todas las estrategias de DR requieren que los orígenes de datos tengan una copia de seguridad en la Región de AWS y que esta se copie en la región de recuperación. [AWS Backup](https://aws.amazon.com/backup/) ofrece una vista centralizada desde la que puede configurar, programar y supervisar copias de seguridad de esos recursos. En el caso de las opciones de luz piloto, espera semiactiva y activa-activa multisitio, también debería replicar los datos de la región principal en los recursos de datos de la región de recuperación, como las instancias de base 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 obtener más información sobre cómo los servicios de AWS operan entre regiones, consulte esta serie de blog sobre la [creación de una aplicación multirregión con servicios de AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Determine e implemente cómo preparará su región de recuperación para la conmutación por error cuando sea necesario (durante un evento de 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, sus acciones de recuperación tendrán que desplegar los recursos faltantes, como las instancias 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 la copia de seguridad y la restauración, la restauración de datos desde una copia de seguridad crea recursos para esos datos, como volúmenes EBS, instancias de bases de datos RDS y tablas de DynamoDB. También tiene que restaurar la infraestructura y desplegar el código. Puede usar AWS Backup para restaurar datos en la región de recuperación. Consulte [REL09-BP01 Identificar todos los datos de los que se debe hacer una copia de seguridad y crearla o reproducir los datos a partir de los orígenes](rel_backing_up_data_identified_backups_data.md) para obtener más información. La reconstrucción de la infraestructura incluye la creación de recursos como instancias EC2 además de las [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. Para aprender cómo, consulte [esta publicación de blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **Determine e implemente cómo redirigirá su tráfico a la conmutación por error cuando sea necesario (durante un evento de desastre).**
Esta operación de conmutación por error se puede iniciar automáticamente o manualmente. La conmutación por error iniciada automáticamente basada en comprobaciones de estado o alarmas se debe usar 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 usar servicios de AWS. Una opción es usar [Amazon Route 53](https://aws.amazon.com/route53). Al usar Amazon Route 53, puede asociar varios puntos de conexión de IP en una o varias Regiones de AWS con un nombre de dominio de Route 53. Para implementar la conmutación por error iniciada manualmente, puede usar [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/), que proporciona una API de plano de datos con alta disponibilidad para redirigir el tráfico a la región de recuperación. Al implementar la conmutación por error, use las operaciones del plano de datos y evite las del plano de control, como se describe en [REL11-BP04 Confiar 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 obtener 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 para la recuperación tras error de su carga de trabajo.**
La recuperación tras error es cuando se devuelve la operación de una carga de trabajo a la región principal una vez que amaina un evento de desastre. El aprovisionamiento de la infraestructura y el código en la región principal generalmente sigue los mismos pasos que se utilizaron inicialmente, recurriendo a la infraestructura como código y las canalizaciones de despliegue del código. El reto que plantea la recuperación tras error es restaurar los almacenes de datos y asegurarse de 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 resincronizar desde la región de recuperación a la región principal, garantizando así que esté actualizada.
Algunos servicios de AWS harán esto automáticamente. Si utiliza [tablas globales de Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/), incluso si la tabla en la región principal ha dejado de estar disponible, cuando vuelva a estar online, DynamoDB volverá a propagar las escrituras pendientes. Si utiliza [una base de datos global de Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) y utiliza 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), entonces se mantiene la topología de replicación existente de la base de datos global de Aurora. Por tanto, la instancia de lectoescritura 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. Por ejemplo, para ver instrucciones sobre cómo hacer esto con una base de datos global de Amazon Aurora suponiendo una conmutación por error *no planificada* , consulte este laboratorio: [Recuperación tras error de una base de datos global](https://awsauroralabsmy.com/global/failback/).
Tras una conmutación por error, si puede seguir operando en su región de recuperación, plantéese convertir esta región en la nueva región principal. Seguiría realizando 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 la restauración tras error deben mantenerse en una guía de estrategias que esté a disposición de todos los miembros del equipo y se revise periódicamente.
**Nivel de esfuerzo para el plan de implementación**: alto
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL09-BP01 Identificar todos los datos de los que se debe hacer una copia de seguridad y crearla o reproducir los datos a partir de los orígenes](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Confiar 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 Definir objetivos de recuperación para la inactividad y la pérdida de datos](rel_planning_for_recovery_objective_defined_recovery.md)
**Documentos relacionados:**
+ [Blog de arquitectura de AWS: serie de recuperación de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperación de desastres de las 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)
+ [Crear una solución backend activa-activa sin servidor en varias regiones en una hora](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Backend sin servidor en varias regiones: actualizado](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: configuración de la conmutación por error de DNS](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)
+ [¿Qué es Route 53 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: primeros pasos - 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 de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Vídeos relacionados:**
+ [Recuperación de desastres de cargas de trabajo en AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: patrones de arquitectura para aplicaciones activas-activas en varias regiones (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Introducción a AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**Ejemplos relacionados:**
+ [Laboratorios de AWS Well-Architected : recuperación de desastres](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - Serie de talleres en los que se ilustran las estrategias de DR
# REL13-BP03 Probar la implementación de recuperación de desastres para validarla
Compruebe habitualmente la conmutación por error a su sitio de recuperación para garantizar un funcionamiento adecuado y que se cumplan el RTO y el RPO.
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 el almacén principal falla, 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 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.
**Patrones de uso no recomendados comunes:**
+ 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 garantizan que el plan funcione cuando llegue el momento y que su equipo sepa cómo ejecutar la estrategia.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Diseñe sus cargas de trabajo para que se puedan recuperar. Compruebe periódicamente sus rutas de recuperación. La informática orientada a la recuperación identifica las características en los sistemas que mejoran la recuperación. Estas características son: 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 asegurarse de que pueda cumplir la recuperación en el tiempo especificado para el estado especificado. Use sus runbooks durante esta recuperación para documentar los problemas y encontrar soluciones para ellos antes de la próxima prueba.
+ [Proyecto de informática orientada a la recuperación de Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ Use Recuperación de desastres de CloudEndure para implementar y probar su estrategia de recuperación de desastres.
+ [Probar la solución de recuperación de desastres con CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Recuperación de desastres de CloudEndure en AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## 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)
+ [Blog de arquitectura de AWS: serie de recuperación de desastres](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)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Recuperación de desastres de las 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)
+ [Probar la solución de recuperación de desastres con CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [Proyecto de informática orientada a la recuperación de Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ [¿Qué es AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Patrones de arquitectura para aplicaciones activas-activas en varias regiones (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Copia de seguridad y restauración y soluciones de recuperación de desastres con AWS (STG208)](https://youtu.be/7gNXfo5HZN8)
**Ejemplos relacionados:**
+ [Laboratorios de AWS Well-Architected: comprobación de resiliencia](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 Administrar la desviación de la configuración en el sitio de o en la región de recuperación de desastres
Asegúrese de que la infraestructura, los datos y la configuración estén cuando se necesiten en el sitio o región de DR. Por ejemplo, compruebe que las AMI y las cuotas de servicio están actualizadas.
AWS Config supervisa y registra continuamente las configuraciones de sus recursos de AWS. Puede detectar la desviación y desencadenar [Automatización de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) para solucionarlo y generar alarmas. Además, AWS CloudFormation puede detectar la desviación en las pilas que ha desplegado.
**Patrones de uso no recomendados comunes:**
+ No realizar actualizaciones en sus ubicaciones de recuperación, cuando realice cambios de configuración o de infraestructura en sus ubicaciones primarias.
+ No considerar las posibles limitaciones (como las diferencias en los servicios) en las ubicaciones principales y de recuperación.
**Beneficios de establecer esta práctica recomendada:** Comprobar que su entorno de DR es coherente con el entorno existente garantiza una recuperación completa.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Asegúrese de que sus canalizaciones de entrega realizan la entrega tanto al sitio principal como al de copia de seguridad. Las canalizaciones de entrega para implementar aplicaciones en producción deben distribuir la entrega a todas las ubicaciones de la estrategia de recuperación de desastres especificadas, incluidos los entornos de desarrollo y pruebas.
+ Habilite AWS Config para realizar un seguimiento de las posibles ubicaciones con desviaciones. Use reglas de AWS Config para crear sistemas que apliquen sus estrategias de recuperación de desastres y creen alertas si detectan divergencias.
+ [Corrección de recursos de AWS disconformes con Reglas de AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [Automatización de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Use AWS CloudFormation para desplegar su infraestructura. AWS CloudFormation puede detectar la desviación entre lo que especifican sus plantillas de CloudFormation y lo que realmente está desplegado.
+ [AWS CloudFormation: detectar desviaciones en una pila completa de CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## 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)
+ [Blog de arquitectura de AWS: serie de recuperación de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation: detectar desviaciones en una pila completa de CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Marketplace: productos que pueden usarse para la recuperación de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [Automatización de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Recuperación de desastres de las 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)
+ [¿Cómo implemento una solución de administración de la configuración de la infraestructura en AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Corrección de recursos de AWS disconformes con Reglas de AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Patrones de arquitectura para aplicaciones activas-activas en varias regiones) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05 Automatizar la recuperación
Use AWS o herramientas de terceros para automatizar la recuperación del sistema y dirigir el tráfico al sitio o región de DR.
En función de las comprobaciones de estado configuradas, los servicios de AWS, como Elastic Load Balancing y AWS Auto Scaling, pueden distribuir la carga a zonas de disponibilidad en buen estado mientras que los servicios, como Amazon Route 53 y AWS Global Accelerator, pueden dirigir la carga a Regiones de AWS en buen estado. Amazon Route 53 Application Recovery Controller le ayuda a administrar y coordinar la conmutación por error mediante comprobaciones de idoneidad y funciones de control de enrutamiento. Estas características supervisan continuamente la capacidad de la aplicación de recuperarse de los errores, de modo que pueda controlar la recuperación de la aplicación en las distintas Regiones de AWS, zonas de disponibilidad y localmente.
Para cargas de trabajo en centros de datos físicos o virtuales existentes o nubes privadas, [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/), disponible en AWS Marketplace, permite a las organizaciones configurar una estrategia de recuperación de desastres automatizada en AWS. CloudEndure también admite la recuperación de desastres entre regiones o AZ en AWS.
**Antipatrones usuales:**
+ La implementación de técnicas de conmutación por error y de conmutación por recuperación idénticas puede producir una alteración cuando surge un error.
**Beneficios de establecer esta práctica recomendada:** La recuperación automatizada reduce el tiempo de recuperación al eliminar la posibilidad de que se produzcan errores manuales.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Automatice las rutas de recuperación. Para tiempos de recuperación cortos, las decisiones y las acciones humanas no pueden usarse para escenarios de alta disponibilidad. El sistema debe recuperarse automáticamente en cada situación.
+ Use la recuperación de desastres de Cloudendure para la conmutación por error y la restauración tras error automatizadas. La recuperación de desastres de CloudEndure replica continuamente las máquinas (incluido el sistema operativo, la configuración de estado del sistema, las bases de datos, las aplicaciones y los archivos) en un área de ensayo de bajo costo en su Cuenta de AWS de destino y región preferida. En caso de desastre, puede indicar a CloudEndure Disaster Recovery que lance automáticamente miles de máquinas en su estado aprovisionado completo en solo unos minutos.
+ [Realizar la conmutación por error y la conmutación por recuperación de recuperación de desastres](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## 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)
+ [Blog de arquitectura de AWS: serie de recuperación de desastres](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 Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Recuperación de desastres de CloudEndure en AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [Recuperación de desastres de las 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)
**Videos relacionados:**
+ [AWS re:Invent 2018: Patrones de arquitectura para aplicaciones activas-activas en varias regiones (ARC209-R2)](https://youtu.be/2e29I3dA8o4)