# Administración de errores
<a name="failure-management"></a>

****  
 Los fallos son un hecho y, con el tiempo, todo fallará: desde los enrutadores hasta los discos duros, desde los sistemas operativos hasta las unidades de memoria que corrompen los paquetes TCP, desde los errores transitorios hasta los fallos permanentes. Esto es un hecho, ya sea que utilice hardware de la más alta calidad o los componentes más económicos: [https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html](https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html) 

 Los fallos de componentes de hardware de bajo nivel son algo que hay que solucionar todos los días en un centro de datos en las instalaciones. Sin embargo, en la nube, debe protegerse contra la mayoría de estos tipos de errores. Por ejemplo, los volúmenes de Amazon EBS se colocan en una zona de disponibilidad específica, donde se replican automáticamente para protegerle en caso de error de un solo componente. Todos los volúmenes de EBS están diseñados para tener una disponibilidad del 99,999 %. Los objetos de Amazon S3 se almacenan en un mínimo de tres zonas de disponibilidad, lo que proporciona una durabilidad del 99,999999999 % durante un año natural. Independientemente del proveedor de servicios en la nube, existe la posibilidad de que los fallos afecten a su carga de trabajo. Por lo tanto, debe tomar medidas para implementar la resiliencia si necesita que su carga de trabajo sea fiable. 

 Un requisito previo para aplicar las prácticas que se analizan aquí es asegurarse de que las personas que diseñan, implementan y operan sus cargas de trabajo conozcan los objetivos empresariales y los objetivos de fiabilidad necesarios para lograrlos. Estas personas deben conocer estos requisitos de fiabilidad y haber recibido la formación para cumplir con ellos. 

 En las siguientes secciones se explican las prácticas recomendadas para gestionar los fallos y evitar que afecten a la carga de trabajo.

**Topics**
+ [Copia de seguridad de los datos](back-up-data.md)
+ [Uso del aislamiento de errores para proteger su carga de trabajo](use-fault-isolation-to-protect-your-workload.md)
+ [Diseño de la carga de trabajo para que tolere los errores de los componentes](design-your-workload-to-withstand-component-failures.md)
+ [Pruebas de fiabilidad](test-reliability.md)
+ [Planificación de la recuperación de desastres (DR)](plan-for-disaster-recovery-dr.md)

# Copia de seguridad de los datos
<a name="back-up-data"></a>

 Haga copias de seguridad de los datos, las aplicaciones y la configuración para cumplir con los requisitos de objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO). 

**Topics**
+ [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)
+ [REL09-BP02 Protección y cifrado de copias de seguridad](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 Copias de seguridad automáticas de los datos](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 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)

# 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
<a name="rel_backing_up_data_identified_backups_data"></a>

Comprenda y use las funciones de copia de seguridad de los servicios y recursos de datos usados por la carga de trabajo. La mayoría de los servicios ofrecen capacidades para crear copias de seguridad de los datos de la carga de trabajo. 

 **Resultado deseado:** se han identificado y clasificado los orígenes de datos según su criticidad. A continuación, establezca una estrategia de recuperación de datos basada en el RPO. Esta estrategia supone crear una copia de seguridad de estos orígenes de datos o tener la capacidad de reproducir datos desde otros orígenes. En el caso de pérdida de datos, la estrategia implementada permite recuperar o reproducir los datos dentro de los RPO y RTO definidos. 

 **Fase de madurez de la nube:** básica 

 **Patrones comunes de uso no recomendados:** 
+  No ser consciente de todos los orígenes de datos de la carga de trabajo y su nivel de gravedad. 
+  No crear copias de seguridad de los orígenes de datos críticos. 
+  Crear copias de seguridad solamente de algunos orígenes de datos sin usar la criticidad como criterio. 
+  RPO sin definir o una frecuencia de copias de seguridad que no puede ajustarse al RPO. 
+  No evaluar si una copia de seguridad es necesaria o si se pueden reproducir datos desde otros orígenes. 

 **Beneficios de establecer esta práctica recomendada:** identificar los lugares en los que se necesitan copias de seguridad e implementar un mecanismo para crearlas, o poder reproducir los datos desde un origen externo, mejora la capacidad de restaurar y recuperar los datos durante una interrupción. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Todos los almacenes de datos de AWS ofrecen capacidades de copia de seguridad. En los servicios como Amazon RDS y Amazon DynamoDB también se pueden hacer copias de seguridad automatizadas, lo que facilita la recuperación en un momento dado (PITR). De este modo, podrá restaurar una copia de seguridad a cualquier momento hasta cinco minutos (o menos) antes del momento actual. Muchos servicios de AWS ofrecen la posibilidad de copiar las copias de seguridad a otra Región de AWS. AWS Backup es una herramienta que le permite centralizar y automatizar la protección de datos en todos los servicios de AWS. [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) le permite copiar cargas de trabajo completas del servidor y mantener una protección continua de los datos en las instalaciones, entre zonas de disponibilidad o entre regiones, con un objetivo de punto de recuperación (RPO) medido en segundos. 

 Amazon S3 puede usarse como destino de las copias de seguridad para los orígenes de datos autoadministrados y administrados por AWS. Los servicios de AWS como Amazon EBS, Amazon RDS y Amazon DynamoDB tienen capacidades integradas para crear copias de seguridad. También se puede usar software de copias de seguridad de terceros. 

 Se pueden hacer copias de seguridad de los datos en las instalaciones en la Nube de AWS con [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) o [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). Los buckets de Amazon S3 se pueden utilizar para almacenar estos datos en AWS. Amazon S3 ofrece varios niveles de almacenamiento, como [Amazon Glacier o Amazon Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html), para reducir el costo del almacenamiento de datos. 

 Es posible que pueda satisfacer las necesidades de recuperación de datos mediante la reproducción de los datos desde otros orígenes. Por ejemplo, los [nodos de réplica de Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) o las [réplicas de lectura de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) podrían usarse para reproducir datos si se pierde el elemento principal. En aquellos casos en que los orígenes como este se puedan utilizar para cumplir su [objetivo de punto de recuperación (RPO) y objetivo de tiempo de recuperación (RTO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html), es posible que no necesite ninguna copia de seguridad. Otro ejemplo: si trabaja con Amazon EMR, puede que no sea necesario hacer copias de seguridad del almacén de datos de HDFS, siempre y cuando pueda [reproducir los datos en Amazon EMR desde Amazon S3](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/). 

 Al seleccionar una estrategia de copia de seguridad, piense en el tiempo que se necesita para recuperar los datos. El tiempo necesario para recuperar datos depende del tipo de copia de seguridad (en el caso de una estrategia de copia de seguridad) o de la complejidad del mecanismo de reproducción de datos. Este tiempo debería ajustarse al RTO de la carga de trabajo. 

 **Pasos para la implementación** 

1.  **Identifique todos los orígenes de datos de la carga de trabajo**. Los datos se pueden almacenar en varios recursos, como [bases de datos](https://aws.amazon.com/products/databases/), [volúmenes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html), [sistemas de archivos](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), [sistemas de registro](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) y [almacenamiento de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). Consulte la sección **Recursos** para encontrar **documentos relacionados** sobre los diferentes servicios de AWS en los que se almacenan los datos y la capacidad de copia de seguridad que ofrecen estos servicios. 

1.  **Clasifique los orígenes de datos según su criticidad.** Los distintos conjuntos de datos tendrán diferentes niveles de criticidad para una carga de trabajo y, por tanto, distintos requisitos de resiliencia. Por ejemplo, algunos datos podrían ser críticos y requerir un RPO cercano a cero, mientras que otros datos podrían ser menos críticos y tolerar un RPO más alto y cierta pérdida de datos. Del mismo modo, los distintos conjuntos de datos podrían tener también diferentes requisitos en cuanto al RTO. 

1.  **Uso de AWS o servicios de terceros para crear copias de seguridad de los datos**. [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) es un servicio administrado que permite crear copias de seguridad de diversos orígenes de datos en AWS. [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) administra la replicación automatizada de datos en menos de un segundo a una Región de AWS. La mayoría de los servicios de AWS también disponen de capacidades nativas para crear copias de seguridad. AWS Marketplace tiene muchas soluciones que ofrecen también estas capacidades. Consulte la sección **Recursos** que aparece a continuación para obtener información sobre cómo crear copias de seguridad de los datos de distintos servicios de AWS. 

1.  **Establezca un mecanismo de reproducción de datos para los datos que no tengan copia de seguridad**. Puede decidir no crear una copia de seguridad de datos que puedan reproducirse desde otros orígenes y por distintos motivos. Podría darse una situación en la que sea más barato reproducir datos de orígenes cuando sea necesario en lugar de crear una copia de seguridad, ya que podría existir un costo asociado con el almacenamiento de copias de seguridad. Otro ejemplo es cuando la restauración desde una copia de seguridad tarda más tiempo que la reproducción de los datos desde el origen, lo que implica un incumplimiento del RTO. En tales situaciones, sopese los pros y los contras y establezca un proceso bien definido sobre cómo se pueden reproducir los datos desde estos orígenes cuando sea necesaria una recuperación de los datos. Por ejemplo, si ha cargado datos desde Amazon S3 en un almacenamiento de datos (como Amazon Redshift) o un clúster de MapReduce (como Amazon EMR) para analizar dichos datos, esto podría ser un ejemplo de datos que se pueden reproducir desde otros orígenes. Siempre y cuando los resultados de estos análisis se almacenen en algún lugar o sean reproducibles, no sufriría ninguna pérdida de datos por un error en el almacenamiento de datos o el clúster de MapReduce. Otros ejemplos que se pueden reproducir desde el origen son las cachés (como Amazon ElastiCache) o las réplicas de lectura de RDS. 

1.  **Establezca una cadencia para hacer copias de seguridad de los datos**. La creación de copias de seguridad de orígenes de datos es un proceso periódico y la frecuencia debería depender del RPO. 

 **Nivel de esfuerzo para el plan de implementación:** moderado 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 

[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) 

 **Documentos relacionados:** 
+  [Qué es AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [What is AWS DataSync?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) 
+  [What is Volume Gateway?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) 
+  [Socio de APN: socios que pueden ayudar con la copia de seguridad](https://aws.amazon.com/partners/find/results/?keyword=Backup) 
+  [AWS Marketplace: productos que pueden usarse para la copia de seguridad](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) 
+  [Instantáneas de Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html) 
+  [Backing Up Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html) 
+  [Backing up Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html) 
+  [Backup and Restore for ElastiCache for Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html) 
+  [Creating a DB Cluster Snapshot in Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html) 
+  [Creación de una instantánea de base de datos](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html) 
+  [Creating an EventBridge Rule That Triggers on a Schedule](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) 
+  [Replicación entre regiones](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) con Amazon S3 
+  [AWS Backup de EFS a EFS](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/) 
+  [Exporting Log Data to Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 
+  [Administración del ciclo de vida del almacenamiento](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html) 
+  [Copia de seguridad y restauración bajo demanda para DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html) 
+  [Recuperación a un momento dado en DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html) 
+  [Working with Amazon OpenSearch Service Index Snapshots](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html) 
+ [ What is AWS Elastic Disaster Recovery? ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)

 **Videos relacionados:** 
+  [AWS re:Invent 2021 - Backup, disaster recovery, and ransomware protection with AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc) 
+  [AWS Backup Demo: Cross-Account and Cross-Region Backup](https://www.youtube.com/watch?v=dCy7ixko3tE) 
+  [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc) 

# REL09-BP02 Protección y cifrado de copias de seguridad
<a name="rel_backing_up_data_secured_backups_data"></a>

Controle y detecte el acceso a las copias de seguridad con autenticación y autorización. Evite que la integridad de los datos de las copias de seguridad se vea comprometida (y detecte los casos en los que así sea) mediante el cifrado.

 Implemente controles de seguridad para evitar el acceso no autorizado a los datos de copia de seguridad. Cifre las copias de seguridad para proteger la confidencialidad y la integridad de los datos. 

 **Patrones comunes de uso no recomendados:** 
+  Tener el mismo acceso a las automatizaciones de las copias de seguridad y restauración que a los datos. 
+  No cifrar las copias de seguridad. 
+  No se implementa la inmutabilidad como protección contra la eliminación o la manipulación. 
+  Se usa el mismo dominio de seguridad para los sistemas de producción y de copia de seguridad. 
+  No se valida la integridad de las copias de seguridad mediante pruebas periódicas. 

 **Beneficios de establecer esta práctica recomendada:** 
+  La protección de las copias de seguridad impide que se manipulen los datos y el cifrado de los datos impide el acceso a esos datos si se exponen de forma accidental. 
+  Protección mejorada contra el ransomware y otras ciberamenazas que afectan a la infraestructura de copia de seguridad. 
+  Reducción del tiempo de recuperación tras un ciberincidente mediante procesos de recuperación validados. 
+  Capacidades de continuidad empresarial mejoradas durante los incidentes de seguridad. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Controle y detecte el acceso a las copias de seguridad con autenticación y autorización, como AWS Identity and Access Management (IAM). Evite que la integridad de los datos de las copias de seguridad se vea comprometida (y detecte los casos en los que así sea) mediante el cifrado. 

 Amazon S3 admite varios métodos de cifrado de los datos en reposo. Con el cifrado del servidor, Amazon S3 acepta sus objetos como datos sin cifrar y después los cifra a medida que se almacenan. Con el cifrado del cliente, la aplicación de la carga de trabajo es la responsable de cifrar los datos antes de que se envíen a Amazon S3. Ambos métodos le permiten utilizar AWS Key Management Service (AWS KMS) para crear y almacenar la clave de los datos, o puede facilitar la suya propia, de la que será responsable. Con AWS KMS, puede establecer políticas con IAM sobre quién puede acceder a sus claves de datos y datos descifrados y quién no. 

 Para Amazon RDS, si ha decidido cifrar las bases de datos, sus copias de seguridad también estarán cifradas. Las copias de seguridad de DynamoDB siempre están cifradas. Al usar AWS Elastic Disaster Recovery, todos los datos en tránsito y en reposo están cifrados. Con la Recuperación de desastres elástica, los datos en reposo se pueden cifrar con la clave de cifrado de volumen predeterminada de Amazon EBS o una clave personalizada administrada por el cliente. 

 **Consideraciones sobre la resiliencia cibernética** 

 Para mejorar la seguridad de las copias de seguridad frente a las ciberamenazas, considere la posibilidad de implementar estos controles adicionales además del cifrado: 
+  Implemente la inmutabilidad mediante AWS Backup Vault Lock o el bloqueo de objetos de Amazon S3 para evitar que los datos de copia de seguridad se alteren o eliminen durante su periodo de retención, protegiéndolos contra el ransomware y la eliminación malintencionada. 
+  Establezca un aislamiento lógico entre los entornos de producción y de copia de seguridad con un almacén aislado lógicamente de AWS Backup para los sistemas críticos, lo que crea una separación que ayuda a evitar que ambos entornos se vean comprometidos simultáneamente. 
+  Valide la integridad de las copias de seguridad con regularidad mediante pruebas de restauración de AWS Backup para comprobar que las copias de seguridad no están dañadas y que se pueden restaurar correctamente tras un ciberincidente. 
+  Implemente la aprobación de varias partes para las operaciones de recuperación críticas mediante la aprobación de varias partes de AWS Backup para evitar intentos de recuperación no autorizados o malintencionados, exigiendo la autorización de varios aprobadores designados. 

### Pasos para la implementación
<a name="implementation-steps"></a>

1.  Use el cifrado en cada uno de los almacenes de datos. Si los datos de origen están cifrados, la copia de seguridad también estará cifrada. 
   + [Utilice el cifrado en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html). Puede configurar el cifrado en reposo mediante AWS Key Management Service al crear una instancia de RDS. 
   + [Use el cifrado en volúmenes de Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html). Puede configurar el cifrado predeterminado o especificar una clave única al crear los volúmenes. 
   +  Use el [cifrado de Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) requerido. DynamoDB cifra todos los datos en reposo. Puede utilizar una clave de AWS propiedad de AWS KMS o una clave de KMS administrada por AWS, siempre que especifique una clave que esté almacenada en su cuenta. 
   + [Cifre los datos almacenados en Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html). Configure el cifrado cuando cree el sistema de archivos. 
   +  Configure el cifrado en las regiones de origen y destino. Puede configurar el cifrado en reposo en Amazon S3 con las claves almacenadas en KMS, pero las claves son específicas de la región. Puede especificar las claves de destino cuando configure la replicación. 
   +  Elija si desea utilizar el cifrado predeterminado o utilizar el [cifrado personalizado de Amazon EBS para la Recuperación de desastres elástica](https://docs.aws.amazon.com/drs/latest/userguide/volumes-drs.html#ebs-encryption). Esta opción cifrará sus datos replicados en reposo en los discos de la subred de la zona de preparación y en los discos replicados. 

1.  Implemente permisos de privilegio mínimo para acceder a las copias de seguridad. Siga las prácticas recomendadas para limitar el acceso a las copias de seguridad, instantáneas y réplicas de acuerdo con las [prácticas recomendadas de seguridad](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html). 

1.  Configure la inmutabilidad de las copias de seguridad críticas. En el caso de los datos críticos, implemente AWS Backup Vault Lock o el bloqueo de objetos de S3 para evitar que se eliminen o modifiquen durante el periodo de retención especificado. Para conocer los detalles de implementación, consulte [AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html). 

1.  Cree una separación lógica para los entornos de copia de seguridad. Implemente un almacén aislado lógicamente de AWS Backup para los sistemas críticos que requieren una protección mejorada contra las ciberamenazas. Para obtener una guía de implementación, consulte [Building cyber resiliency with AWS Backup logically air-gapped vault](https://aws.amazon.com/blogs/storage/building-cyber-resiliency-with-aws-backup-logically-air-gapped-vault/). 

1.  Implemente procesos de validación de copias de seguridad. Configure las pruebas de restauración de AWS Backup para comprobar que las copias de seguridad no están dañadas y que se pueden restaurar correctamente tras un ciberincidente. Para obtener más información, consulte [Validate recovery readiness with AWS Backup restore testing](https://aws.amazon.com/blogs/storage/validate-recovery-readiness-with-aws-backup-restore-testing/). 

1.  Configure la aprobación de varias partes para las operaciones de recuperación confidenciales. En el caso de los sistemas críticos, implemente la aprobación de varias partes de AWS Backup para solicitar la autorización de varios aprobadores designados antes de que pueda continuar con la recuperación. Para obtener información detallada sobre la implementación, consulte [Improve recovery resilience with AWS Backup support for Multi-party approval](https://aws.amazon.com/blogs/storage/improve-recovery-resilience-with-aws-backup-support-for-multi-party-approval/). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Marketplace: productos que pueden usarse para la copia de seguridad](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) 
+  [Amazon EBS Encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) 
+  [Amazon S3: protección de los datos mediante el cifrado](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) 
+  [Configuración adicional de CRR: replicación de objetos creados con el cifrado del servidor (SSE) usando las claves de cifrado almacenadas en AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html) 
+  [Cifrado en reposo en DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) 
+  [Encrypting Amazon RDS Resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) 
+  [Encrypting Data and Metadata in Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) 
+  [Encryption for Backups in AWS](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html) 
+  [Administración de tablas de cifrado](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html) 
+  [Pilar de seguridad: Marco de AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) 
+ [ What is AWS Elastic Disaster Recovery? ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [FSISEC11: ¿Cómo se protege contra el ransomware?](https://docs.aws.amazon.com/wellarchitected/latest/financial-services-industry-lens/fsisec11.html)
+ [Ransomware Risk Management on AWS Using the NIST Cyber Security Framework](https://docs.aws.amazon.com/whitepapers/latest/ransomware-risk-management-on-aws-using-nist-csf/welcome.html)
+  [Building cyber resiliency with AWS Backup logically air-gapped vault](https://aws.amazon.com/blogs/storage/building-cyber-resiliency-with-aws-backup-logically-air-gapped-vault/) 
+  [Validate recovery readiness with AWS Backup restore testing](https://aws.amazon.com/blogs/storage/validate-recovery-readiness-with-aws-backup-restore-testing/) 
+  [Improve recovery resilience with AWS Backup support for Multi-party approval](https://aws.amazon.com/blogs/storage/improve-recovery-resilience-with-aws-backup-support-for-multi-party-approval/) 

 **Ejemplos relacionados:** 
+ [Implementing Bi-Directional Cross-Region Replication (CRR) for Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)

# REL09-BP03 Copias de seguridad automáticas de los datos
<a name="rel_backing_up_data_automated_backups_data"></a>

Configure las copias de seguridad para que se creen automáticamente con arreglo a un calendario periódico determinado por el objetivo de punto de recuperación (RPO) o cuando se produzcan cambios en el conjunto de datos. En el caso de los conjuntos de datos críticos con requisitos de pérdida de datos bajos, es necesario crear una copia de seguridad automática con frecuencia, mientras que en el de los datos menos críticos para los que resultan aceptables ciertas pérdidas, las copias de seguridad pueden ser menos frecuentes.

 **Resultado deseado:** un proceso automatizado que crea copias de seguridad de los orígenes de datos con una cadencia establecida. 

 **Patrones comunes de uso no recomendados:** 
+  Hacer las copias de seguridad manualmente. 
+  Usar recursos que tengan la función de copia de seguridad, pero no incluir la copia de seguridad en la automatización. 

 **Beneficios de establecer esta práctica recomendada:** al automatizar las copias de seguridad, se comprueba que se hagan con regularidad en función del RPO y, si no se hacen, se avisa al usuario. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio 

## Guía para la implementación
<a name="implementation-guidance"></a>

 AWS Backup se puede usar para crear copias de seguridad automatizadas de los datos de diversos orígenes de datos de AWS. Es posible crear copias de seguridad de las instancias de Amazon RDS casi de forma continua cada cinco minutos, y de los objetos de Amazon S3 cada quince minutos, lo que facilita una recuperación en un momento dado (PITR) a un punto específico del historial de copias de seguridad. Para otros orígenes de datos de AWS, como los volúmenes de Amazon EBS, las tablas de Amazon DynamoDB o los sistemas de archivos de Amazon FSx, AWS Backup puede ejecutar una copia de seguridad automatizada con una frecuencia que puede llegar a ser de una hora. Estos servicios también ofrecen capacidades de copia de seguridad nativas. Los servicios de AWS que ofrecen copias de seguridad automatizadas con recuperación en un momento dado son [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html), [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html) y [Amazon Keyspaces (para Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html), que se pueden restaurar a un momento específico del historial de copias de seguridad. La mayoría del resto de servicios de almacenamiento de datos de AWS ofrecen la capacidad de programar copias de seguridad periódicas, con una frecuencia que puede llegar a ser de una hora. 

 Amazon RDS y Amazon DynamoDB ofrecen copias de seguridad continuas con recuperación en un momento dado. El control de versiones de Amazon S3, una vez activado, es automático. Se puede utilizar [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) para automatizar la creación, retención y eliminación de instantáneas de Amazon EBS. También puede automatizar la creación, copia, desuso y anulación de registro de imágenes de máquina de Amazon (AMI) basadas en Amazon EBS y sus instantáneas de Amazon EBS subyacentes. 

 AWS Elastic Disaster Recovery proporciona replicación continua en el nivel de bloque desde el entorno de origen (en las instalaciones o AWS) a la región de recuperación de destino. El servicio crea y administra automáticamente instantáneas de Amazon EBS de un momento dado. 

 Para obtener una vista centralizada de la automatización y el historial de sus copias de seguridad, AWS Backup proporciona una solución de copia de seguridad totalmente administrada y basada en políticas. Centraliza y automatiza la copia de seguridad de datos entre varios servicios de AWS en la nube y en el entorno en las instalaciones con AWS Storage Gateway. 

 De forma adicional al control de versiones, Amazon S3 incluye también replicación. Todo el bucket de S3 se puede replicar automáticamente en otro bucket de la misma Región de AWS o una diferente. 

 **Pasos para la implementación** 

1.  **Identifique los orígenes de datos** de los que se están haciendo copias de seguridad manualmente. Para obtener más informació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). 

1.  **Determine el RPO** de la carga de trabajo. Para obtener más información, consulte [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). 

1.  **Use una solución de copia de seguridad automatizada o un servicio administrado**. AWS Backup es un servicio totalmente administrado que facilita la [centralización y automatización de la protección de datos en todos los servicios de AWS, en la nube y en las instalaciones](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). Mediante planes de copia de seguridad en AWS Backup, cree reglas que definan de qué recursos se debe hacer copia de seguridad y con qué frecuencia deben crearse. Esta frecuencia debe determinarla el RPO establecido en el paso 2. Para obtener orientación práctica sobre cómo crear copias de seguridad automatizadas mediante AWS Backup, consulte [Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/). La mayoría de los servicios de AWS que almacenan datos ofrecen capacidades de copia de seguridad nativas. Por ejemplo, se puede utilizar RDS para hacer copias de seguridad automatizadas con recuperación en un momento dado (PITR). 

1.  **En el caso de los orígenes de datos que no sean compatibles** con una solución de copia de seguridad automatizada o un servicio administrado, como los orígenes de datos en las instalaciones o las colas de mensajes, considere la posibilidad de utilizar una solución de terceros de confianza para crear copias de seguridad automatizadas. Como alternativa, puede crear una automatización que se encargue de esto con la AWS CLI o algún SDK. Puede usar funciones de AWS Lambda o AWS Step Functions para definir la lógica implicada en la creación de una copia de seguridad de datos y utilizar Amazon EventBridge para invocarla con una frecuencia basada en el RPO. 

 **Nivel de esfuerzo para el plan de implementación:** bajo 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Socio de APN: socios que pueden ayudar con la copia de seguridad](https://aws.amazon.com/partners/find/results/?keyword=Backup) 
+  [AWS Marketplace: productos que pueden usarse para la copia de seguridad](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) 
+  [Creating an EventBridge Rule That Triggers on a Schedule](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) 
+  [¿Qué es AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [¿Qué es AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) 
+ [ What is AWS Elastic Disaster Recovery? ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)

 **Videos relacionados:** 
+  [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc) 

# REL09-BP04 Recuperación periódica de los datos para verificar la integridad de la copia de seguridad y los procesos
<a name="rel_backing_up_data_periodic_recovery_testing_data"></a>

Valide que su implementación del proceso de copia de seguridad cumpla con los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO) mediante una prueba de recuperación.

 **Resultado deseado:** los datos de las copias de seguridad se recuperan periódicamente mediante mecanismos bien definidos para verificar que la recuperación sea posible dentro del objetivo de tiempo de recuperación (RTO) establecido para la carga de trabajo. Verifique que la restauración a partir de una copia de seguridad dé como resultado un recurso que contenga los datos originales sin que ninguno de ellos resulte dañado o inaccesible, y una pérdida de datos coherente con el objetivo de punto de recuperación (RPO). 

 **Patrones comunes de uso no recomendados:** 
+  Restaurar una copia de seguridad, pero no consultar ni recuperar ningún dato para comprobar que la restauración sea posible. 
+  Suponer que existe una copia de seguridad. 
+  Suponer que la copia de seguridad de un sistema está plenamente operativa y que es posible recuperar datos de ella. 
+  Suponer que el tiempo de restauración o recuperación de datos de una copia de seguridad entra dentro del RTO para la carga de trabajo. 
+  Suponer que los datos que contiene la copia de seguridad están dentro del RPO para la carga de trabajo 
+  Restaurar cuando sea necesario, sin usar un manual de procedimientos, o fuera de un procedimiento automatizado. 

 **Beneficios de establecer esta práctica recomendada:** al probar la recuperación de las copias de seguridad, se comprueba que los datos se pueden restaurar cuando sea necesario sin preocuparse de que falten datos o estén dañados, de que la restauración y la recuperación sean posibles dentro del RTO de la carga de trabajo y que cualquier pérdida de datos recaiga dentro del RPO correspondiente a la carga de trabajo. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio 

## Guía para la implementación
<a name="implementation-guidance"></a>

 La comprobación de la capacidad de copia de seguridad y restauración aumenta la confianza en la capacidad de llevar a cabo estas acciones durante una interrupción. Restaure periódicamente las copias de seguridad en una nueva ubicación y lleve a cabo pruebas para verificar la integridad de los datos. Algunas de las pruebas habituales que deberían efectuarse consisten en comprobar que todos los datos estén disponibles, no estén dañados, sean accesibles y si la pérdida de datos (si la hay) se ajusta al RPO de la carga de trabajo. Estas pruebas también pueden ayudar a determinar si los mecanismos de recuperación son lo suficientemente rápidos como para tener capacidad para el RTO de la carga de trabajo. 

 Con AWS, puede crear un entorno de pruebas y restaurar sus copias de seguridad para evaluar las capacidades en cuanto al RTO y al RPO y llevar a cabo pruebas sobre el contenido y la integridad de los datos. 

 Además, Amazon RDS y Amazon DynamoDB permiten la recuperación en un momento dado (PITR). Mediante la copia de seguridad continua, puede restaurar su conjunto de datos al estado en el que se encontraba en una fecha y hora específicas. 

 Si todos los datos están disponibles, no están dañados, son accesibles y la pérdida de datos (si la hay) se ajusta al RPO de la carga de trabajo. Estas pruebas también pueden ayudar a determinar si los mecanismos de recuperación son lo suficientemente rápidos como para tener capacidad para el RTO de la carga de trabajo. 

 AWS Elastic Disaster Recovery ofrece instantáneas de recuperación en un momento dado continuas de volúmenes de Amazon EBS. A medida que se replican los servidores de origen, los estados de un momento dado se cronifican en el tiempo en función de la política configurada. La Recuperación de desastres elástica ayuda a verificar la integridad de estas instantáneas mediante el lanzamiento de instancias con fines de prueba y simulacro sin redirigir el tráfico. 

 **Pasos para la implementación** 

1.  **Identifique los orígenes de datos** de los que se están haciendo copias de seguridad actualmente y dónde se almacenan dichas copias de seguridad. Para obtener una guía para la implementació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). 

1.  **Establezca los criterios de validación de datos** para cada origen de datos. Los diferentes tipos de datos tendrán distintas propiedades, lo que podría requerir diferentes mecanismos de validación. Considere cómo se podrían validar estos datos antes de contar con la confianza suficiente para usarlos en producción. Algunas formas habituales de validar los datos son usar las propiedades de datos y copias de seguridad como el tipo de datos, el formato, la suma de comprobación, el tamaño o una combinación de ellas con lógica de validación personalizada. Por ejemplo, podría tratarse de una comparación de los valores de las sumas de comprobación entre el recurso restaurado y el origen de datos en el momento en que se creó la copia de seguridad. 

1.  **Establezca el RTO y el RPO** para restaurar los datos según su importancia. Para obtener una guía para la implementación, consulte [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). 

1.  **Evalúe su capacidad de recuperación.** Revise su estrategia de copia de seguridad y restauración para comprender si se ajusta a su RTO y RPO y ajuste la estrategia según sea necesario. Con [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html), puede evaluar la carga de trabajo. La evaluación compara la configuración de su aplicación con la política de resiliencia y notifica si se pueden cumplir los objetivos de RTO y RPO. 

1.  **Ejecute una restauración de prueba** con los procesos actualmente establecidos que se utilizan en la producción para la restauración de datos. Estos procesos dependen de cómo se haya creado la copia de seguridad del origen de datos, el formato y la ubicación del almacenamiento de la copia de seguridad, o de si los datos se reproducen desde otros orígenes. Por ejemplo, si utiliza un servicio administrado, como [AWS Backup, podría ser tan sencillo como restaurar la copia de seguridad en un nuevo recurso](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html). Si usó AWS Elastic Disaster Recovery, puede [iniciar un simulacro de recuperación](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html). 

1.  **Valide la recuperación de datos** del recurso restaurado en función de los criterios que estableció previamente para la validación de los datos. ¿Los datos restaurados y recuperados contienen el registro o elemento más reciente en el momento de la copia de seguridad? ¿Estos datos se ajustan al RPO de la carga de trabajo? 

1.  **Calcule el tiempo necesario** para la restauración y la recuperación y compárelo con el RTO establecido. ¿Este proceso se ajusta al RTO de la carga de trabajo? Por ejemplo, compare las marcas de tiempo del momento en que se inició el proceso de restauración y de cuando se completó la validación de la recuperación para calcular cuánto tarda este proceso. Todas las llamadas a la API de AWS llevan una marca de tiempo y esta información está disponible en [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Aunque esta información puede proporcionar detalles sobre cuándo se inició el proceso de restauración, la marca de tiempo final del momento en que finalizó la validación debería quedar registrada mediante su lógica de validación. Si se utiliza un proceso automatizado, se pueden utilizar servicios como [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) para almacenar esta información. Además, muchos servicios de AWS proporcionan un historial de eventos que facilita información con marcas de tiempo cuando ocurren determinadas acciones. En AWS Backup, las acciones de copia de seguridad y restauración se denominan *trabajos*, y estos trabajos contienen información sobre la marca de tiempo como parte de sus metadatos, que se puede utilizar para medir el tiempo necesario para la restauración y la recuperación. 

1.  **Notifique a las partes interesadas** si se produce un error en la validación de los datos o si el tiempo necesario para la restauración y la recuperación supera el RTO establecido para la carga de trabajo. Al implementar la automatización para que lo haga, [como en este laboratorio](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/), se pueden utilizar servicios como Amazon Simple Notification Service (Amazon SNS) para enviar notificaciones push, como correos electrónicos o SMS, a las partes interesadas. [Estos mensajes también se pueden publicar en aplicaciones de mensajería como Amazon Chime, Slack o Microsoft Teams](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/), o se pueden usar para [crear tareas como OpsItems con el Centro de operaciones de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html). 

1.  **Automatice este proceso para que se ejecute periódicamente**. Por ejemplo, se pueden usar servicios como AWS Lambda o una máquina de estados en AWS Step Functions para automatizar los procesos de restauración y recuperación, mientras que se puede usar Amazon EventBridge para invocar este flujo de trabajo de automatización periódicamente como se muestra en el siguiente diagrama de arquitectura. Obtenga información sobre cómo [automatizar la validación de recuperación de datos con AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/). Además, en [este laboratorio de Well-Architected](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) se ofrece una experiencia práctica sobre una forma de ejecutar la automatización de varios de los pasos que se describen aquí. 

![\[Diagrama en el que se muestra un proceso de copia de seguridad y restauración automatizado\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/automated-backup-restore-process.png)


 **Nivel de esfuerzo para el plan de implementación:** de moderado a alto, según la complejidad de los criterios de validación. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Automate data recovery validation with AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/) 
+  [Socio de APN: socios que pueden ayudar con la copia de seguridad](https://aws.amazon.com/partners/find/results/?keyword=Backup) 
+  [AWS Marketplace: productos que pueden usarse para la copia de seguridad](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) 
+  [Creating an EventBridge Rule That Triggers on a Schedule](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) 
+  [Copia de seguridad y restauración bajo demanda para DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html) 
+  [Qué es AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [Qué es AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) 
+  [Qué es AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) 
+  [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 

# Uso del aislamiento de errores para proteger su carga de trabajo
<a name="use-fault-isolation-to-protect-your-workload"></a>

El aislamiento de fallos limita el impacto de un fallo en un componente o sistema a un límite definido. Mediante un aislamiento adecuado, los componentes que se encuentran fuera del límite no se ven afectados por el error. Hacer que la carga de trabajo supere varios límites de aislamiento de fallos puede hacer que sea más resistente a los fallos.

**Topics**
+ [REL10-BP01 Implementación de la carga de trabajo en varias ubicaciones](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Automatización de la recuperación de los componentes restringidos a una sola ubicación](rel_fault_isolation_single_az_system.md)
+ [REL10-BP03 Uso de arquitecturas herméticas para limitar el alcance del impacto](rel_fault_isolation_use_bulkhead.md)

# REL10-BP01 Implementación de la carga de trabajo en varias ubicaciones
<a name="rel_fault_isolation_multiaz_region_system"></a>

 Distribuya los datos y los recursos de la carga de trabajo entre varias zonas de disponibilidad o, si es necesario, entre varias Regiones de AWS. 

 Un principio fundamental para el diseño de servicios en AWS es evitar puntos únicos de error, incluida la infraestructura física subyacente. AWS proporciona recursos y servicios de computación en la nube a nivel internacional en múltiples ubicaciones geográficas denominadas [regiones](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/regions.html). Cada región es independiente física y lógicamente y consta de tres o más [zonas de disponibilidad (AZ)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html). Las zonas de disponibilidad están geográficamente cerca unas de otras, pero están físicamente separadas y aisladas. Cuando distribuye sus cargas de trabajo entre las zonas y regiones de disponibilidad, mitiga el riesgo de amenazas como incendios, inundaciones, desastres relacionados con el clima, terremotos y errores humanos. 

 Cree una estrategia de ubicación para ofrecer una alta disponibilidad que sea adecuada para las cargas de trabajo. 

 **Resultado deseado:** las cargas de trabajo de producción se distribuyen entre varias zonas de disponibilidad (AZ) o regiones para lograr la tolerancia a los errores y una alta disponibilidad. 

 **Patrones comunes de uso no recomendados:** 
+  La carga de trabajo de producción solo existe en una sola zona de disponibilidad. 
+  Se implementa una arquitectura multirregional cuando una arquitectura Multi-AZ podría cumplir los requisitos empresariales. 
+  Las implementaciones o los datos se desincronizan, lo que provoca cambios en la configuración o una replicación insuficiente de los datos. 
+  No se tienen en cuenta las dependencias entre los componentes de la aplicación si los requisitos de resiliencia y de múltiples ubicaciones difieren entre esos componentes. 

 **Beneficios de establecer esta práctica recomendada:** 
+  Su carga de trabajo es más resistente a los incidentes, como los cortes de energía o de control ambiental, los desastres naturales, los fallos del servicio previo o los problemas de red que afectan a una zona de disponibilidad o a toda una región. 
+  Puede acceder a un inventario más amplio de instancias de Amazon EC2 y reducir la probabilidad de que se produzcan InsufentCapacityExceptions (ICE) al lanzar tipos de instancias EC2 específicos. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Implemente y opere todas las cargas de trabajo de producción en al menos dos zonas de disponibilidad (AZ) en una región. 

 **Uso de varias zonas de disponibilidad** 

 Las zonas de disponibilidad son ubicaciones de alojamiento de recursos que están separadas físicamente entre sí para evitar fallos correlacionados debidos a riesgos como incendios, inundaciones y tornados. Cada zona de disponibilidad tiene una infraestructura física independiente, que incluye conexiones eléctricas de servicios públicos, fuentes de energía de emergencia, servicios mecánicos y conectividad de red. Esta disposición limita los errores en cualquiera de estos componentes únicamente a la zona de disponibilidad afectada. Por ejemplo, si un incidente en toda la zona de disponibilidad hace que las instancias de EC2 no estén disponibles en la zona de disponibilidad afectada, las instancias de la otra zona de disponibilidad seguirán disponibles. 

 A pesar de estar separadas físicamente, las zonas de disponibilidad de la misma Región de AWS están lo suficientemente cerca como para proporcionar redes de alto rendimiento y baja latencia (milisegundos de un solo dígito). Puede replicar los datos de forma sincrónica entre las zonas de disponibilidad para la mayoría de las cargas de trabajo sin que ello afecte significativamente a la experiencia del usuario. Esto significa que puede utilizar las zonas de disponibilidad en una configuración activa/activa o activa/en espera. 

 Toda la computación asociada a su carga de trabajo debe distribuirse entre varias zonas de disponibilidad. Esto incluye instancias de [Amazon EC2](https://aws.amazon.com/ec2/), tareas y funciones de [AWS Fargate](https://aws.amazon.com/fargate/) y funciones conectadas a [AWS Lambda](https://aws.amazon.com/lambda/). Los servicios de computación de AWS, incluido [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/), [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) y [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/) (EKS), le proporcionan formas de lanzar y administrar el procesamiento en todas las zonas de disponibilidad. Configúrelos para reemplazar automáticamente el procesamiento según sea necesario en una zona de disponibilidad diferente para mantener la disponibilidad. Para dirigir el tráfico a las zonas de disponibilidad disponibles, coloque un equilibrador de cargas delante del equipo, como un Equilibrador de carga de aplicación o un Equilibrador de carga de red. Los equilibradores de carga de AWS pueden redirigir el tráfico a las instancias disponibles en caso de que la zona de disponibilidad se vea afectada. 

 También debe replicar los datos de su carga de trabajo y ponerlos a disposición en varias zonas de disponibilidad. Algunos servicios de datos gestionados de AWS, como [Amazon S3](https://aws.amazon.com/s3/), [Amazon Elastic File Service (EFS)](https://aws.amazon.com/efs/), [Amazon Aurora](https://aws.amazon.com/aurora/), [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [Amazon Simple Queue Service (SQS)](https://aws.amazon.com/sqs/) y [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/), replican los datos en varias zonas de disponibilidad de forma predeterminada y son robustos frente al deterioro de la zona de disponibilidad. Con otros servicios de datos gestionados de AWS, como [Amazon Relational Database Service (RDS)](https://aws.amazon.com/rds/), [Amazon Redshift](https://aws.amazon.com/redshift/) y [Amazon ElastiCache](https://aws.amazon.com/elasticache/), debe habilitar la replicación Multi-AZ. Una vez activados, estos servicios detectan automáticamente una alteración en la zona de disponibilidad, redirigen las solicitudes a una zona de disponibilidad disponible y vuelven a replicar los datos según sea necesario tras la recuperación sin la intervención del cliente. Familiarícese con la guía del usuario de cada servicio de datos gestionado de AWS que utilice para comprender las funciones, comportamientos y operaciones en zonas de disponibilidad múltiples. 

 Si utiliza un almacenamiento autogestionado, como los volúmenes de [Amazon Elastic Block Store (EBS)](https://aws.amazon.com/ebs/) o el almacenamiento de instancias de Amazon EC2, debe gestionar usted mismo la replicación en zonas de disponibilidad múltiples (Multi-AZ). 

![\[Diagrama en el que se muestra la arquitectura de varios niveles implementada en tres zonas de disponibilidad. Tenga en cuenta que Amazon S3 y Amazon DynamoDB siempre se implementan automáticamente en varias zonas de disponibilidad (Multi-AZ). El ELB también se implementa en las tres zonas.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/multi-tier-architecture.png)


 **Uso de múltiples Regiones de AWS** 

 Si tiene cargas de trabajo que requieren una capacidad de recuperación extrema (como infraestructuras críticas, aplicaciones relacionadas con la salud o servicios con requisitos de disponibilidad estrictos u obligatorios por parte del cliente), es posible que necesite una disponibilidad adicional más allá de lo que puede ofrecer una sola Región de AWS. En este caso, debe implementar y operar su carga de trabajo en al menos dos Regiones de AWS (siempre que sus requisitos de residencia de datos lo permitan). 

 Las Regiones de AWS se encuentran en diferentes regiones geográficas de todo el mundo y en varios continentes. Las Regiones de AWS tienen una separación física y un aislamiento aún mayores que las zonas de disponibilidad por sí solas. Los servicios de AWS, con pocas excepciones, aprovechan este diseño para funcionar de forma totalmente independiente entre diferentes regiones (también conocidos como *servicios regionales*). El fallo de un servicio en una Región de AWS está diseñado para no afectar al servicio en una región diferente. 

 Cuando utilice su carga de trabajo en varias regiones, debe tener en cuenta requisitos adicionales. Como los recursos de las distintas regiones están separados y son independientes los unos de los otros, debe duplicar los componentes de la carga de trabajo en cada región. Esto incluye la infraestructura básica, como las VPC, además de los servicios de computación y de datos. 

 **NOTA:** Cuando se plantee un diseño multirregional, compruebe que su carga de trabajo sea capaz de ejecutarse en una sola región. Si crea dependencias entre regiones en las que un componente de una región depende de servicios o componentes de una región diferente, puede aumentar el riesgo de fallos y reducir considerablemente su nivel de fiabilidad. 

 Para facilitar las implementaciones multirregionales y mantener la coherencia, los [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) pueden replicar toda su infraestructura de AWS en varias regiones. [AWS CloudFormation](https://aws.amazon.com/cloudformation/) también puede detectar cambios en la configuración e informarle cuando los recursos de AWS de una región no estén sincronizados. Muchos servicios de AWS ofrecen replicación multirregional para activos de carga de trabajo importantes. Por ejemplo, [Generador de imágenes de EC2](https://aws.amazon.com/image-builder/) puede publicar sus imágenes de máquina (AMI) de EC2 después de cada compilación en cada región que utilice. [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) puede replicar las imágenes del contenedor en las regiones seleccionadas. 

 También debe replicar los datos en cada una de las regiones que elija. Muchos servicios de datos gestionados de AWS ofrecen capacidad de replicación entre regiones, incluidos Amazon S3, Amazon DynamoDB, Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon ElastiCache, y Amazon EFS. Las [tablas globales de Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/) aceptan escrituras en cualquier región compatible y replicarán los datos en todas las demás regiones configuradas. Con otros servicios, debe designar una región principal para las escrituras, ya que otras regiones contienen réplicas de solo lectura. Para cada servicio de datos gestionado de AWS que utilice su carga de trabajo, consulte la guía del usuario y la guía para desarrolladores para comprender sus capacidades y limitaciones en varias regiones. Preste especial atención a dónde deben dirigirse las escrituras, a las capacidades y limitaciones de las transacciones, a cómo se lleva a cabo la replicación y a cómo supervisar la sincronización entre regiones. 

 AWS también ofrece la posibilidad de dirigir el tráfico de solicitudes a sus implementaciones regionales con gran flexibilidad. Por ejemplo, puede configurar sus registros DNS con [Amazon Route 53](https://aws.amazon.com/route53/) para dirigir el tráfico a la región disponible más cercana al usuario. Como alternativa, puede configurar sus registros DNS en una configuración activa/en espera, en la que designe una región como principal y recurra a una réplica regional solo si la región principal deja de estar en buen estado. Puede configurar las [comprobaciones de estado de Route 53](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover.html) para detectar puntos de conexión en mal estado y realizar una conmutación por error automática y, además, utilizar [Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/) para proporcionar un control de enrutamiento de alta disponibilidad para redireccionar el tráfico manualmente según sea necesario. 

 Incluso si decide no operar en varias regiones por motivos de alta disponibilidad, considere la posibilidad de hacerlo en varias regiones como parte de su estrategia de recuperación ante desastres (DR). Si es posible, replique los datos y los componentes de la infraestructura de su carga de trabajo en una configuración de *espera activa* o *piloto ligero* en una región secundaria. En este diseño, se replica la infraestructura de referencia de la región principal, como las VPC, los grupos de escalado automático, los orquestadores de contenedores y otros componentes, pero se configuran los componentes de tamaño variable de la región en espera (como el número de instancias de EC2 y réplicas de bases de datos) para que tengan un tamaño operativo mínimo. También puede organizar la replicación continua de los datos desde la región principal a la región en espera. Si se produce un incidente, puede escalar horizontalmente o aumentar los recursos de la región en espera y, después, convertirla en la región principal. 

### Pasos para la implementación
<a name="implementation-steps"></a>

1.  Coordínese con las partes interesadas de la empresa y los expertos en residencia de datos para determinar qué Regiones de AWS se pueden utilizar para alojar sus recursos y datos. 

1.  Contacte con las partes interesadas tanto a nivel técnico como empresarial para evaluar su carga de trabajo y determinar si sus necesidades de resiliencia pueden satisfacerse mediante un método Multi-AZ (una sola Región de AWS) o si requieren un enfoque multirregional (si se permiten varias regiones). El uso de varias regiones puede proporcionar una mayor disponibilidad, pero también puede suponer una complejidad y un coste adicionales. Tenga en cuenta los siguientes factores en la evaluación: 

   1.  **Objetivos empresariales y requisitos del cliente**: ¿cuánto tiempo de inactividad se permite en caso de que se produzca un incidente que afecte a la carga de trabajo en una zona o región de disponibilidad? Evalúe los objetivos de puntos de recuperación, tal como se describe en [REL13-BP01. Definición de objetivos de recuperación para el tiempo de inactividad y la pérdida de datos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html). 

   1.  **Requisitos de recuperación ante desastres (DR)**: ¿Contra qué tipo de posible desastre quiere asegurarse? Plantéese la posibilidad de que se produzcan pérdidas de datos o una falta de disponibilidad prolongada en diferentes ámbitos de impacto, desde una sola zona de disponibilidad hasta una región completa. Si replica los datos y los recursos en todas las zonas de disponibilidad y una sola zona de disponibilidad sufre un error prolongado, puede recuperar el servicio en otra zona de disponibilidad. Si replica los datos y los recursos en todas las regiones, puede recuperar el servicio en otra región. 

1.  Implemente los recursos informáticos en varias zonas de disponibilidad. 

   1.  En la VPC, cree varias subredes en diferentes zonas de disponibilidad. Configure cada una de ellas para que sea lo suficientemente grande como para albergar los recursos necesarios para atender la carga de trabajo, incluso durante un incidente. Para obtener más información, consulte [REL02-BP03 Garantía de que la asignación de subredes IP tenga en cuenta la expansión y la disponibilidad](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html). 

   1.  Si utiliza instancias de Amazon EC2, utilice [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) para gestionar las instancias. Especifique las subredes que haya elegido en el paso anterior al crear los grupos de escalado automático. 

   1.  Si utiliza la computación de AWS Fargate para [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) o [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html), seleccione las subredes que haya elegido en el primer paso al crear un servicio de ECS, lanzar una tarea de ECS o crear un [perfil de Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html) para EKS. 

   1.  Si utiliza funciones de AWS Lambda que deben ejecutarse en su VPC, seleccione las subredes que haya elegido en el primer paso al crear la función de Lambda. Para cualquier función que no tenga una configuración de VPC, AWS Lambda administra la disponibilidad automáticamente por usted. 

   1.  Coloque los directores de tráfico, como los equilibradores de carga, al frente de sus recursos informáticos. Si el equilibrio de carga entre zonas está activado, los [equilibradores de carga de aplicaciones de AWS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) y los [equilibradores de carga de red](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) detectan si no es posible contactar con los destinos, como las instancias de EC2 y los contenedores, debido al deterioro de la zona de disponibilidad y redirigen el tráfico hacia los destinos que se encuentran en las zonas de disponibilidad en buen estado. Si inhabilita el equilibrio de carga entre zonas, utilice Amazon Application Recovery Controller (ARC) para proporcionar la capacidad de cambio de zona. Si utiliza un equilibrador de carga de terceros o ha implementado sus propios equilibradores de carga, configúrelos con múltiples interfaces en diferentes zonas de disponibilidad. 

1.  Replique los datos de la carga de trabajo en varias zonas de disponibilidad. 

   1.  Si utiliza un servicio de datos gestionado de AWS, como Amazon RDS, Amazon ElastiCache o Amazon FSx, consulte detenidamente su guía del usuario para conocer sus capacidades de replicación y resiliencia de datos. Habilite la replicación entre zonas de disponibilidad y la conmutación por error si es necesario. 

   1.  Si utiliza servicios de almacenamiento gestionados de AWS, como Amazon S3, Amazon EFS y Amazon FSx, evite utilizar configuraciones Single-AZ o One Zone para datos que requieran una gran durabilidad. Utilice una configuración Multi-AZ para estos servicios. Consulte la guía del usuario del servicio correspondiente para determinar si la replicación Multi-AZ está habilitada de forma predeterminada o si debe habilitarla. 

   1.  Si ejecuta una base de datos, una cola u otro servicio de almacenamiento autogestionado, organice la replicación en zonas de disponibilidad múltiples según las instrucciones o las prácticas recomendadas de la aplicación. Familiarícese con los procedimientos de conmutación por error de su aplicación. 

1.  Configure su servicio de DNS para detectar el deterioro de la zona de disponibilidad y redirigir el tráfico a una zona de disponibilidad en buen estado. Amazon Route 53, en combinación con Elastic Load Balancers, puede hacerlo automáticamente. Route 53 también se puede configurar con registros de conmutación por error que utilizan comprobaciones de estado para responder a las consultas únicamente con direcciones IP en buen estado. En el caso de cualquier registro de DNS que se utilice para la conmutación por error, especifique un valor de tiempo de vida (TTL) corto (por ejemplo, 60 segundos o menos) para evitar que el almacenamiento en caché de los registros impida la recuperación (los registros de alias de Route 53 le proporcionan los TTL adecuados). 

 **Pasos adicionales cuando se utilizan varias Regiones de AWS** 

1.  Replique todo el código del sistema operativo (SO) y de la aplicación que utilice su carga de trabajo en las regiones seleccionadas. Replique las imágenes de máquina de Amazon (AMI) que utilizan sus instancias de EC2 si es necesario mediante soluciones como Generador de imágenes de Amazon EC2. Replique las imágenes de contenedores almacenadas en los registros mediante soluciones como la replicación entre regiones de Amazon ECR. Habilite la replicación regional para cualquier bucket de Amazon S3 que se utilice para almacenar los recursos de la aplicación. 

1.  Implemente sus recursos informáticos y metadatos de configuración (como los parámetros almacenados en el almacén de parámetros de AWS Systems Manager) en varias regiones. Utilice los mismos procedimientos descritos en los pasos anteriores, pero replique la configuración para cada región que utilice para su carga de trabajo. Utilice la infraestructura como soluciones de código, tales como AWS CloudFormation, para reproducir uniformemente las configuraciones entre las regiones. Si utiliza una región secundaria en una configuración piloto sencilla para la recuperación ante desastres, puede reducir la cantidad de recursos informáticos a un valor mínimo para ahorrar costes, con el consiguiente aumento del tiempo de recuperación. 

1.  Replique los datos de la región principal en las regiones secundarias. 

   1.  Las tablas globales de Amazon DynamoDB proporcionan réplicas globales de sus datos que se pueden escribir desde cualquier región compatible. Con otros servicios de datos gestionados por AWS, como Amazon RDS, Amazon Aurora y Amazon Elasticache, se designa una región principal (lectura/escritura) y regiones de réplica (solo lectura). Consulte las guías de usuario y del desarrollador de los servicios respectivos para obtener más información sobre la replicación regional. 

   1.  Si ejecuta una base de datos autogestionada, organice la replicación en varias regiones siguiendo las instrucciones o las prácticas recomendadas de la aplicación. Familiarícese con los procedimientos de conmutación por error de su aplicación. 

   1.  Si la carga de trabajo utiliza AWS EventBridge, tal vez tenga que reenviar los eventos seleccionados de su región principal a las regiones secundarias. Para ello, especifique los buses de eventos de sus regiones secundarias como destinos de los eventos coincidentes en su región principal. 

1.  Piense si quiere utilizar claves de cifrado idénticas en todas las regiones y en qué medida. Un enfoque típico que equilibra la seguridad y la facilidad de uso consiste en utilizar claves de ámbito regional para los datos y la autenticación regionales y locales y utilizar claves de ámbito internacional para cifrar los datos que se replican entre distintas regiones. [AWS Key Management Service (KMS)](https://aws.amazon.com/kms/) admite [claves de varias regiones](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) para distribuir y proteger de forma segura las claves compartidas entre las regiones. 

1.  Puede usar AWS Global Accelerator para mejorar la disponibilidad de la aplicación, que dirige el tráfico a regiones que contengan puntos de conexión en buen estado. 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [REL02-BP03 Garantía de que la asignación de subredes IP tenga en cuenta la expansión y la disponibilidad](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html) 
+  [REL11-BP05 Uso de la estabilidad estática para evitar el comportamiento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html) 
+  [REL13-BP01 Definición de objetivos de recuperación para el tiempo de inactividad y la pérdida de datos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html) 

 **Documentos relacionados:** 
+  [Infraestructura global de AWS](https://aws.amazon.com/about-aws/global-infrastructure) 
+  [Documento técnico: AWS Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html) 
+  [Resiliencia en Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/disaster-recovery-resiliency.html) 
+  [Amazon EC2 Auto Scaling: Ejemplo: Distribuir instancias entre zonas de disponibilidad](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ) 
+  [Cómo funciona Generador de Imágenes de EC2](https://docs.aws.amazon.com/imagebuilder/latest/userguide/how-image-builder-works.html#image-builder-distribution) 
+  [Cómo coloca Amazon ECS las tareas en las instancias de contenedor (incluido Fargate)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html) 
+  [Resiliencia en AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/security-resilience.html) 
+  [Amazon S3: Información general de la replicación de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) 
+  [Replicación de imágenes privadas en Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html) 
+  [Tablas globales: replicación en varias regiones para DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html) 
+  [Amazon Elasticache para Redis OSS: Replicación en Regiones de AWS con almacenes de datos globales](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html) 
+  [Resiliencia en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/disaster-recovery-resiliency.html) 
+  [Uso de bases de datos globales de Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html) 
+  [Guía para desarrolladores de AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  [Multi-Region keys in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) 
+  [Amazon Route 53: Configuración de la recuperación ante errores a nivel de DNS](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover-configuring.html) 
+  [Guía para desarrolladores del Controlador de recuperación de aplicaciones de Amazon (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  [Sending and receiving Amazon EventBridge events between Regiones de AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html) 
+  [Serie de blogs Creating a Multi-Region Application with AWS Services](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) 
+  [Arquitectura de recuperación de desastres (DR) en AWS, parte I: estrategias de recuperación en la nube](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) 
+  [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/) 

 **Videos relacionados:** 
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4) 
+  [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure](https://youtu.be/UObQZ3R9_4c) 

# REL10-BP02 Automatización de la recuperación de los componentes restringidos a una sola ubicación
<a name="rel_fault_isolation_single_az_system"></a>

Si los componentes de la carga de trabajo solo se pueden ejecutar en una zona de disponibilidad o en el centro de datos en las instalaciones, implemente la capacidad de volver a crear la carga de trabajo de acuerdo con los objetivos de recuperación definidos.

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Si la práctica recomendada de implementar la carga de trabajo en varias ubicaciones no es posible por limitaciones tecnológicas, debe implementar una ruta alternativa hacia la resiliencia. Debe automatizar la capacidad de recrear la infraestructura necesaria, volver a implementar las aplicaciones y volver a crear los datos necesarios para estos casos. 

 Por ejemplo, Amazon EMR lanza todos los nodos de un clúster determinado en la misma zona de disponibilidad, porque la ejecución de un clúster en la misma zona mejora el rendimiento de los flujos de trabajo, ya que ofrece una velocidad de acceso a los datos más alta. Si este componente resulta necesario para la resiliencia de la carga de trabajo, debe tener una forma de volver a implementar el clúster y sus datos. Además, para Amazon EMR, debería aprovisionar la redundancia de formas diferentes al uso de varias zonas de disponibilidad. Puede aprovisionar [varios nodos](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). Con el [sistema de archivos de EMR (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html), los datos de EMR se pueden almacenar en Amazon S3, que a su vez se puede replicar en varias zonas de disponibilidad o Regiones de AWS. 

 De modo similar, en el caso de Amazon Redshift, el clúster se aprovisiona de forma predeterminada en una zona de disponibilidad seleccionada al azar dentro de la Región de AWS que haya seleccionado. Todos los nodos del clúster se aprovisionan en la misma zona. 

 Para cargas de trabajo basadas en servidores con estado implementadas en un centro de datos en las instalaciones, puede utilizar AWS Elastic Disaster Recovery para proteger sus cargas de trabajo en AWS. Si ya se aloja en AWS, puede usar la Recuperación de desastres elástica para proteger la carga de trabajo en una región o zona de disponibilidad alternativa. La Recuperación de desastres elástica utiliza la replicación continua en el nivel de bloque en un espacio de almacenamiento ligero para proporcionar una recuperación rápida y fiable de las aplicaciones en las instalaciones y basadas en la nube. 

 **Pasos para la implementación** 

1.  Implemente la autorrecuperación. Implemente sus instancias o contenedores con escalado automático siempre que sea posible. Si no puede usar el escalado automático, utilice la recuperación automática para instancias de EC2 o implemente la automatización de autorrecuperación basada en eventos de ciclo de vida del contenedor de Amazon EC2 o ECS. 
   +  Utilice [grupos de Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) para instancias y cargas de trabajo de contenedor que no tengan requisitos de una sola dirección IP de instancia, dirección IP privada, dirección IP elástica y metadatos de instancia. 
     +  Los datos de usuario de la plantilla de lanzamiento se pueden usar para implementar una automatización que pueda solucionar la mayoría de las cargas de trabajo. 
   +  Utilice la [recuperación automática de instancias de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) para cargas de trabajo que requieran una única dirección ID de instancia, dirección IP privada, dirección IP elástica y metadatos de instancia. 
     +  La recuperación automática enviará alertas de estado de recuperación a un tema de SNS cuando se detecte un error en la instancia. 
   +  Utilice los [eventos del ciclo de vida de la instancia de Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) o los [eventos de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) para automatizar la autorrecuperación cuando no se pueda utilizar el escalado automático ni la recuperación de EC2. 
     +  Utilice los eventos para invocar la automatización que reparará su componente de acuerdo con la lógica de proceso que necesita. 
   +  Proteja las cargas de trabajo con estado que están limitadas a una única ubicación con [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Eventos de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) 
+  [Enlaces de ciclo de vida de Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) 
+  [Recuperación de instancias.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) 
+  [Escalado automático de su servicio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) 
+  [What Is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)

# REL10-BP03 Uso de arquitecturas herméticas para limitar el alcance del impacto
<a name="rel_fault_isolation_use_bulkhead"></a>

La implementación de arquitecturas herméticas (también conocidas como arquitecturas basadas en celdas) restringe el efecto del fallo dentro de una carga de trabajo a un número limitado de componentes.

 **Resultado deseado:** una arquitectura basada en celdas utiliza varias instancias aisladas de una carga de trabajo, donde cada instancia se conoce como celda. Cada celda es independiente, no comparte estado con otras celdas y gestiona un subconjunto de las solicitudes de la carga de trabajo global. Esto reduce la posible repercusión de un error, como una actualización de software incorrecta, en una celda individual y en las solicitudes que está procesando. Si una carga de trabajo utiliza 10 celdas para atender 100 solicitudes cuando se produce un error, el 90 % del total de las solicitudes no se verá afectado por el error. 

 **Patrones comunes de uso no recomendados:** 
+  Permitir que las celdas crezcan sin límites. 
+  Aplicar actualizaciones o implementaciones de código a todas las celdas al mismo tiempo. 
+  Compartir estado o componentes entre celdas (a excepción de la capa de enrutador). 
+  Agregar lógica compleja de negocio o de enrutamiento a la capa de enrutador. 
+  No minimizar las interacciones entre celdas. 

 **Beneficios de establecer esta práctica recomendada:** con las arquitecturas basadas en celdas, muchos tipos de fallos comunes se encuentran dentro de la propia celda, lo que proporciona un aislamiento adicional de los fallos. Estos límites de los errores pueden favorecer la resiliencia frente a tipos de errores que, de otro modo, serían difíciles de contener, como implementaciones de código fallidas o solicitudes dañadas o que invocan un modo de error específico (también conocidas como *solicitudes de píldora venenosa*). 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 En un barco, los mamparos garantizan que una brecha en el casco quede contenida en una sola sección del casco. En los sistemas complejos, este modelo de contención suele imitarse para permitir el aislamiento de errores. Los límites aislados de los errores restringen el efecto de un error en una carga de trabajo a un número limitado de componentes. Los componentes que se encuentran fuera del límite no se ven afectados por el error. Al usar múltiples límites aislados de errores, puede limitar el impacto en su carga de trabajo. En AWS, los clientes pueden utilizar varias zonas y regiones de disponibilidad para proporcionar aislamiento de errores, pero el concepto de aislamiento de errores también puede extenderse a la arquitectura de su carga de trabajo. 

 La carga de trabajo global se divide en celdas mediante una clave de partición. Esta clave tiene que alinearse con la *corriente* del servicio o con la forma natural en que la carga de trabajo de un servicio puede subdividirse con mínimas interacciones entre celdas. Algunos ejemplos de claves de partición son el ID de cliente, el ID de recurso o cualquier otro parámetro fácilmente accesible en la mayoría de las llamadas a la API. Una capa de enrutador de celdas distribuye las solicitudes a celdas individuales en función de la clave de partición y presenta un único punto de conexión a los clientes. 

![\[Diagrama en el que se muestra una arquitectura basada en celdas\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/cell-based-architecture.png)


 **Pasos para la implementación** 

 Al diseñar una arquitectura basada en celdas, hay que tener en cuenta varias consideraciones de diseño: 

1.  **Clave de partición**: se debe tener especial cuidado al elegir la clave de partición. 
   +  Debe alinearse con la corriente del servicio o con la forma natural en que la carga de trabajo de un servicio puede subdividirse con mínimas interacciones entre celdas. Algunos ejemplos son `customer ID` o `resource ID`. 
   +  La clave de partición debe estar disponible en todas las solicitudes, ya sea de modo directo o de una manera que se pueda inferir con facilidad de forma determinista por otros parámetros. 

1.  **Asignación persistente de celdas**: los servicios ascendentes solo deberían interactuar con una única celda durante el ciclo de vida de sus recursos. 
   +  Según la carga de trabajo, puede ser necesaria una estrategia de migración de celda para migrar datos de una celda a otra. Un posible escenario en el que puede ser precisa una migración de celda es si un usuario o recurso concreto de la carga de trabajo crece demasiado y requiere una celda dedicada. 
   +  Las celdas no deben compartir estados ni componentes entre ellas. 
   +  En consecuencia, las interacciones entre celdas deben evitarse o mantenerse al mínimo, ya que dichas interacciones crean dependencias entre las celdas y, por lo tanto, disminuyen las ventajas en el aislamiento de errores. 

1.  **Capa de enrutador**: la capa de enrutador es un componente compartido entre las celdas y, por lo tanto, no puede seguir la misma estrategia de compartimentación que las celdas. 
   +  Se recomienda que la capa de enrutador distribuya las solicitudes a las celdas individuales mediante un algoritmo de asignación de particiones de una manera eficiente a nivel computacional, como la combinación de funciones hash criptográficas y aritmética modular para asignar claves de partición a las celdas. 
   +  Para evitar impactos multicelda, la capa de enrutador debe ser lo más simple y escalable horizontalmente posible, lo que requiere evitar una lógica de negocio compleja dentro de esta capa. Esto tiene la ventaja agregada de facilitar la comprensión de su comportamiento esperado en todo momento, lo que permite una comprobabilidad exhaustiva. Como explica Colm MacCárthaigh en [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/), los diseños simples y los patrones de trabajo constantes producen sistemas fiables y reducen la antifragilidad. 

1.  **Tamaño de la celda**: las celdas deben tener un tamaño máximo y no debe permitirse que lo superen. 
   +  Para determinar el tamaño máximo, se deben llevar a cabo pruebas exhaustivas hasta que se alcancen puntos de ruptura y se establezcan márgenes de funcionamiento seguros. Para obtener más detalles sobre cómo implementar prácticas de prueba, consulte [REL07-BP04 Pruebas en su carga de trabajo](rel_adapt_to_changes_load_tested_adapt.md) 
   +  La carga de trabajo global crecerá a medida que se agreguen celdas adicionales, lo que permite escalar la carga de trabajo con los aumentos de la demanda. 

1.  **Estrategias de varias zonas de disponibilidad o de varias regiones**: se deben aprovechar las diversas capas de resiliencia para protegerse contra diferentes dominios de error. 
   +  Para obtener resiliencia, debe utilizar un enfoque que cree capas de defensa. Una capa protege de las interrupciones más pequeñas y frecuentes mediante la creación de una arquitectura de alta disponibilidad con múltiples AZ. Otra capa de defensa está pensada para proteger de eventos poco frecuentes, como las catástrofes naturales generalizadas y las interrupciones a nivel regional. Esta segunda capa implica la arquitectura de su aplicación para que abarque múltiples Regiones de AWS. Implementar una estrategia multirregión para la carga de trabajo ayuda a protegerla de catástrofes naturales generalizadas que afecten a una región geográfica amplia de un país o de errores técnicos de alcance regional. Tenga en cuenta que implementar una arquitectura multirregional puede ser significativamente complejo y no suele ser necesario para la mayoría de las cargas de trabajo. Para obtener más información, consulte [REL10-BP01 Implementación de la carga de trabajo en varias ubicaciones](rel_fault_isolation_multiaz_region_system.md). 

1.  **Implementación de código**: debería preferirse una estrategia de implementación de código escalonada en lugar de implementar cambios de código en todas las celdas al mismo tiempo. 
   +  Esto ayuda a minimizar posibles errores en numerosas celdas provocados por una implementación incorrecta o a un error humano. Para obtener más detalles, consulte [Automatización de implementaciones seguras y sin intervención](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/). 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [REL07-BP04 Pruebas en su carga de trabajo](rel_adapt_to_changes_load_tested_adapt.md) 
+  [REL10-BP01 Implementación de la carga de trabajo en varias ubicaciones](rel_fault_isolation_multiaz_region_system.md) 

 **Documentos relacionados:** 
+  [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
+ [AWS and Compartmentalization ](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [ Aislamiento de las cargas de trabajo a través de la fragmentación aleatoria ](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+  [Automatización de implementaciones seguras y sin intervención](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 

 **Videos relacionados:** 
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)
+  [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20) 
+  [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373) 
+ [AWS Summit ANZ 2021 - Everything fails, all the time: Designing for resilience ](https://www.youtube.com/watch?v=wUzSeSfu1XA)

# Diseño de la carga de trabajo para que tolere los errores de los componentes
<a name="design-your-workload-to-withstand-component-failures"></a>

 Las cargas de trabajo con un requisito de alta disponibilidad y un tiempo de recuperación (MTTR) bajo deben diseñarse para que sean resilientes. 

**Topics**
+ [REL11-BP01 Supervisión de todos los componentes de la carga de trabajo para detectar errores](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Conmutación por error a recursos en buen estado](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Automatización de la reparación en todas las capas](rel_withstand_component_failures_auto_healing_system.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)
+ [REL11-BP05 Uso de la estabilidad estática para evitar el comportamiento bimodal](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Envío de notificaciones cuando los eventos afecten a la disponibilidad](rel_withstand_component_failures_notifications_sent_system.md)
+ [REL11-BP07 Diseño de su producto para cumplir objetivos de disponibilidad y acuerdos de nivel de servicio (SLA) de tiempo de actividad](rel_withstand_component_failures_service_level_agreements.md)

# REL11-BP01 Supervisión de todos los componentes de la carga de trabajo para detectar errores
<a name="rel_withstand_component_failures_monitoring_health"></a>

 Supervise continuamente el estado de las cargas de trabajo para que usted y los sistemas automatizados sepan cuándo se produce degradaciones o errores en cuanto ocurran. Supervise los indicadores clave de rendimiento (KPI) en función del valor empresarial. 

 Todos los mecanismos de recuperación y corrección deben comenzar por la capacidad de detectar problemas rápidamente. Los fallos técnicos deberían detectarse en primer lugar para poder resolverse. Sin embargo, la disponibilidad se basa en la capacidad de su carga de trabajo para ofrecer valor empresarial, de modo que los indicadores clave de rendimiento (KPI) que midan esto tienen que formar parte de su estrategia de detección y corrección. 

 **Resultado deseado:** los componentes esenciales de una carga de trabajo se supervisan de forma independiente para detectar los errores en el momento y el lugar en que se producen y alertar sobre ellos. 

 **Patrones comunes de uso no recomendados:** 
+  No se han configurado alarmas, por lo que las interrupciones se producen sin notificación. 
+  Existen alarmas, pero en umbrales que no proporcionan el tiempo necesario para reaccionar. 
+  No se recopilan métricas con la suficiente regularidad para satisfacer el objetivo de tiempo de recuperación (RTO). 
+  Solo se supervisan activamente las interfaces de la carga de trabajo orientadas a los clientes. 
+  Solo se recopilan métricas técnicas, no métricas de funciones empresariales. 
+  No hay métricas que midan la experiencia del usuario con la carga de trabajo. 
+  Se crean demasiadas supervisiones. 

 **Beneficios de establecer esta práctica recomendada:** una supervisión adecuada de todas las capas le permite reducir el tiempo de recuperación al reducirse el tiempo de detección. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Identifique todas las cargas de trabajo que se revisarán para su supervisión. Una vez que haya identificado todos los componentes de la carga de trabajo que deberán supervisarse, tendrá que determinar el intervalo de supervisión. El intervalo de supervisión tendrá un impacto directo en la rapidez con la que se puede iniciar la recuperación en función del tiempo que se tarde en detectar un error. El tiempo medio de detección (MTTD) es el tiempo transcurrido entre la aparición de un error y el inicio de las operaciones de reparación. La lista de servicios debe ser amplia y completa. 

 La supervisión debe cubrir todas las capas de la pila de aplicaciones, incluidas la aplicación, la plataforma, la infraestructura y la red. 

 Su estrategia de supervisión debe considerar el impacto de los *errores grises*. Para obtener más información sobre los errores grises, consulte [Gray failures](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) en el documento técnico Advanced Multi-AZ Resilience Patterns. 

### Pasos para la implementación
<a name="implementation-steps"></a>
+  El intervalo de supervisión depende de la rapidez con la que deba recuperarse. El tiempo de recuperación depende del tiempo que tarde la recuperación, por lo que debe determinar la frecuencia de recopilación teniendo en cuenta este tiempo y el objetivo de tiempo de recuperación (RTO). 
+  Configure la supervisión detallada de los componentes y los servicios administrados. 
  +  Determine si son necesarios la [supervisión detallada de las instancias de EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) y el [escalado automático](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html). La supervisión detallada proporciona métricas en intervalos de un minuto y la supervisión predeterminada proporciona métricas en intervalos de cinco minutos. 
  +  Determine si se necesita la [supervisión mejorada](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) de RDS. La supervisión mejorada usa un agente en las instancias de RDS para obtener información útil sobre los diferentes procesos o subprocesos. 
  +  Determine los requisitos de supervisión de los componentes sin servidor cruciales para [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html), [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html), [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html), [Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs) y todos los tipos de [equilibradores de carga](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html). 
  +  Determine los requisitos de supervisión de los componentes de almacenamiento para [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html), [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html), [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html) y [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html). 
+  Cree [métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) para medir los indicadores clave de rendimiento (KPI) del negocio. Las cargas de trabajo implementan funciones empresariales clave, que deben usarse como KPI para ayudar a identificar cuándo se produce un problema indirecto. 
+  Supervise la experiencia del usuario para detectar errores mediante canarios del usuario. Las [pruebas de transacciones sintéticas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (también denominadas “pruebas canario”, que no deben confundirse con las implementaciones canario) que puedan ejecutar y simular el comportamiento de los clientes son uno de los procesos de prueba más importantes. Ejecute estas pruebas constantemente en los puntos de conexión de las cargas de trabajo desde distintas ubicaciones remotas. 
+  Cree [métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) que controlen la experiencia del usuario. Si puede instrumentar la experiencia del cliente, puede determinar cuándo se degrada la experiencia del cliente. 
+  [Defina alarmas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) para detectar cuándo alguna parte de la carga de trabajo no funciona correctamente y para indicar cuándo escalar automáticamente los recursos. Las alarmas pueden mostrarse visualmente en paneles, enviar alertas a través de Amazon SNS o por correo electrónico y trabajar con escalado automático para escalar o reducir verticalmente los recursos de la carga de trabajo. 
+  Cree [paneles](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) para visualizar las métricas. Se pueden usar paneles para visualizar las tendencias, los valores atípicos y otros indicadores de problemas potenciales, o para proporcionar una indicación de problemas que tal vez le convenga investigar. 
+  Cree una [supervisión de rastreo distribuida](https://aws.amazon.com/xray/faqs/) para sus servicios. Con la supervisión distribuida, podrá saber cómo se comporta su aplicación y sus servicios subyacentes para identificar y resolver la causa raíz de los problemas y errores de rendimiento. 
+  Cree paneles de sistemas de supervisión (mediante [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) o [X-Ray](https://aws.amazon.com/xray/faqs/)) y recopilaciones de datos en una región y una cuenta independientes. 
+  Manténgase informado sobre las degradaciones del servicio con [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/). [Cree notificaciones de eventos de AWS Health adecuados para su propósito](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html) para los canales de correo electrónico y chat a través de [AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) e intégrelas mediante programación con [las herramientas de supervisión y alertas a través de Amazon EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html). 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [Availability Definition](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP06 Envío de notificaciones cuando los eventos afecten a la disponibilidad](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 

 **Documentos relacionados:** 
+  [Amazon CloudWatch Synthetics le permite crear canarios de usuario](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [Activar o desactivar el monitoreo detallado para las instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) 
+  [Supervisión mejorada](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) 
+  [Monitoring Your Auto Scaling Groups and Instances Using Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) 
+  [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Uso de las alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Uso de paneles de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [Uso de paneles de CloudWatch entre regiones y entre cuentas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) 
+  [Uso del rastreo de X-Ray entre regiones y entre cuentas](https://aws.amazon.com/xray/faqs/) 
+  [Understanding availability](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html) 

 **Videos relacionados:** 
+  [Mitigating gray failures](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) 

 **Ejemplos relacionados:** 
+  [One Observability Workshop: Explore X-Ray](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray) 

 **Herramientas relacionadas:** 
+  [CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) 

# REL11-BP02 Conmutación por error a recursos en buen estado
<a name="rel_withstand_component_failures_failover2good"></a>

 Si un recurso fallara, los recursos en buen estado deberían seguir atendiendo las solicitudes. Para problemas de ubicación (como zonas de disponibilidad o Región de AWS), asegúrese de que disponga de sistemas para conmutar por error a recursos en buen estado en ubicaciones sin problemas. 

 Al diseñar un servicio, distribuya la carga entre los recursos, las zonas de disponibilidad o las regiones. De esta manera, el error de un recurso individual o el deterioro puede mitigarse al desplazar el tráfico a los recursos restantes en buen estado. Tenga en cuenta cómo se descubren los servicios y cómo se enruta a ellos en caso de que se produzca un error. 

 Tenga en cuenta la recuperación de errores al diseñar sus servicios. En AWS, diseñamos servicios para minimizar el tiempo de recuperación de los errores y el impacto en los datos. Nuestros servicios utilizan principalmente almacenes de datos que confirman las solicitudes solo después de que se almacenen de forma duradera en varias réplicas en una región. Se han diseñado para utilizar el aislamiento basado en celdas y el aislamiento de errores que proporcionan las zonas de disponibilidad. Utilizamos ampliamente la automatización en nuestros procedimientos operativos. También optimizamos nuestra funcionalidad de reemplazo y reinicio para recuperarnos rápidamente de las interrupciones. 

 Los patrones y diseños que permiten la conmutación por error varían para cada servicio de plataforma de AWS. Muchos servicios administrados nativos de AWS son zonas de disponibilidad múltiples de forma nativa (como Lambda o API Gateway). Otros servicios de AWS (como EC2 y EKS) requieren diseños específicos de las prácticas recomendadas para admitir la conmutación por error de los recursos o el almacenamiento de datos en las AZ. 

 La supervisión debe configurarse para que compruebe que el recurso de conmutación por error esté en buen estado, hacer un seguimiento del progreso de los recursos de conmutación por error y supervisar la recuperación de los procesos empresariales. 

 **Resultado deseado:** los sistemas son capaces de utilizar nuevos recursos de forma automática o manual para recuperarse de la degradación. 

 **Patrones comunes de uso no recomendados:** 
+  La planificación de errores no forma parte de la fase de planificación y diseño. 
+  No se establecen el RTO ni el RPO. 
+  Supervisión insuficiente para detectar recursos defectuosos. 
+  Aislamiento adecuado de los dominios de error. 
+  No se considera la conmutación por error multirregional. 
+  La detección de errores es demasiado sensible o agresiva a la hora de decidir efectuar una conmutación por error. 
+  No probar ni validar el diseño de la conmutación por error. 
+  Llevar a cabo la automatización de la recuperación automática, pero no notificar que se necesitaba una reparación. 
+  Ausencia de un periodo de amortiguación para evitar que la conmutación por error se lleve a cabo demasiado pronto. 

 **Beneficios de establecer esta práctica recomendada:** con una degradación uniforme y una recuperación rápida, puede crear sistemas más resilientes que mantengan la fiabilidad cuando se producen errores. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Los servicios de AWS, como [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) y [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html), ayudan a distribuir la carga entre los recursos y las zonas de disponibilidad. Por lo tanto, el error de un recurso individual (como una instancia de EC2) o el deterioro de una zona de disponibilidad puede mitigarse si se desplaza el tráfico a los recursos restantes en buen estado. 

 Para las cargas de trabajo multirregionales, los diseños son más complicados. Por ejemplo, las réplicas de lectura entre regiones le permiten implementar sus datos en varias Regiones de AWS. Sin embargo, la conmutación por error sigue siendo necesaria para convertir la réplica de lectura en principal y, a continuación, dirigir el tráfico al nuevo punto de conexión. Amazon Route 53, el [Controlador de recuperación de aplicaciones de (ARC)](https://aws.amazon.com/application-recovery-controller/), Amazon CloudFront y AWS Global Accelerator pueden ayudar a enrutar el tráfico en las Regiones de AWS. 

 Los servicios de AWS, como Amazon S3, Lambda, API Gateway, Amazon SQS, Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon ECR, AWS Certificate Manager, EventBridge o Amazon DynamoDB, se implementan automáticamente en varias zonas de disponibilidad mediante AWS. En caso de error, estos servicios de AWS dirigen automáticamente el tráfico a ubicaciones en buen estado. Los datos se almacenan de forma redundante en varias zonas de disponibilidad y siguen estando disponibles. 

 Para Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon EKS o Amazon ECS, Multi-AZ es una opción de configuración. AWS puede dirigir el tráfico a la instancia en buen estado si se inicia la conmutación por error. Esta acción de conmutación por error puede llevarla a cabo AWS o según lo requiera el cliente 

 Para las instancias de Amazon EC2, Amazon Redshift, las tareas de Amazon ECS o los pods de Amazon EKS, elige en qué zonas de disponibilidad deben implementarse. En algunos diseños, Elastic Load Balancing proporciona la solución para detectar instancias en zonas que no están en buen estado y dirigir el tráfico a las que sí están en buen estado. Elastic Load Balancing también puede dirigir el tráfico a componentes de su centro de datos en las instalaciones. 

 En cuanto a la conmutación por error del tráfico multirregional, el reenrutamiento puede utilizar Amazon Route 53, el Controlador de recuperación de aplicaciones de Amazon, AWS Global Accelerator, DNS privado de Route 53 para VPC o CloudFront para proporcionar una forma de definir dominios de Internet y asignar políticas de enrutamiento, incluidas comprobaciones de estado, para enrutar el tráfico a regiones en buen estado. AWS Global Accelerator proporciona direcciones IP estáticas que actúan como punto de entrada fijo a su aplicación; a continuación, se enrutan a los puntos de conexión de las Regiones de AWS que elija, mediante la red global de AWS en lugar de Internet para mejorar el rendimiento y la fiabilidad. 

### Pasos para la implementación
<a name="implementation-steps"></a>
+  Cree diseños de conmutación por error para todas las aplicaciones y servicios pertinentes. Aísle cada componente de la arquitectura y cree diseños de conmutación por error que satisfagan el RTO y el RPO de cada componente. 
+  Configure entornos inferiores (como los de desarrollo o prueba) con todos los servicios que sean necesarios para tener un plan de conmutación por error. Implemente las soluciones mediante la infraestructura como código (IaC) para garantizar la repetibilidad. 
+  Configure un sitio de recuperación, como una segunda región, para implementar y probar los diseños de conmutación por error. Si fuera necesario, los recursos para las pruebas se pueden configurar temporalmente para limitar los costos adicionales. 
+  Determine qué planes de conmutación por error se automatizan mediante AWS, cuáles pueden automatizarse mediante un proceso de DevOps y cuáles pueden ser manuales. Documente y mida el RTO y el RPO de cada servicio. 
+  Cree un manual de estrategias de conmutación por error e incluya todos los pasos de la conmutación por error de cada recurso, aplicación y servicio. 
+  Cree un manual de estrategias de conmutación por recuperación e incluya todos los pasos de la conmutación por recuperación (con plazos) de cada recurso, aplicación y servicio. 
+  Cree un plan para iniciar y ensayar el manual de estrategias. Utilice simulaciones y pruebas de caos para poner a prueba los pasos del manual de estrategias y la automatización. 
+  Para problemas de ubicación (como zonas de disponibilidad o Región de AWS), asegúrese de que disponga de sistemas para conmutar por error a recursos en buen estado en ubicaciones sin problemas. Compruebe la cuota, los niveles de escalado automático y los recursos en ejecución antes de llevar a cabo la prueba de conmutación por error. 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas de Well-Architected relacionadas:** 
+  [REL13: Plan para DR](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) 
+  [REL10: Uso del aislamiento de errores para proteger la carga de trabajo](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) 

 **Documentos relacionados:** 
+  [Setting RTO and RPO Targets](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/) 
+  [Failover using Route 53 Weighted routing](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack) 
+  [Disaster Recovery with Amazon Application Recovery Controller](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/) 
+  [EC2 with autoscaling](https://github.com/adriaanbd/aws-asg-ecs-starter) 
+  [EC2 Deployments - Multi-AZ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
+  [ECS Deployments - Multi-AZ](https://github.com/aws-samples/ecs-refarch-cloudformation) 
+  [Switch traffic using Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html) 
+  [Lambda con un equilibrador de carga de aplicación y conmutación por error](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html) 
+  [ACM Replication and Failover](https://github.com/aws-samples/amazon-ecr-cross-region-replication) 
+  [Parameter Store Replication and Failover](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d) 
+  [ECR cross region replication and Failover](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html) 
+  [Secrets manager cross region replication configuration](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html) 
+  [Enable cross region replication for EFS and Failover](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/) 
+  [EFS Cross Region Replication and Failover](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/) 
+  [Conmutación por error de red](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html) 
+  [S3 Endpoint failover using MRAP](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap) 
+  [Creación de replicación entre regiones para S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) 
+  [Guidance for Cross Region Failover and Graceful Failback on AWS](https://d1.awsstatic.com/solutions/guidance/architecture-diagrams/cross-region-failover-and-graceful-failback-on-aws.pdf) 
+  [Failover using multi-region global accelerator](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/) 
+  [Failover with DRS](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html) 

 **Ejemplos relacionados:** 
+  [Disaster Recovery on AWS](https://disaster-recovery.workshop.aws/en/) 
+  [Elastic Disaster Recovery on AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US) 

# REL11-BP03 Automatización de la reparación en todas las capas
<a name="rel_withstand_component_failures_auto_healing_system"></a>

 Cuando se detecte un error, utilice las funciones automatizadas para tomar medidas correctivas. Las degradaciones pueden repararse automáticamente a través de mecanismos de servicio interno o requerir que los recursos se reinicien o eliminen a través de medidas de corrección. 

 Para las aplicaciones autoadministradas y la reparación entre regiones, los diseños de recuperación y los procesos de reparación automatizados se pueden extraer de las [prácticas recomendadas existentes](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/). 

 La capacidad de reiniciar o eliminar un recurso es una herramienta importante para corregir los errores. Una práctica recomendada es convertir los servicios en servicios sin estado siempre que sea posible. Esto evita la pérdida de datos o disponibilidad tras el reinicio del recurso. En la nube, puede (y generalmente debería) sustituir todo el recurso (por ejemplo, la instancia de computación o la función sin servidor) como parte del reinicio. El reinicio en sí es una forma sencilla y fiable de recuperarse de un error. En las cargas de trabajo ocurren muchos tipos de errores diferentes. Los errores pueden ocurrir en el hardware, el software, las comunicaciones y el funcionamiento. 

 El reinicio o el reintento también se aplican a las solicitudes de red. Se aplica el mismo enfoque de recuperación tanto a un tiempo de espera de la red como a un error en la dependencia, en el que la dependencia devuelve un error. Ambos eventos tienen un efecto similar en el sistema, por lo que, en lugar de intentar convertir cada uno en un caso especial, se aplicaría una estrategia similar de reintento con retroceso exponencial y fluctuación. La capacidad de reiniciar es un mecanismo de recuperación que aparece en la computación orientada a la recuperación y en las arquitecturas de clústeres de alta disponibilidad. 

 **Resultado deseado:** se llevan a cabo medidas automatizadas para corregir la detección de un error. 

 **Patrones comunes de uso no recomendados:** 
+  Aprovisionar recursos sin escalado automático. 
+  Implementar las aplicaciones en instancias o contenedores individualmente. 
+  Implementar aplicaciones que no se pueden implementar en varias ubicaciones sin usar la recuperación automática. 
+  Reparar manualmente las aplicaciones que el escalado automático y la recuperación automática no pueden reparar. 
+  No hay automatización de las bases de datos de conmutación por error. 
+  Carencia de métodos automatizados para redirigir el tráfico a nuevos puntos de conexión. 
+  No hay replicación del almacenamiento. 

 **Beneficios de establecer esta práctica recomendada:** la reparación automática puede reducir el tiempo medio de recuperación y mejorar la disponibilidad. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Los diseños de Amazon EKS u otros servicios de Kubernetes deben incluir conjuntos de réplicas o con estado mínimo y máximo y el tamaño mínimo del clúster y los grupos de nodos. Estos mecanismos proporcionan una cantidad mínima de recursos de procesamiento disponibles de forma continua y, al mismo tiempo, corrigen automáticamente cualquier error mediante el plano de control de Kubernetes. 

 Los patrones de diseño a los que se accede a través de un equilibrador de carga mediante clústeres de computación deben utilizar los grupos de escalado automático. Elastic Load Balancing (ELB) distribuye automáticamente el tráfico de aplicaciones entrante entre varios destinos y dispositivos virtuales en una o más zonas de disponibilidad (AZ). 

 Los diseños basados en computación en clúster que no utilizan el equilibrio de carga deben tener un diseño de tamaño que dé cabida a la pérdida de al menos un nodo. Esto permitirá que el servicio siga funcionando con una capacidad potencialmente reducida mientras recupera un nuevo nodo. Algunos servicios son Mongo, el Acelerador de DynamoDB, Amazon Redshift, Amazon EMR, Cassandra, Kafka, MSK-EC2, Couchbase, ELK y Amazon OpenSearch Service. Muchos de estos servicios se pueden diseñar con características adicionales de autorreparación. Algunas tecnologías de clústeres deben generar una alerta tras la pérdida de un nodo, lo que desencadena un flujo de trabajo automático o manual para recrear un nuevo nodo. Este flujo de trabajo se puede automatizar con AWS Systems Manager para corregir los problemas rápidamente. 

 Se puede usar Amazon EventBridge para supervisar y filtrar los eventos, como las alarmas de CloudWatch o cambios en el estado en otros servicios de AWS. En función de la información del evento, se puede invocar a AWS Lambda, Automatización de Systems Manager u otros destinos para ejecutar una lógica de corrección personalizada en la carga de trabajo. Amazon EC2 Auto Scaling se puede configurar para comprobar el estado de la instancia de EC2. Si el estado de la instancia es cualquier otro estado distinto de En ejecución o si el estado del sistema es Dañado, Amazon EC2 Auto Scaling considera que la instancia tiene un estado incorrecto y lanza una instancia de reemplazo. Para sustituciones a gran escala (como la pérdida de toda una zona de disponibilidad), se prefiere la estabilidad estática para la alta disponibilidad. 

### Pasos para la implementación
<a name="implementation-steps"></a>
+  Use grupos de escalado automático para implementar niveles en una carga de trabajo. El [escalado automático](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) puede llevar a cabo una reparación automática de aplicaciones sin estado y agregar o eliminar capacidad. 
+  En el caso de las instancias de computación indicadas anteriormente, utilice el [equilibrio de carga](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) y elija el tipo de equilibrador de carga adecuado. 
+  Considere la reparación para Amazon RDS. Con las instancias en espera, defina la configuración de la [conmutación por error automática](https://repost.aws/questions/QU4DYhqh2yQGGmjE_x0ylBYg/what-happens-after-failover-in-rds) en la instancia en espera. Para la réplica de lectura de Amazon RDS, se requiere un flujo de trabajo automatizado para convertir una réplica de lectura en principal. 
+  Implemente la [recuperación automática en instancias de EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) que tengan aplicaciones implementadas que no se puedan implementar en varias ubicaciones y puedan tolerar el reinicio tras un error. La recuperación automática se puede usar para reemplazar hardware defectuoso y reiniciar la instancia cuando la aplicación no se puede implementar en varias ubicaciones. Los metadatos de la instancia y las direcciones IP asociadas se conservan, así como los [volúmenes de EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) y los puntos de montaje en [Amazon Elastic File System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) o [File Systems para Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) y [Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html). Con [AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html), puede configurar la reparación automática de las instancias de EC2 en el nivel de capa. 
+  Implemente la recuperación automática mediante [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) y [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) cuando no pueda usar el escalado automático ni la recuperación automática o cuando la recuperación automática produzca un error. Cuando no pueda usar el escalado automático ni la recuperación automática, o esta produzca un error, puede automatizar la reparación con AWS Step Functions y AWS Lambda. 
+  Se puede usar [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) para supervisar y filtrar los eventos, como las [alarmas de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) o cambios en el estado en otros servicios de AWS. En función de la información del evento, se puede invocar AWS Lambda (u otros destinos) para ejecutar una lógica de corrección personalizada en su carga de trabajo. 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [Availability Definition](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP01 Supervisión de todos los componentes de la carga de trabajo para detectar errores](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 

 **Documentos relacionados:** 
+  [Funcionamiento de AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [Recuperación automática de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) 
+  [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) 
+  [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) 
+  [What is Amazon FSx for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) 
+  [What is Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) 
+  [AWS OpsWorks: Using Auto Healing to Replace Failed Instances](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) 
+  [Qué es AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) 
+  [Qué es AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 
+  [Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [Using Amazon CloudWatch Alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Amazon RDS Failover](https://d1.awsstatic.com/rdsImages/IG1_RDS1_AvailabilityDurability_Final.pdf) 
+  [SSM - Systems Manager Automation](https://docs.aws.amazon.com/resilience-hub/latest/userguide/integrate-ssm.html) 
+  [Resilient Architecture Best Practices](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/) 

 **Videos relacionados:** 
+  [Automatically Provision and Scale OpenSearch Service](https://www.youtube.com/watch?v=GPQKetORzmE) 
+  [Amazon RDS Failover Automatically](https://www.youtube.com/watch?v=Mu7fgHOzOn0) 

 **Ejemplos relacionados:** 
+  [Amazon RDS Failover Workshop](https://catalog.workshops.aws/resilient-apps/en-US/rds-multi-availability-zone/failover-db-instance) 

 **Herramientas relacionadas:** 
+  [CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) 

# REL11-BP04 Confianza en el plano de datos y no en el plano de control durante la recuperación
<a name="rel_withstand_component_failures_avoid_control_plane"></a>

 Los planos de control proporcionan las API administrativas que se utilizan para crear, leer y describir, actualizar, eliminar y enumerar los recursos (CRUDL), mientras que los planos de datos gestionan el tráfico de servicio diario. Al implementar respuestas de recuperación o mitigación a eventos que puedan afectar a la resiliencia, céntrese en utilizar un número mínimo de operaciones del plano de control para recuperar, reescalar, restaurar, reparar o conmutar por error el servicio. La acción del plano de datos debe reemplazar cualquier actividad durante estos eventos de degradación. 

 Por ejemplo, las siguientes son todas las acciones del plano de control: lanzar una nueva instancia de computación, crear almacenamiento en bloques y describir los servicios de colas. Al lanzar instancias de computación, el plano de control debe hacer varias tareas, como encontrar un host físico con capacidad, asignar interfaces de red, preparar los volúmenes de almacenamiento en bloques locales, generar credenciales y agregar reglas de seguridad. Los planos de control suelen tener una orquestación complicada. 

 **Resultado deseado:** cuando un recurso entra en un estado deteriorado, el sistema es capaz de recuperarse automática o manualmente al cambiar el tráfico de recursos deteriorados a recursos en buen estado. 

 **Patrones comunes de uso no recomendados:** 
+  Depender de cambiar los registros de DNS para redirigir el tráfico. 
+  Depender de las operaciones de escalado del plano de control para reemplazar los componentes dañados debido a que no se han aprovisionado suficientes recursos. 
+  Confiar en amplias acciones del plano de control de varios servicios y varias API para corregir cualquier categoría de deterioro. 

 **Beneficios de establecer esta práctica recomendada:** el aumento de la tasa de éxito de la corrección automatizada puede reducir el tiempo medio de recuperación y mejorar la disponibilidad de la carga de trabajo. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio (para determinados tipos de degradaciones del servicio, los planos de control se ven afectados). Si se depende del uso extensivo del plano de control para la corrección, se puede aumentar el tiempo de recuperación (RTO) y el tiempo medio de recuperación (MTTR). 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Para limitar las acciones del plano de datos, evalúe cada servicio para determinar qué acciones son necesarias para restablecer el servicio. 

 Use el Controlador de recuperación de aplicaciones de Amazon para cambiar el tráfico de DNS. Estas características supervisan continuamente la capacidad de la aplicación de recuperarse de los errores y le permiten controlar la recuperación de la aplicación en las distintas Regiones de AWS, zonas de disponibilidad y en las instalaciones. 

 Las políticas de enrutamiento de Route 53 utilizan el plano de control, por lo que no debe confiar en él para la recuperación. Los planos de datos de Route 53 responden a consultas de DNS y llevan a cabo y evalúan comprobaciones de estado. Están distribuidos por todo el mundo y están diseñados para cumplir con un [acuerdo de nivel de servicio (SLA) con una disponibilidad del 100 %](https://aws.amazon.com/route53/sla/). 

 Las API de administración de Route 53 y las consolas en las que se crean, actualizan y eliminan recursos de Route 53 se ejecutan en planos de control diseñados para dar prioridad a la sólida coherencia y durabilidad que necesita al administrar DNS. Para conseguirlo, los planos de control se encuentran en una única región: Este de EE. UU. (Norte de Virginia). Aunque ambos sistemas se han diseñado para ser muy fiables, los planos de control no están incluidos en el SLA. Podría haber eventos poco frecuentes en los que el diseño resiliente del plano de datos permita mantener la disponibilidad mientras que los planos de control no lo permitan. Con los mecanismos de recuperación de desastres y conmutación por error, utilice las funciones del plano de datos para proporcionar la mejor fiabilidad posible. 

 Diseñe su infraestructura informática para que sea estable desde el punto de vista estático a fin de evitar el uso del plano de control durante un incidente. Por ejemplo, si utiliza instancias de Amazon EC2, evite aprovisionar nuevas instancias manualmente o dar instrucciones a los grupos de escalado automático para que agreguen instancias en respuesta. Para obtener los niveles más altos de resiliencia, aprovisione suficiente capacidad en el clúster utilizado para la conmutación por error. Si este umbral de capacidad debe limitarse, establezca limitaciones en todo el sistema de principio a fin para limitar de forma segura el tráfico total que llega al conjunto limitado de recursos. 

 En el caso de los servicios como Amazon DynamoDB, Amazon API Gateway, los equilibradores de carga y sin servidor de AWS Lambda, el uso de esos servicios utiliza el plano de datos. Sin embargo, la creación de nuevas funciones, equilibradores de carga, puertas de enlace de API o tablas de DynamoDB es una acción del plano de control y debe completarse antes de la degradación como preparación para un evento y ensayo de las acciones de conmutación por error. En el caso de Amazon RDS, las acciones del plano de datos permiten el acceso a los datos. 

 Para obtener más información sobre planos de datos, planos de control y cómo AWS crea servicios para cumplir los objetivos de alta disponibilidad, consulte [Estabilidad estática con zonas de disponibilidad](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/). 

 Comprenda qué operaciones están en el plano de datos y cuáles están en el plano de control. 

### Pasos para la implementación
<a name="implementation-steps"></a>

 Para cada carga de trabajo que deba restaurarse después de un evento de degradación, evalúe el manual de procedimientos de conmutación por error, el diseño de alta disponibilidad, el diseño de reparación automática o el plan de restauración de recursos de alta disponibilidad. Identifique cada acción que pueda considerarse una acción del plano de control. 

 Considere cambiar la acción de control por una acción del plano de datos: 
+ Escalado automático (plano de control) a los recursos de Amazon EC2 preescalados (plano de datos)
+ Escalado de instancias de Amazon EC2 (plano de control) a escalado de AWS Lambda (plano de datos)
+  Evalúe cualquier diseño con Kubernetes y la índole de las acciones del plano de control. Agregar pods es una acción del plano de datos en Kubernetes. Las acciones deben limitarse a agregar pods y no a agregar nodos. Usar [nodos sobreaprovisionados](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/) es el método preferido para limitar las acciones del plano de control 

 Tenga en cuenta los enfoques alternativos que permiten que las acciones del plano de datos afecten a la misma corrección. 
+  Cambio de registro de Route 53 (plano de control) o Controlador de recuperación de aplicaciones de Amazon (plano de datos) 
+ [ Comprobaciones de estado de Route 53 para obtener actualizaciones más automatizadas ](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)

 Considere algunos servicios en una región secundaria, en caso de que el servicio sea crítico, para permitir más acciones del plano de control y el plano de datos en una región no afectada. 
+  Amazon EC2 Auto Scaling o Amazon EKS en una región principal en comparación con Amazon EC2 Auto Scaling o Amazon EKS en una región secundaria y enrutamiento del tráfico a una región secundaria (acción del plano de control) 
+  Hacer réplicas de lectura en la región principal secundaria o intentar la misma acción en la región principal (acción del plano de control) 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [Availability Definition](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP01 Supervisión de todos los componentes de la carga de trabajo para detectar errores](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 

 **Documentos relacionados:** 
+  [Socio de APN: socios que pueden ayudar con la automatización de su tolerancia a errores](https://aws.amazon.com/partners/find/results/?keyword=automation) 
+  [AWS Marketplace: productos que pueden usarse para tolerancia a errores](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) 
+  [Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/) 
+  [API de Amazon DynamoDB (plano de control y plano de datos)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html) 
+  [Ejecuciones de AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (divididas entre el plano de control y el plano de datos) 
+  [Plano de datos de AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html) 
+  [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/) 
+  [Building highly resilient applications using Amazon Application Recovery Controller, Part 2: Multi-Region stack](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/) 
+  [Creating Disaster Recovery Mechanisms Using Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) 
+  [What is Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+ [ Kubernetes Control Plane and data plane ](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)

 **Videos relacionados:** 
+ [ Back to Basics - Using Static Stability ](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [ Building resilient multi-site workloads using AWS global services ](https://www.youtube.com/watch?v=62ZQHTruBnk)

 **Ejemplos relacionados:** 
+  [Introducing Amazon Application Recovery Controller](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/) 
+ [ Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control ](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [ 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/)
+ [ Building highly resilient applications using Amazon Application Recovery Controller, Part 2: Multi-Region stack ](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [ Estabilidad estática con zonas de disponibilidad ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)

 **Herramientas relacionadas:** 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)

# REL11-BP05 Uso de la estabilidad estática para evitar el comportamiento bimodal
<a name="rel_withstand_component_failures_static_stability"></a>

 Las cargas de trabajo deben ser estáticamente estables y funcionar solo en un único modo normal. El comportamiento bimodal se produce cuando la carga de trabajo presenta un comportamiento diferente en los modos normal y de error. 

 Por ejemplo, puede intentar recuperarse de un error en una zona de disponibilidad mediante el lanzamiento de nuevas instancias en una zona de disponibilidad distinta. Esto puede dar como resultado una respuesta bimodal durante un modo de error. En lugar de ello, debe crear cargas de trabajo que sean estables estáticamente y funcionen en un solo modo. En este ejemplo, esas instancias deben haberse aprovisionado en la segunda zona de disponibilidad antes del error. Este diseño de estabilidad estática verifica que la carga de trabajo solo funcione en un único modo. 

 **Resultado deseado:** las cargas de trabajo no muestran un comportamiento bimodal durante los modos normal y de error. 

 **Patrones comunes de uso no recomendados:** 
+  Suponer que los recursos siempre se pueden aprovisionar independientemente del alcance del error. 
+  Intentar adquirir recursos de forma dinámica durante un error. 
+  No aprovisionar los recursos adecuados en todas las zonas o regiones hasta que se produzca un error. 
+  Considerar diseños estáticos estables solo para recursos de computación. 

 **Beneficios de establecer esta práctica recomendada:** las cargas de trabajo que se ejecutan con diseños estáticamente estables pueden tener resultados predecibles durante eventos normales y de error. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio 

## Guía para la implementación
<a name="implementation-guidance"></a>

 El comportamiento bimodal ocurre cuando la carga de trabajo exhibe diferentes comportamientos en los modos normal y de error (como confiar en el lanzamiento de nuevas instancias si se produce un error en una zona de disponibilidad). Un ejemplo de comportamiento bimodal ocurre cuando los diseños de Amazon EC2 estables aprovisionan suficientes instancias en cada zona de disponibilidad para gestionar la carga de trabajo si se eliminara una zona de disponibilidad. Se comprobaría el estado de Elastic Load Balancing o Amazon Route 53 para desviar una carga de las instancias dañadas. Una vez desviado el tráfico, use AWS Auto Scaling para sustituir de manera asíncrona las instancias de la zona con errores y lanzarlas en las zonas en buen estado. La estabilidad estática para implementaciones de computación (como instancias de EC2 o contenedores) da como resultado la máxima fiabilidad. 

![\[Diagrama en el que se muestra la estabilidad estática de las instancias de EC2 entre zonas de disponibilidad\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/static-stability.png)


 Esto debe ponderarse en comparación con el costo de este modelo y el valor empresarial de mantener la carga de trabajo en todos los casos de resiliencia. Es menos costoso aprovisionar menos capacidad de computación y confiar en el lanzamiento de nuevas instancias en caso de error, pero en el caso de errores a gran escala (como un deterioro regional o de zona de disponibilidad), este enfoque es menos eficaz porque se basa tanto en un plano operativo como en la disponibilidad de recursos suficientes en las zonas o regiones no afectadas. 

 Su solución también debe ponderar la fiabilidad en comparación con los costos necesarios para la carga de trabajo. Las arquitecturas de estabilidad estática se aplican a una variedad de arquitecturas, incluidas las instancias de computación distribuidas en las zonas de disponibilidad, los diseños de réplicas de lectura de bases de datos, los diseños de clústeres de Kubernetes (Amazon EKS) y las arquitecturas de conmutación por error multirregional. 

 También es posible implementar un diseño más estable desde el punto de vista estático mediante el uso de más recursos en cada zona. Al agregar más zonas, reduce la cantidad de procesamiento adicional que necesita para la estabilidad estática. 

 Un ejemplo de comportamiento bimodal sería un tiempo de espera de la red que podría provocar que un sistema intente actualizar el estado de configuración de todo el sistema. Se agregaría una carga inesperada a otro componente, lo que podría hacer que se produzca un error y desencadene otras consecuencias inesperadas. Este bucle de retroalimentación negativa afecta a la disponibilidad de su carga de trabajo. En lugar de ello, puede crear cargas de trabajo que sean estables estáticamente y funcionen en un solo modo. Un diseño estáticamente estable haría un trabajo constante y actualizaría continuamente el estado de configuración a una cadencia establecida. Cuando una llamada genera un error, la carga de trabajo utiliza el valor previamente almacenado en caché e inicia una alarma. 

 Otro ejemplo de comportamiento bimodal es permitir que los clientes omitan la caché de la carga de trabajo si se produce un error. Esto podría parecer una solución para satisfacer las necesidades del cliente, pero puede cambiar notablemente la demanda de la carga de trabajo y es probable que produzca errores. 

 Evalúe las cargas de trabajo críticas para determinar cuáles requieren este tipo de diseño de resiliencia. Se debe revisar cada componente de la aplicación en las cargas que se consideren cruciales. Algunos tipos de servicios que requieren evaluaciones de estabilidad estática son: 
+  **Computación**: Amazon EC2, EKS-EC2, ECS-EC2, EMR-EC2 
+  **Bases de datos**: Amazon Redshift, Amazon RDS, Amazon Aurora 
+  **Almacenamiento**: Amazon S3 (zona única), Amazon EFS (montajes), Amazon FSx (montajes) 
+  **Equilibradores de carga:** según diseños determinados 

### Pasos para la implementación
<a name="implementation-steps"></a>
+  Cree cargas de trabajo que sean estables estáticamente y funcionen en un solo modo. En este caso, aprovisione suficientes instancias en cada región o zona de disponibilidad para gestionar la capacidad de la carga de trabajo en caso de que se eliminara una región o zona de disponibilidad. Puede usar una variedad de servicios para el enrutamiento a recursos en buen estado, como: 
  +  [Cross Region DNS Routing](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html) 
  +  [MRAP Amazon S3 MultiRegion Routing](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html) 
  +  [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) 
  +  [Controlador de recuperación de aplicaciones de Amazon](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  Configure las [réplicas de lectura de base de datos](https://aws.amazon.com/rds/features/multi-az/) de modo que tengan en cuenta la pérdida de una única instancia principal o una réplica de lectura. Si las réplicas de lectura atienden el tráfico, la cantidad en cada zona de disponibilidad y cada región debe ser igual a la necesidad general en caso de que se produzca un error en la zona o región. 
+  Configure los datos cruciales en el almacenamiento de Amazon S3 que está diseñado para ser estáticamente estable para los datos almacenados en caso de que se produzca un error en la zona de disponibilidad. Si se utiliza la clase de almacenamiento [Amazon S3 One Zone-IA](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/), no debe considerarse estable desde el punto de vista estático, ya que la pérdida de esa zona minimiza el acceso a los datos almacenados. 
+  Los [equilibradores de carga](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) a veces están configurados incorrectamente o por diseño para prestar servicio a una zona de disponibilidad específica. En este caso, el diseño estáticamente estable podría consistir en distribuir una carga de trabajo entre varias zonas de disponibilidad en un diseño más complejo. El diseño original se puede utilizar para reducir el tráfico entre zonas por motivos de seguridad, latencia o costo. 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas de Well-Architected relacionadas:** 
+  [Availability Definition](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP01 Supervisión de todos los componentes de la carga de trabajo para detectar errores](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 
+  [REL11-BP04 Confianza en el plano de datos y no en el plano de control durante la recuperación](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html) 

 **Documentos relacionados:** 
+  [Minimizing Dependencies in a Disaster Recovery Plan](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) 
+  [Amazon Builders' Library: estabilidad estática con zonas de disponibilidad](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 
+  [Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html) 
+  [Estabilidad estática con zonas de disponibilidad](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 
+  [RDS multizona](https://aws.amazon.com/rds/features/multi-az/) 
+  [Minimizing Dependencies in a Disaster Recovery Plan](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) 
+  [Cross Region DNS Routing](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html) 
+  [MRAP Amazon S3 MultiRegion Routing](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html) 
+  [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) 
+  [Controlador de recuperación de aplicaciones de Amazon](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  [Amazon S3 de zona única](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) 
+  [Cross Zone Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) 

 **Videos relacionados:** 
+  [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704) 

# REL11-BP06 Envío de notificaciones cuando los eventos afecten a la disponibilidad
<a name="rel_withstand_component_failures_notifications_sent_system"></a>

 Se envían notificaciones cuando se detecta que se han superado los umbrales, incluso si el evento que causó el problema se ha resuelto automáticamente. 

 La corrección automática permite que la carga de trabajo sea fiable. Sin embargo, también puede ocultar problemas subyacentes que deberían abordarse. Implemente una supervisión y unos eventos adecuados para poder detectar patrones de problemas, incluidos los que pueden abordarse mediante corrección automática, para que pueda resolver los problemas de la causa fundamental. 

 Los sistemas resilientes están diseñados para que los eventos de degradación se comuniquen inmediatamente a los equipos correspondientes. Estas notificaciones deben enviarse a través de uno o varios canales de comunicación. 

 **Resultado deseado:** las alertas se envían inmediatamente a los equipos de operaciones cuando se superan los umbrales, como las tasas de error, la latencia u otras métricas cruciales de los indicadores clave de rendimiento (KPI), para que estos problemas se resuelvan lo antes posible y se evite o minimice el impacto en los usuarios. 

 **Patrones comunes de uso no recomendados:** 
+  Enviar demasiadas alarmas. 
+  Enviar alarmas que no son procesables. 
+  Establecer umbrales de alarma demasiado altos (muy sensibles) o demasiado bajos (poco sensibles). 
+  No enviar alarmas para dependencias externas. 
+  No considerar los [errores grises](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) al diseñar la supervisión y las alarmas. 
+  Llevar a cabo la automatización de la reparación, pero sin notificar al equipo adecuado que se necesita una reparación. 

 **Beneficios de establecer esta práctica recomendada:** las notificaciones de recuperación permiten que los equipos operativos y empresariales estén al tanto de las degradaciones del servicio para que puedan reaccionar de inmediato y minimizar tanto el tiempo medio de detección (MTTD) como el tiempo medio de reparación (MTTR). Las notificaciones de los eventos de recuperación también garantizan que no se ignoren problemas que ocurren con poca frecuencia. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio. Si no se implementan los mecanismos adecuados de supervisión y notificación de eventos, es posible que no se detecten patrones de problemas, incluidos los que pueden abordarse mediante la corrección automática. El equipo solo descubrirá la degradación del sistema cuando los usuarios se pongan en contacto con el servicio de atención al cliente o por casualidad. 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Al definir una estrategia de supervisión, la activación de una alarma es un evento frecuente. Es probable que este evento contenga un identificador de la alarma, el estado de la alarma (como `IN ALARM` o `OK`) y los detalles de lo que la desencadenó. En muchos casos, se debe detectar el evento de alarma y enviar una notificación por correo electrónico. Este es un ejemplo de una acción en una alarma. La notificación de alarmas es fundamental en la observabilidad, ya que informa a las personas adecuadas de que existe un problema. Sin embargo, cuando la acción sobre los eventos madura en su solución de observabilidad, puede solucionar el problema automáticamente sin necesidad de intervención humana. 

 Una vez que se hayan establecido las alarmas de supervisión de los KPI, se deben enviar alertas a los equipos correspondientes cuando se superen los umbrales. Esas alertas también se pueden usar para activar procesos automatizados que intentarán corregir la degradación. 

 Para una supervisión de umbrales más compleja, se deben considerar las alarmas compuestas. Las alarmas compuestas utilizan una serie de alarmas de supervisión de KPI para crear una alerta basada en la lógica empresarial operativa. Las alarmas de CloudWatch se pueden configurar para enviar correos electrónicos o para registrar incidentes en sistemas de seguimiento de incidentes de terceros mediante la integración con Amazon SNS o Amazon EventBridge. 

### Pasos para la implementación
<a name="implementation-steps"></a>

 Cree varios tipos de alarmas en función de la forma en que se supervisan las cargas de trabajo, como, por ejemplo: 
+  Las alarmas de las aplicaciones se utilizan para detectar cuando alguna parte de la carga de trabajo no funciona correctamente. 
+  Las [alarmas de la infraestructura](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) indican cuándo escalar los recursos. Las alarmas se pueden mostrar visualmente en paneles, enviar alertas a través de Amazon SNS o por correo electrónico y trabajar con el escalado automático para reducir o escalar horizontalmente los recursos de la carga de trabajo. 
+  Se pueden crear [alarmas estáticas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) sencillas para supervisar cuando una métrica supera un umbral estático durante un número específico de periodos de evaluación. 
+  Las [alarmas compuestas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) pueden abarcar alarmas complejas de numerosos orígenes. 
+  Una vez creada la alarma, cree los eventos de notificación adecuados. Puede invocar directamente una [API de Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) para enviar notificaciones y vincular cualquier automatización para su corrección o comunicación. 
+  Manténgase informado sobre las degradaciones del servicio con [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/). [Cree notificaciones de eventos de AWS Health adecuados para su propósito](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html) para los canales de correo electrónico y chat a través de [AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) e intégrelas mediante programación con [las herramientas de supervisión y alertas a través de Amazon EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html). 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas de Well-Architected relacionadas:** 
+  [Availability Definition](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 

 **Documentos relacionados:** 
+  [Cree una alarma de CloudWatch basada en un umbral estático](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) 
+  [Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [What is Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 
+  [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Uso de las alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Configuración de alarmas compuestas de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) 
+  [What's new in AWS Observability at re:Invent 2022](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2022/) 

 **Herramientas relacionadas:** 
+  [CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) 

# REL11-BP07 Diseño de su producto para cumplir objetivos de disponibilidad y acuerdos de nivel de servicio (SLA) de tiempo de actividad
<a name="rel_withstand_component_failures_service_level_agreements"></a>

Diseñe el producto para que cumpla con los objetivos de disponibilidad y los acuerdos de nivel de servicio (SLA) de tiempo de actividad. Si publica o acuerda en privado objetivos de disponibilidad o SLA de tiempo de actividad, verifique que su arquitectura y procesos operativos están diseñados para admitirlos. 

 **Resultado deseado:** cada aplicación tiene un objetivo definido de disponibilidad y un SLA para las métricas de rendimiento, que se pueden supervisar y mantener para cumplir con los resultados comerciales. 

 **Patrones comunes de uso no recomendados:** 
+  Diseño e implementación de cargas de trabajo sin establecer acuerdos de nivel de servicio. 
+  Las métricas de los SLA se fijan en niveles demasiado altos sin justificación ni requisitos empresariales. 
+  Establecimiento de SLA sin tener en cuenta las dependencias y sus SLA subyacentes. 
+  Los diseños de aplicaciones se crean sin tener en cuenta el Modelo de responsabilidad compartida para la resiliencia. 

 **Beneficios de establecer esta práctica recomendada:** diseñar aplicaciones en función de los objetivos clave de resiliencia ayuda a cumplir los objetivos empresariales y las expectativas de los clientes. Estos objetivos contribuyen a impulsar el proceso de diseño de aplicaciones que evalúa diferentes tecnologías y tiene en cuenta varios compromisos. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio 

## Guía para la implementación
<a name="implementation-guidance"></a>

 El diseño de aplicaciones debe tener en cuenta una serie de requisitos derivados de objetivos empresariales, operativos y financieros. Dentro de los requisitos operativos, las cargas de trabajo deben tener objetivos concretos de métricas de resiliencia para que se puedan supervisar y respaldar adecuadamente. Las métricas de resiliencia no deben establecerse ni derivarse después de implementar la carga de trabajo. En cambio, deben definirse durante la fase de diseño y ayudar a orientar diversas decisiones y compensaciones. 
+  Cada carga de trabajo debe tener su propio conjunto de métricas de resiliencia. Esas métricas pueden ser diferentes de las de otras aplicaciones empresariales. 
+  Reducir las dependencias puede tener un impacto positivo en la disponibilidad. Cada carga de trabajo debe considerar sus dependencias y sus SLA. En general, seleccione dependencias con objetivos de disponibilidad iguales o superiores a los objetivos de su carga de trabajo. 
+  Siempre que sea posible, examine diseños de acoplamiento débil para que la carga de trabajo pueda funcionar correctamente a pesar del deterioro de las dependencias. 
+  Reduzca las dependencias del plano de control, especialmente durante la recuperación o una degradación. Evalúe diseños que sean estáticamente estables para las cargas de trabajo críticas. Utilice el ahorro de recursos para aumentar la disponibilidad de esas dependencias en una carga de trabajo. 
+  La observabilidad y la instrumentación son fundamentales para alcanzar los SLA al reducir el tiempo medio de detección (MTTD) y el tiempo medio de reparación (MTTR). 
+  Los tres factores que se utilizan para mejorar la disponibilidad en los sistemas distribuidos son una menor frecuencia de errores (MTBF más largo), tiempos de detección de errores más cortos (MTTD más corto) y tiempos de reparación más cortos (MTTR más corto). 
+  Establecer y cumplir las métricas de resiliencia para una carga de trabajo es una parte imprescindible de todo diseño eficaz. Estos diseños deben tener en cuenta las compensaciones de la complejidad del diseño, las dependencias de los servicios, el rendimiento, la escalabilidad y los costos. 

 **Pasos para la implementación** 
+  Revise y documente el diseño de la carga de trabajo con las siguientes preguntas en mente: 
  +  ¿Dónde se utilizan los planos de control en la carga de trabajo? 
  +  ¿Cómo implementa la carga de trabajo la tolerancia a errores? 
  +  ¿Cuáles son los patrones de diseño para el escalado, el escalado automático, la redundancia y los componentes de alta disponibilidad? 
  +  ¿Cuáles son los requisitos de coherencia y disponibilidad de los datos? 
  +  ¿Se tiene en cuenta el ahorro de recursos o la estabilidad estática de los recursos? 
  +  ¿Cuáles son las dependencias de los servicios? 
+  Defina las métricas de los SLA en función de la arquitectura de la carga de trabajo mientras trabaja con las partes interesadas. Considere los SLA de todas las dependencias que utiliza la carga de trabajo. 
+  Una vez establecido el objetivo del SLA, optimice la arquitectura para que cumpla el SLA. 
+  Una vez establecido el diseño que cumplirá el SLA, implemente cambios operativos, automatización de procesos y manuales de procedimientos que también se centren en reducir el MTTD y el MTTR. 
+  Una vez implementado, supervise y cree informes del SLA. 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [REL03-BP01 Elección de cómo segmentar su carga de trabajo](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 Implementación de la carga de trabajo en varias ubicaciones](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 Supervisión de todos los componentes de la carga de trabajo para detectar errores](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 Automatización de la reparación en todas las capas](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP04 Pruebas de resiliencia mediante ingeniería del caos](rel_testing_resiliency_failure_injection_resiliency.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) 
+ [ Comprender el estado de la carga de trabajo ](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)

 **Documentos relacionados:** 
+ [ Disponibilidad con redundancia ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [ Pilar de fiabilidad: disponibilidad ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [ Measuring availability ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Modelo de responsabilidad compartida para la resiliencia ](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)
+ [ Estabilidad estática con zonas de disponibilidad ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [Acuerdos de nivel de servicios (SLA) de AWS](https://aws.amazon.com/legal/service-level-agreements/)
+ [ Guidance for Cell-based Architecture on AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)
+ [AWS infrastructure ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [ Documento técnico Advanced Multi-AZ Resilience Patterns ](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)

 **Servicios relacionados:** 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)

# Pruebas de fiabilidad
<a name="test-reliability"></a>

 Una vez diseñada la carga de trabajo para que sea resiliente al estrés de producción, las pruebas son la única forma de garantizar que funcionará según lo previsto y proporcionará la resiliencia esperada. 

 Haga pruebas para comprobar que su carga de trabajo cumpla con los requisitos funcionales y no funcionales, ya que los errores o los cuellos de botella en el rendimiento pueden afectar a la fiabilidad de la carga de trabajo. Pruebe la resiliencia de su carga de trabajo para poder encontrar errores latentes que solo aparecen en la producción. Haga estas pruebas regularmente. 

**Topics**
+ [REL12-BP01 Uso de manuales de estrategias para investigar los errores](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 Análisis después del incidente](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 Requisitos de escalado y rendimiento de las pruebas](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP04 Pruebas de resiliencia mediante ingeniería del caos](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP05 Planificación periódica de días de juego](rel_testing_resiliency_game_days_resiliency.md)

# REL12-BP01 Uso de manuales de estrategias para investigar los errores
<a name="rel_testing_resiliency_playbook_resiliency"></a>

 Permite obtener respuestas sistemáticas e inmediatas a escenarios de error que no se comprendan bien mediante la documentación del proceso de investigación en guías de estrategias. Los manuales de estrategias son pasos predefinidos hechos para identificar los factores que contribuyen a un escenario de error. Los resultados de cualquier paso del proceso se utilizan para determinar los siguientes pasos, hasta que el problema se identifique o escale. 

 El manual de estrategias es una planificación proactiva que debe hacer para poder tomar medidas reactivas de manera efectiva. Cuando se produzcan situaciones de error que no estén contempladas en el manual de estrategias, aborde primero el problema (resuelva la crisis). A continuación, repase los pasos que ha seguido para solucionar el problema y utilícelos para agregar una nueva entrada al manual de estrategias. 

 Tenga en cuenta que los manuales de estrategias se usan en respuesta a incidentes específicos, mientras que los manuales de procedimientos se usan para conseguir resultados específicos. A menudo, los manuales de procedimientos se utilizan para actividades rutinarias, mientras que los manuales de estrategias se utilizan para responder a eventos no rutinarios. 

 **Patrones comunes de uso no recomendados:** 
+  Planificar la implementación de una carga de trabajo sin conocer los procesos para diagnosticar los problemas o responder a los incidentes. 
+  Decisiones no planificadas acerca de qué sistemas se recopilan registros y métricas cuando se investiga un evento. 
+  No retener las métricas y los eventos el tiempo suficiente para poder recuperar los datos. 

 **Beneficios de establecer esta práctica recomendada:** la captura de esta información en manuales de estrategias garantiza que el proceso pueda seguirse sistemáticamente. La creación de manuales de estrategias limita la introducción de errores de la actividad manual. La automatización de manuales de estrategias reduce el tiempo para responder a un evento, ya que se elimina el requisito de intervención de un miembro del equipo o se dispone de información adicional al inicio de su intervención. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>
+  Use manuales de estrategias para identificar problemas. Los manuales de estrategias son procesos documentados para investigar problemas. Permita las respuestas sistemáticas e inmediatas a escenarios de error mediante la documentación de los procesos en manuales de estrategias. Los manuales de estrategias deben contener la información y las instrucciones necesarias para que alguien con la formación adecuada reúna la información correspondiente, identifique las posibles fuentes de error, aísle los errores y determine los factores que han contribuido al problema (hacer un análisis después del incidente). 
  +  Implemente manuales de estrategias como código. Efectúe sus operaciones como código mediante scripts de sus manuales de estrategias para garantizar la sistematicidad y reducir los errores provocados por los procesos manuales. Los manuales de estrategias pueden constar de varios scripts que representen los diferentes pasos que podrían ser necesarios para identificar los factores que contribuyen a un problema. Se pueden invocar o llevar a cabo actividades del manual de procedimientos como parte de las actividades de un manual de estrategias, o se puede solicitar la ejecución de un manual de estrategias en respuesta a eventos identificados. 
    +  [Automatice sus manuales operativos con AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/) 
    +  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
    +  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
    +  [¿Qué es AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 
    +  [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
    +  [Uso de las alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
+  [Automatice sus manuales operativos con AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/) 
+  [Uso de las alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Uso de canarios (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [¿Qué es AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 

 **Ejemplos relacionados:** 
+  [Automating operations with Playbooks and Runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 

# REL12-BP02 Análisis después del incidente
<a name="rel_testing_resiliency_rca_resiliency"></a>

 Revise los eventos que afectan a los clientes e identifique los factores que contribuyen al evento y las medidas preventivas. Use esta información para desarrollar un plan de mitigación que limite o evite la reaparición del problema. Desarrolle procedimientos para proporcionar respuestas rápidas y eficaces. Comunique los factores que han contribuido al problema y las medidas correctivas según corresponda, adaptados al público de destino. Disponga de un método para comunicar estas causas a otros usuarios según sea necesario. 

 Evalúe por qué las pruebas existentes no han detectado el problema. Agregue pruebas para este caso si no hay pruebas ya establecidas. 

 **Resultado deseado:** sus equipos tienen un enfoque coherente y consensuado para gestionar el análisis posterior al incidente. Un mecanismo es el [proceso de corrección de errores (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/). El proceso de COE ayuda a los equipos a identificar, comprender y abordar las causas fundamentales de los incidentes, a la vez que crea mecanismos y barreras de protección para limitar la probabilidad de que se repita el mismo incidente. 

 **Patrones comunes de uso no recomendados:** 
+  Buscar los factores que han contribuido al problema, pero no seguir investigando si existen otros problemas potenciales o enfoques que mitigar. 
+  Identificar solo los errores humanos y no proporcionar ninguna formación o automatización que pueda evitar estos errores. 
+  Concentrarse en determinar la culpa en lugar de en conocer la causa fundamental, lo que da lugar a una cultura de miedo y obstaculiza la comunicación abierta. 
+  No intercambiar información, lo que hace que los resultados del análisis de incidentes los conozca solo un grupo pequeño y evita que otros se beneficien de las lecciones aprendidas. 
+  No existe ningún mecanismo para capturar el conocimiento institucional, por lo que se pierde información valiosa al no preservar las lecciones aprendidas en forma de actualizaciones de las prácticas recomendadas y, por lo tanto, se repiten incidentes con la misma causa fundamental o una similar 

 **Beneficios de establecer esta práctica recomendada:** hacer análisis después de un incidente y compartir los resultados permite que el riesgo se mitigue en otras cargas de trabajo si estas tienen implementadas los mismos factores que han contribuido al problema, y permite también implementar la mitigación o la recuperación automatizada antes de que se produzca un incidente. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Un buen análisis posterior a un incidente ofrece oportunidades de proponer soluciones comunes para problemas con patrones de arquitectura que se utilizan en otros lugares de los sistemas. 

 Un aspecto clave del proceso de COE es documentar y resolver los problemas. Es recomendable definir una forma estandarizada de documentar las causas fundamentales críticas y garantizar que estas se revisan y solucionan. Asigne una responsabilidad clara al proceso de análisis posterior al incidente. Nombre un equipo o persona responsable que supervise las investigaciones y el seguimiento de los incidentes. 

 Fomente una cultura que se centre en el aprendizaje y la mejora en lugar de en la culpa. Haga hincapié en que el objetivo es prevenir futuros incidentes, no penalizar a las personas. 

 Desarrolle procedimientos bien definidos para llevar a cabo análisis posteriores a los incidentes. En estos procedimientos, se deben describir los pasos que hay que seguir, la información que se va a recopilar y las preguntas clave que se abordarán durante el análisis. Investigue los incidentes a fondo y vaya más allá de las causas inmediatas para identificar las causas fundamentales y los factores que contribuyen a ellos. Utilice técnicas como los *[cinco porqués](https://en.wikipedia.org/wiki/Five_whys)* para profundizar en los problemas subyacentes. 

 Mantenga un repositorio de las lecciones aprendidas de los análisis de incidentes. Este conocimiento institucional puede servir como referencia para incidentes futuros e iniciativas de prevención. Comparta los resultados y la información de los análisis posteriores a los incidentes y considere la posibilidad de celebrar reuniones de revisión de invitación abierta después de los incidentes para analizar las lecciones aprendidas. 

### Pasos para la implementación
<a name="implementation-steps"></a>
+  Al hacer un análisis posterior al incidente, asegúrese de que en el proceso no se culpe a nadie. Esto permite que las personas involucradas en el incidente se muestren imparciales con respecto a las medidas correctivas propuestas, además de fomentar una autoevaluación honesta y la colaboración entre los equipos. 
+  Defina una forma estandarizada de documentar los problemas críticos. Un ejemplo de estructura para dicho documento es el siguiente: 
  +  ¿Qué ha pasado? 
  +  ¿Cómo ha afectado a los clientes y a la empresa? 
  +  ¿Cuál ha sido la causa fundamental? 
  +  ¿Qué datos tiene para corroborarlo? 
    +  Por ejemplo, métricas y gráficos 
  +  ¿Qué pilares básicos estuvieron implicados, con especial atención a la seguridad? 
    +  Al diseñar cargas de trabajo, se hacen concesiones entre pilares según el contexto del negocio. Estas decisiones de negocio puede impulsar sus prioridades de diseño. Podría dar preferencia a reducir el costo a expensas de la fiabilidad en el desarrollo de entornos o, para soluciones críticas, podría optimizar la fiabilidad con un aumento de los costos. La seguridad siempre es la tarea primordial, ya que sus clientes deben estar protegidos. 
  +  ¿Qué lecciones aprendió? 
  +  ¿Qué medidas correctivas va a tomar? 
    +  Elementos de acción 
    +  Elementos relacionados 
+  Cree procedimientos operativos estándar bien definidos para llevar a cabo análisis posteriores a los incidentes. 
+  Configure un proceso estandarizado de notificación de incidentes. Documente todos los incidentes de manera exhaustiva, incluido el informe inicial del incidente, los registros, las comunicaciones y las medidas tomadas durante el incidente. 
+  Recuerde que un incidente no requiere una interrupción. Podría tratarse de un cuasi incidente o de un sistema que funciona de una forma inesperada, pero que cumple su función. 
+  Mejore continuamente su proceso de análisis posterior a un incidente en función de los comentarios y las lecciones aprendidas. 
+  Registre los resultados clave en un sistema de administración del conocimiento y considere cualquier patrón que deba agregarse a las guías para desarrolladores o a las listas de verificación previas a la implementación. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Why you should develop a correction of error (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/) 

 **Videos relacionados:** 
+ [ Amazon’s approach to failing successfully ](https://aws.amazon.com/builders-library/amazon-approach-to-failing-successfully/)
+ [AWS re:Invent 2021 - Amazon Builders’ Library: Operational Excellence at Amazon ](https://www.youtube.com/watch?v=7MrD4VSLC_w)

# REL12-BP03 Requisitos de escalado y rendimiento de las pruebas
<a name="rel_testing_resiliency_test_non_functional"></a>

 Utilice técnicas, como las pruebas de carga, para validar que la carga de trabajo satisface los requisitos de escalado y rendimiento. 

 En la nube, puede crear un entorno de pruebas a escala de producción bajo demanda para la carga de trabajo. En lugar de confiar en un entorno de pruebas reducido, lo que podría provocar predicciones inexactas de los comportamientos de producción, puede utilizar la nube para proporcionar un entorno de pruebas que refleje fielmente el entorno de producción esperado. Este entorno lo ayuda a realizar pruebas en una simulación más precisa de las condiciones reales a las que se enfrenta su aplicación. 

 Además de las pruebas de rendimiento que intente llevar a cabo, asegúrese de validar que los recursos básicos, la configuración de escalado, las cuotas de servicio y el diseño de resiliencia funcionen según lo esperado bajo carga. Este enfoque holístico verifica que su aplicación pueda escalarse y funcionar de manera confiable según sea necesario, incluso en las condiciones más exigentes. 

 **Resultado deseado:** su carga de trabajo mantiene el comportamiento esperado incluso cuando está sujeta a picos de carga. Aborda de forma proactiva cualquier problema relacionado con el rendimiento que pueda surgir a medida que la aplicación crece y evoluciona. 

 **Patrones comunes de uso no recomendados:** 
+  Utiliza entornos de prueba que no coinciden estrechamente con el entorno de producción. 
+  Considera las pruebas de carga como una actividad independiente y única, y no como una parte integrada del proceso de integración continua (CI) de la implementación. 
+  No se definen requisitos de rendimiento claros y mensurables, como el tiempo de respuesta, el rendimiento y los objetivos de escalabilidad. 
+  Realiza pruebas con escenarios de carga poco realistas o insuficientes, y no realiza pruebas para detectar picos de carga, picos repentinos y cargas elevadas sostenidas. 
+  No se pone a prueba la carga de trabajo usando límites de carga esperados excesivos. 
+  Utilizas herramientas de pruebas de carga y elaboración de perfiles de rendimiento inadecuadas. 
+  Carece de sistemas integrales de supervisión y alerta para realizar un seguimiento de las métricas de rendimiento y detectar anomalías. 

 **Beneficios de establecer esta práctica recomendada:** 
+  Las pruebas de carga lo ayudan a identificar posibles obstáculos en el rendimiento de su sistema antes de que entre en producción. Al simular el tráfico y las cargas de trabajo en la producción, puede identificar las áreas en las que el sistema puede tener dificultades para gestionar la carga, como los tiempos de respuesta lentos, la escasez de recursos o los fallos del sistema. 
+  Probar el sistema en distintas condiciones de carga lo ayudará a comprender mejor los requisitos de recursos necesarios para respaldar su carga de trabajo. Esta información puede ayudarlo a tomar decisiones fundamentadas sobre la asignación de recursos y a evitar el aprovisionamiento excesivo o insuficiente de los recursos. 
+  Para identificar los posibles puntos de fallo, puede observar el rendimiento de su carga de trabajo en condiciones de carga elevada. Esta información lo ayuda a mejorar la fiabilidad y la resiliencia de su carga de trabajo mediante la implementación de mecanismos de tolerancia a fallos, estrategias de conmutación por error y medidas de redundancia, según corresponda. 
+  Puede identificar y abordar los problemas de rendimiento anticipadamente y evitar así el elevado coste de las interrupciones del sistema, la lentitud de los tiempos de respuesta y la insatisfacción de los usuarios. 
+  Los datos de rendimiento detallados y la información de creación de perfiles recopilados durante las pruebas pueden ayudarlo a solucionar los problemas relacionados con el rendimiento que puedan surgir en la producción. Esto puede acelerar la respuesta y la resolución de los incidentes, lo que reduce el impacto en los usuarios y en las operaciones de la organización. 
+  En algunos sectores, las pruebas de rendimiento proactivas pueden ayudar a que su carga de trabajo cumpla con los estándares de conformidad, lo que reduce el riesgo de sanciones o problemas legales. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 El primer paso es definir una estrategia de pruebas integral que abarque todos los aspectos de los requisitos de escalado y rendimiento. Para empezar, defina claramente los objetivos de nivel de servicio (SLO) de su carga de trabajo en función de las necesidades de su empresa, como el rendimiento, el histograma de latencia y la tasa de errores. A continuación, diseñe un conjunto de pruebas que puedan simular varios escenarios de carga, desde un uso medio hasta picos repentinos y picos de carga sostenidos, y compruebe que el comportamiento de la carga de trabajo cumpla con sus SLO. Estas pruebas deben automatizarse e integrarse en la canalización de integración e implementación continuas para detectar las regresiones de rendimiento al principio del proceso de desarrollo. 

 Para probar de forma eficaz el escalado y el rendimiento, invierta en las herramientas y la infraestructura adecuadas. Esto incluye herramientas de pruebas de carga que pueden generar un tráfico de usuarios realista, herramientas de creación de perfiles de rendimiento para identificar los cuellos de botella y soluciones de supervisión para realizar un seguimiento de las métricas clave. Por otro lado, es muy importante comprobar que sus entornos de prueba se ajusten perfectamente al entorno de producción en términos de infraestructura y condiciones ambientales para que los resultados de las pruebas sean lo más precisos posible. Para facilitar la replicación y el escalado fiables de configuraciones similares a las de producción, utilice la infraestructura como código y aplicaciones basadas en contenedores. 

 Las pruebas de escalado y rendimiento son un proceso continuo, no una actividad que se realiza una sola vez. Implemente la supervisión y las alertas de manera exhaustiva para realizar un seguimiento del rendimiento de la aplicación en producción y utilice estos datos para perfeccionar continuamente sus estrategias de prueba y sus esfuerzos de optimización. Analice periódicamente los datos de rendimiento para identificar los problemas que surjan, pruebe nuevas estrategias de escalado e implemente optimizaciones para mejorar la eficiencia y la fiabilidad de la aplicación. Si adopta un enfoque iterativo y aprende constantemente de los datos de producción, puede comprobar que su aplicación puede adaptarse a las demandas variables de los usuarios y mantener la resiliencia y un rendimiento óptimo a lo largo del tiempo. 

### Pasos para la implementación
<a name="implementation-steps"></a>

1.  Establezca requisitos de rendimiento claros y mensurables, como el tiempo de respuesta, el rendimiento y los objetivos de escalabilidad. Estos requisitos deben basarse en los patrones de uso de la carga de trabajo, las expectativas de los usuarios y las necesidades empresariales. 

1.  Seleccione y configure una herramienta de pruebas de carga que pueda imitar con precisión los patrones de carga y el comportamiento de los usuarios en su entorno de producción. 

1.  Configure un entorno de pruebas que se ajuste perfectamente al entorno de producción, incluidas las condiciones de la infraestructura y el entorno, para mejorar la precisión de los resultados de las pruebas. 

1.  Cree un conjunto de pruebas que abarque una amplia gama de escenarios, desde patrones de uso promedio hasta picos de carga, picos rápidos y cargas elevadas sostenidas. Integre las pruebas en la canalización de integración e implementación continuas para detectar las regresiones de rendimiento al principio del proceso de desarrollo. 

1.  Realice pruebas de carga para simular el tráfico de usuarios del mundo real y comprender cómo se comporta su aplicación en diferentes condiciones de carga. Para someter la aplicación a una prueba de estrés, supere la carga esperada y observe su comportamiento, como la degradación del tiempo de respuesta, el agotamiento de los recursos o los fallos del sistema. Esto ayuda a identificar el punto de ruptura de su aplicación y a determinar las estrategias de escalado. Evalúe la escalabilidad de su carga de trabajo aumentando gradualmente la carga y mida el impacto en el rendimiento para identificar los límites de escalado y planificar las necesidades de capacidad futuras. 

1.  Implemente la supervisión y las alertas de manera exhaustiva para realizar un seguimiento de las métricas de rendimiento, detectar anomalías e iniciar acciones de escalado o notificaciones cuando se superen los umbrales. 

1.  Supervise y analice continuamente los datos de rendimiento para identificar las áreas de mejora. Repita sus estrategias de prueba y sus esfuerzos de optimización. 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [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) 
+  [REL06-BP01 Supervisión de todos los componentes de la carga de trabajo (generación)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html) 
+  [REL06-BP03 Envío de notificaciones (procesamiento y alarmas en tiempo real)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html) 

 **Documentos relacionados:** 
+  [Aplicaciones de pruebas de carga](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html) 
+  [Pruebas de carga distribuidas en AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) 
+  [Supervisión del rendimiento de las aplicaciones](https://aws.amazon.com/what-is/application-performance-monitoring/) 
+  [Amazon EC2 Testing Policy](https://aws.amazon.com/ec2/testing/) 

 **Ejemplos relacionados:** 
+  [Pruebas de carga distribuidas en AWS (GitHub)](https://github.com/aws-solutions/distributed-load-testing-on-aws) 

 **Herramientas relacionadas:** 
+  [Generador de perfiles de Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html) 
+  [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 
+  [Apache JMeter](https://jmeter.apache.org/) 
+  [K6](https://k6.io/) 
+  [Vegeta](https://github.com/tsenart/vegeta) 
+  [Hey](https://github.com/rakyll/hey) 
+  [ab](https://httpd.apache.org/docs/2.4/programs/ab.html) 
+  [wrk](https://github.com/wg/wrk) 
+ [Pruebas de carga distribuidas en AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)

# REL12-BP04 Pruebas de resiliencia mediante ingeniería del caos
<a name="rel_testing_resiliency_failure_injection_resiliency"></a>

 Haga experimentos de caos con regularidad en entornos que estén en producción o lo más cerca posible de ella para entender cómo responde su sistema a condiciones adversas. 

 ** Resultado deseado: ** 

 La resiliencia de la carga de trabajo se verifica regularmente aplicando la ingeniería del caos en forma de experimentos de inyección de errores o inyección de carga inesperada, además de las pruebas de resiliencia que validan el comportamiento esperado conocido de su carga de trabajo durante un evento. Combine la ingeniería del caos y las pruebas de resiliencia para tener la seguridad de que su carga de trabajo puede sobrevivir a los errores de los componentes y puede recuperarse de las interrupciones inesperadas con un impacto mínimo o nulo. 

 ** Patrones comunes de uso no recomendados: ** 
+  Diseñar para lograr la resiliencia, pero no verificar cómo funciona la carga de trabajo en su conjunto cuando se producen errores. 
+  No experimentar nunca en condiciones reales y con la carga prevista. 
+  No tratar los experimentos como código ni mantenerlos durante el ciclo de desarrollo. 
+  No ejecutar experimentos de caos tanto como parte de su canalización de CI/CD, así como fuera de las implementaciones. 
+  No utilizar los análisis posteriores a los incidentes a la hora de determinar los errores con los que experimentar. 

 **Beneficios de establecer esta práctica recomendada:** inyectar errores para verificar la resiliencia de la carga de trabajo permite tener seguridad de que los procedimientos de recuperación de su diseño resiliente funcionarán en caso de un error real. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio 

## Guía para la implementación
<a name="implementation-guidance"></a>

 La ingeniería del caos proporciona a sus equipos capacidades para inyectar continuamente interrupciones del mundo real (simulaciones) de forma controlada según el proveedor de servicios, infraestructura, carga de trabajo y componentes, con un impacto mínimo o nulo para sus clientes. Permite que sus equipos aprendan de los errores y observen, midan y mejoren la resiliencia de las cargas de trabajo, además de validar que las alertas se activen y que los equipos reciban notificaciones en caso de algún evento. 

 Cuando se hace de forma continua, la ingeniería del caos puede poner de manifiesto deficiencias en las cargas de trabajo que, si no se abordan, podrían afectar negativamente a la disponibilidad y al funcionamiento. 

**nota**  
La ingeniería del caos es la disciplina que consiste en experimentar en un sistema para generar confianza en la capacidad del sistema de resistir condiciones adversas en producción. – [Principios de la ingeniería del caos](https://principlesofchaos.org/) 

 Si un sistema puede soportar estas interrupciones, el experimento del caos debe mantenerse como una prueba de regresión automatizada. De este modo, los experimentos de caos deben hacerse como parte de su ciclo de vida de desarrollo de sistemas (SDLC) y como parte de su canalización de CI/CD. 

 Para garantizar que la carga de trabajo puede sobrevivir a los errores de los componentes, inyecte eventos reales como parte de los experimentos. Por ejemplo, experimente con la pérdida de instancias de Amazon EC2 o la conmutación por error de la instancia primaria de la base de datos de Amazon RDS y verifique que la carga de trabajo no se ve afectada (o solo en un mínimo). Utilice una combinación de errores de componentes para simular los eventos que puede causar una interrupción en una zona de disponibilidad. 

 Para los errores a nivel de aplicación (como las caídas), se puede empezar con factores de estrés como el agotamiento de la memoria y la CPU. 

 Para validar los [mecanismos de respaldo y de conmutación por error](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) para las dependencias externas debido a interrupciones intermitentes de la red, sus componentes deben simular un evento de este tipo mediante el bloqueo del acceso a los proveedores de terceros durante una duración especificada que puede durar desde segundos hasta horas. 

 Otros modos de degradación podrían provocar una funcionalidad reducida y respuestas lentas, lo que a menudo da como resultado una interrupción de los servicios. Los orígenes comunes de esta degradación son una mayor latencia en los servicios críticos y una comunicación de red poco fiable (paquetes omitidos). Los experimentos con estos errores, como, por ejemplo, efectos de red como la latencia, los mensajes perdidos y los errores de DNS, podrían incluir la incapacidad de resolver un nombre, alcanzar el servicio DNS o establecer conexiones con servicios dependientes. 

 **Herramientas de ingeniería del caos:** 

 AWS Fault Injection Service (AWS FIS) es un servicio completamente administrado para hacer experimentos de inyección de errores que puede utilizarse como parte de su canalización de CD. AWS FIS es una buena opción para usar durante los días de simulación de ingeniería del caos. Admite la introducción simultánea de errores en distintos tipos de recursos, tales como Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) y Amazon RDS. Estos errores incluyen la terminación de los recursos, forzado de conmutación por error, estrés de CPU o memoria, limitación, latencia y pérdida de paquetes. Al estar integrado con las alarmas de Amazon CloudWatch, puede configurar las condiciones de detención como barreras de protección para revertir un experimento si provoca un impacto inesperado. 

![\[Diagrama en el que se muestra la integración de AWS Fault Injection Service con los recursos de AWS para permitirle ejecutar experimentos de inyección de errores para las cargas de trabajo.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/fault-injection-simulator.png)


También hay varias opciones de terceros para los experimentos de inyección de errores. Entre estas se incluyen herramientas de código abierto como [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/) y [Litmus Chaos](https://litmuschaos.io/), así como opciones comerciales como Gremlin. Para ampliar el número de errores que se pueden inyectar en AWS, AWS FIS [se integra con Chaos Mesh y Litmus Chaos](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/), lo que le permite coordinar los flujos de trabajo de inyección de errores entre varias herramientas. Por ejemplo, puede ejecutar una prueba de estrés en la CPU de un pod mediante errores de Chaos Mesh o Litmus, además de terminar un porcentaje seleccionado al azar de nodos del clúster mediante acciones de error de AWS FIS. 

## Pasos para la implementación
<a name="implementation-steps"></a>

1.  Determine qué errores se van a utilizar en los experimentos. 

    Evalúe el diseño de su carga de trabajo para la resiliencia. Estos diseños (creados mediante las prácticas recomendadas del [Marco de Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)) tienen en cuenta los riesgos en función de las dependencias críticas, los eventos pasados, los problemas conocidos y los requisitos de cumplimiento. Enumere cada elemento del diseño destinado a mantener la resiliencia y los errores que pretende mitigar. Para obtener más información sobre la creación de dichas listas, consulte el [documento técnico sobre revisión de la preparación operativa](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html), que guía sobre cómo crear un proceso para evitar que se repitan incidentes anteriores. El proceso de análisis de modos de error y efectos (FMEA) le proporciona un marco para hacer un análisis de los errores de componentes y cómo afectan a la carga de trabajo. Adrian Cockcroft describe con más detalle el FMEA en [Failure Modes and Continuous Resilience](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5). 

1.  Asigne una prioridad a cada error. 

    Comience con una categorización amplia, como alta, media o baja. Para evaluar la prioridad, hay que tener en cuenta la frecuencia del error y su impacto en la carga de trabajo global. 

    Al considerar la frecuencia de un determinado error, analice los datos anteriores de esta carga de trabajo cuando estén disponibles. Si no están disponibles, utilice datos de otras cargas de trabajo que se ejecuten en un entorno similar. 

    Cuando se considera el impacto de un error determinado, cuanto mayor sea el alcance del error, generalmente mayor será el impacto. También hay que tener en cuenta el diseño y la finalidad de la carga de trabajo. Por ejemplo, la capacidad de acceder a los almacenes de datos de origen es fundamental para una carga de trabajo que haga transformaciones y análisis de datos. En este caso, se daría prioridad a los experimentos de errores de acceso, así como al acceso limitado y a la inserción de latencia. 

    Los análisis posteriores a los incidentes son un buen origen de datos para comprender tanto la frecuencia como el impacto de los modos de error. 

    Utilice la prioridad asignada para determinar con qué errores experimentar primero y en qué orden desarrollar nuevos experimentos de inyección de errores. 

1.  En cada experimento que haga, siga la ingeniería del caos y el volante de resiliencia continua en la figura siguiente.   
![\[Diagrama del volante de ingeniería del caos y resiliencia continua, en el que se muestran las fases de Mejora, Estado estable, Hipótesis, Ejecución del experimento y Verificación.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/chaos-engineering-flywheel.png)

    

   1.  Defina el estado estable como un resultado medible de una carga de trabajo que indica un comportamiento normal. 

       Su carga de trabajo exhibe un estado estable si está operando de manera fiable y como se espera. Por tanto, valide que su carga de trabajo tenga un buen estado antes de definir el estado estable. El estado estable no significa necesariamente que no haya impacto en la carga de trabajo cuando se produce un error, ya que un cierto porcentaje en los errores podría estar dentro de los límites aceptables. El estado estable es la línea de base que observará durante el experimento, que pondrá de manifiesto las anomalías si su hipótesis definida en el siguiente paso no resulta de la forma esperada. 

       Por ejemplo, un estado estable de un sistema de pagos puede definirse como el procesamiento de 300 TPS con una tasa de éxito del 99 % y un tiempo de ida y vuelta de 500 ms. 

   1.  Formule una hipótesis sobre cómo reaccionará la carga de trabajo ante el error. 

       Una buena hipótesis se basa en cómo se espera que la carga de trabajo mitigue el error para mantener el estado estable. La hipótesis establece que, dado el error de un tipo específico, el sistema o la carga de trabajo continuará en estado estable, porque la carga de trabajo se diseñó con mitigaciones específicas. En la hipótesis deben especificarse el tipo específico de error y las mitigaciones. 

       Se puede utilizar la siguiente plantilla para la hipótesis (pero también se acepta otra redacción): 
**nota**  
 Si se produce un *error específico*, el *nombre de la carga de trabajo* *describirá los controles de mitigación* para mantener el *impacto de las métricas empresariales o técnicas*. 

       Por ejemplo: 
      +  Si el 20 % de los nodos del grupo de nodos de Amazon EKS se eliminan, la API de creación de transacciones sigue sirviendo el percentil 99 de peticiones en menos de 100 ms (estado estable). Los nodos de Amazon EKS se recuperarán en cinco minutos y los pods se programarán y procesarán el tráfico en ocho minutos tras el inicio del experimento. Las alertas se activan en tres minutos. 
      +  Si se produce un error de instancia de Amazon EC2, la comprobación de estado de Elastic Load Balancing del sistema de pedidos hará que Elastic Load Balancing solo envíe solicitudes a las instancias en buen estado restantes mientras Amazon EC2 Auto Scaling sustituye la instancia con error, manteniendo un aumento inferior al 0,01 % en los errores del servidor (5xx) (estado estable). 
      +  Si se produce un error en la instancia de la base de datos principal de Amazon RDS, la carga de trabajo de recopilación de datos de la cadena de suministro se conmutará por error y se conectará a la instancia de la base de datos de Amazon RDS en espera para mantener menos de 1 minuto de errores de lectura o escritura en la base de datos (estado estable). 

   1.  Inyecte el error para hacer el experimento. 

       Un experimento debe ser de manera predeterminada a prueba de errores y tolerado por la carga de trabajo. Si sabe que se producirá un error en la carga de trabajo, no haga el experimento. Debe utilizarse la ingeniería del caos para encontrar incógnitas conocidas o incógnitas desconocidas. Las *incógnitas desconocidas* son aspectos que conoce, pero que no comprende del todo, y las *incógnitas desconocidas* son aspectos que no conoce ni comprende del todo. Experimentar con una carga de trabajo que se sabe que está descompuesta no proporcionará información nueva. El experimento se debe planificar con cuidado, tener un alcance claro del impacto y proporcionar un mecanismo de retroceso que pueda aplicarse en caso de turbulencias inesperadas. Si su diligencia demuestra que la carga de trabajo debe sobrevivir al experimento, siga adelante. Hay varias opciones para inyectar los errores. Para las cargas de trabajo en AWS, [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) proporciona diversas simulaciones de errores predefinidas que se denominan [acciones](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). También puede definir acciones personalizadas que se ejecuten en AWS FIS, mediante [documentos de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html). 

       Desaconsejamos el uso de scripts personalizados para los experimentos de caos, a menos que los scripts tengan la capacidad de entender el estado actual de la carga de trabajo, sean capaces de emitir registros y proporcionen mecanismos para retrocesos y condiciones de parada cuando sea posible. 

       Un marco o conjunto de herramientas eficaz que apoye la ingeniería del caos debe hacer el seguimiento del estado actual de un experimento, emitir registros y proporcionar mecanismos de reversión para apoyar la ejecución controlada de un experimento. Comience con un servicio establecido como AWS FIS que permite hacer experimentos con un alcance claramente definido y mecanismos de seguridad que reviertan el experimento si este introduce turbulencias inesperadas. Para obtener información sobre una variedad más amplia de experimentos mediante AWS FIS, consulte también el [laboratorio Resilient and Well-Architected Apps with Chaos Engineering](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). Además, [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) analizará la carga de trabajo y creará experimentos que puede elegir para implementar y ejecutar en AWS FIS. 
**nota**  
 Para cada experimento, comprenda claramente el alcance y su impacto. Recomendamos que los errores se simulen primero en un entorno de no producción antes de ejecutarlos en producción. 

       Cuando sea posible, los experimentos deben ejecutarse en un entorno de producción en condiciones reales, mediante [implementaciones canario](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) que permitan implementar un sistema de control y uno experimental. Ejecutar los experimentos durante las horas de menor actividad es una buena práctica para mitigar el impacto potencial cuando se experimenta por primera vez en producción. Además, si utilizar el tráfico real del cliente supone demasiado riesgo, puede hacer experimentos con tráfico sintético en la infraestructura de producción en las implementaciones de control y experimentales. Cuando no sea posible utilizar la producción, ejecute los experimentos en entornos de preproducción que sean lo más parecidos posible a la producción. 

       Debe establecer y supervisar las barreras de protección para garantizar que el experimento no afecte al tráfico de producción o a otros sistemas más allá de los límites aceptables. Establezca condiciones de parada para detener un experimento si alcanza un umbral en una métrica de barrera de protección que usted defina. Esto debe incluir las métricas para el estado estable de la carga de trabajo, así como la métrica en comparación con los componentes en los que está inyectando el error. Un [monitor sintético](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (también conocido como canario de usuario) es una métrica que normalmente debe incluir como proxy de usuario. Las [condiciones de parada para AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) se admiten como parte de la plantilla del experimento, lo que permite hasta cinco condiciones de parada por plantilla. 

       Uno de los principios del caos es minimizar el alcance del experimento y su impacto: 

       Aunque hay que tener en cuenta algún impacto negativo a corto plazo, es responsabilidad y obligación del ingeniero del caos garantizar que las consecuencias de los experimentos se minimicen y contengan. 

       Un método para verificar el alcance y el impacto potencial es hacer el experimento primero en un entorno que no sea de producción, y verificar que los umbrales para las condiciones de parada se activan como se espera durante un experimento y la observabilidad está disponible para detectar una excepción, en lugar de experimentar directamente en producción. 

       Cuando se hagan experimentos de inyección de errores, verifique que todas las partes responsables estén bien informadas. Comuníquese con los equipos adecuados, como los equipos de operaciones, los equipos de fiabilidad del servicio y el servicio de atención al cliente, para informarles de cuándo se llevarán a cabo los experimentos y qué pueden esperar. Proporcione herramientas de comunicación a estos equipos para que informen a quienes dirigen el experimento si observan algún efecto adverso. 

       Debe restablecer la carga de trabajo y sus sistemas subyacentes al estado original de funcionalidad comprobada. A menudo, el diseño resistente de la carga de trabajo se autorrepara. No obstante, algunos diseños de errores o experimentos con errores pueden dejar la carga de trabajo en un estado de error inesperado. Al final del experimento, debe ser consciente de ello y restablecer la carga de trabajo y los sistemas. Con AWS FIS puede establecer una configuración de reversión (también llamada acción posterior) en los parámetros de la acción. Una acción posterior devuelve el destino al estado en el que se encontraba antes de que se ejecutara la acción. Ya sean automatizadas (como con AWS FIS) o manuales, estas acciones posteriores deben formar parte de una guía de estrategias que describa cómo detectar y gestionar los errores. 

   1.  Verifique la hipótesis. 

      [Principios de la ingeniería del caos](https://principlesofchaos.org/) ofrece estas directrices sobre cómo verificar el estado estable de su carga de trabajo: 

      Céntrese en los resultados medibles de un sistema, más que en sus atributos internos. Las mediciones de esos resultados durante un corto periodo constituyen una aproximación al estado estable del sistema. El rendimiento global del sistema, las tasas de error y los percentiles de latencia podrían ser métricas de interés que representen el comportamiento del estado estable. Al centrarse en los patrones de comportamiento sistémico durante los experimentos, la ingeniería del caos verifica que el sistema funcione, en lugar de intentar validar su funcionamiento.

       En nuestros dos ejemplos anteriores, incluimos las métricas de estado estable de menos del 0,01 % de aumento de errores del servidor (5xx) y menos de un minuto de errores de lectura y escritura en la base de datos. 

       Los errores 5xx son una buena métrica porque son una consecuencia del modo de error que experimentará directamente un cliente de la carga de trabajo. La medición de los errores de la base de datos es buena como consecuencia directa del error, pero también debe complementarse con una medición del impacto en el cliente, como las solicitudes con errores de los clientes o los errores que aparecen en el cliente. Además, incluya un monitor sintético (también conocido como canario de usuario) en cualquier API o URI al que acceda directamente el cliente de su carga de trabajo. 

   1.  Mejora del diseño de la carga de trabajo para la resiliencia. 

       Si el estado estable no se mantuvo, investigue cómo se puede mejorar el diseño de la carga de trabajo para mitigar el error y aplique las prácticas recomendadas del [pilar de fiabilidad de AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Puede encontrar orientación y recursos adicionales en la [AWS Builders' Library](https://aws.amazon.com/builders-library/), que contiene artículos sobre cómo [mejorar las comprobaciones de estado](https://aws.amazon.com/builders-library/implementing-health-checks/) o [utilizar los reintentos con retroceso en el código de la aplicación](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/), entre otros temas. 

       Una vez aplicados estos cambios, vuelva a hacer el experimento (mostrado por la línea de puntos en el volante de ingeniería del caos) para determinar su eficacia. Si el paso de verificación indica que la hipótesis es cierta, entonces la carga de trabajo estará en estado estable y el ciclo continúa. 

1.  Lleve a cabo experimentos periódicos. 

    Un experimento de caos es un ciclo y los experimentos deben hacerse regularmente como parte de la ingeniería del caos. Después de que una carga de trabajo cumpla con la hipótesis del experimento, este debe automatizarse para ejecutarse continuamente como parte de la regresión de su canalización de CI/CD. Para obtener información sobre cómo hacerlo, consulte este blog sobre [cómo hacer experimentos de AWS FIS con AWS CodePipeline](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/). Este laboratorio sobre [experimentos recurrentes de AWS FIS en una canalización de CI/CD](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) le permite trabajar de forma práctica. 

    Los experimentos de inyección de errores también forman parte de los días de simulación (consulte [REL12-BP05 Planificación periódica de días de juego](rel_testing_resiliency_game_days_resiliency.md)). En los días de simulación se simula un error o evento para verificar los sistemas, los procesos y las respuestas de los equipos. El objetivo es llevar a cabo las acciones que llevaría a cabo el equipo si se produjera un evento excepcional. 

1.  Capture y almacene los resultados de los experimentos. 

   Los resultados de los experimentos de inyección de errores deben capturarse y persistir. Incluya todos los datos necesarios (como el tiempo, la carga de trabajo y las condiciones) para poder analizar posteriormente los resultados y las tendencias del experimento. Algunos ejemplos de resultados pueden ser capturas de pantalla de paneles, volcados en CSV de la base de datos de métricas o un registro escrito a mano de los eventos y las observaciones del experimento. El [registro de experimentos con AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) puede ser parte de esta captura de datos.

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [REL08-BP03 Integración de las pruebas de resiliencia como parte de la implementación](rel_tracking_change_management_resiliency_testing.md) 
+  [REL13-BP03 Prueba de la implementación de recuperación de desastres para validarla](rel_planning_for_recovery_dr_tested.md) 

 **Documentos relacionados:** 
+  [Qué es AWS Fault Injection Service?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 
+  [Qué es AWS Resilience Hub?](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 
+  [Principios de la ingeniería del caos](https://principlesofchaos.org/) 
+  [Chaos Engineering: Planning your first experiment](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde) 
+  [Resilience Engineering: Learning to Embrace Failure](https://queue.acm.org/detail.cfm?id=2371297) 
+  [Chaos Engineering stories](https://github.com/ldomb/ChaosEngineeringPublicStories) 
+  [Evitar los planes alternativos en los sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) 
+  [Canary Deployment for Chaos Experiments](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) 

 **Videos relacionados:** 
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering (ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg) 
+  [AWS re:Invent 2019: Improving resiliency with chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY) 
+  [AWS re:Invent 2019: Performing chaos engineering in a serverless world (CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA) 

 ** Herramientas relacionadas: ** 
+  [AWS Fault Injection Service](https://aws.amazon.com/fis/) 
+ AWS Marketplace: [Gremlin Chaos Engineering Platform](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney) 
+  [Chaos Toolkit](https://chaostoolkit.org/) 
+  [Chaos Mesh](https://chaos-mesh.org/) 
+  [Litmus](https://litmuschaos.io/) 

# REL12-BP05 Planificación periódica de días de juego
<a name="rel_testing_resiliency_game_days_resiliency"></a>

 Organice días de juego para poner en práctica con regularidad sus procedimientos de respuesta a los eventos y deficiencias que afecten a la carga de trabajo. Incluya a los mismos equipos que se encargarían de gestionar los escenarios de producción. Estos ejercicios ayudan a aplicar medidas para evitar que los eventos de producción afecten a los usuarios. Si practica sus procedimientos de respuesta en condiciones realistas, podrá identificar y abordar cualquier laguna o punto débil antes de que se produzca un suceso real. 

 En los días de juego, se simulan eventos en entornos de producción para probar los sistemas, los procesos y las respuestas de los equipos. El objetivo es poner en práctica las acciones que llevaría a cabo el equipo si se produjera realmente un evento. Estos ejercicios lo ayudan a comprender dónde se pueden efectuar mejoras y a desarrollar la experiencia de la organización a la hora de gestionar eventos y deficiencias. Deben hacerse periódicamente, para que el equipo desarrolle hábitos sobre cómo responder. 

 Los días de juego preparan a los equipos para que puedan abordar los eventos de producción con mayor confianza. Los equipos que tienen mucha experiencia son más capaces de detectar y responder rápidamente a varios escenarios. Esto se traduce en una postura de preparación y resiliencia significativamente mejorada. 

 **Resultado deseado:** organiza los días de juego de resiliencia de forma constante y programada. Estos días de juego se integran armoniosamente en la actividad empresarial. Su organización ha creado una cultura de preparación y, cuando se producen problemas de producción, sus equipos están bien preparados para responder con eficacia, resolver los problemas de manera eficiente y mitigar las repercusiones para los clientes. 

 **Patrones comunes de uso no recomendados:** 
+  Documenta los procedimientos, pero no los llega a poner en práctica. 
+  En los ejercicios de prueba se excluye a los responsables de la toma de decisiones empresariales. 
+  Organiza un día de juego, pero no informa a todas las partes interesadas pertinentes. 
+  Se centra únicamente en los fallos técnicos, pero no incluye a las partes interesadas de la empresa. 
+  No incorpora las lecciones aprendidas de los días de juego en sus procesos de recuperación. 
+  Culpa a los equipos de los fallos o los errores. 

 **Beneficios de establecer esta práctica recomendada:** 
+  Mejorar las habilidades de respuesta: durante los días de juego, los equipos practican sus tareas y ponen a prueba sus mecanismos de comunicación durante los eventos simulados, lo que permite una respuesta más coordinada y eficiente en situaciones de producción. 
+  Identificar y abordar las dependencias: los entornos complejos suelen conllevar dependencias intrincadas entre varios sistemas, servicios y componentes. Los días de juego pueden ayudar a identificar y abordar estas dependencias, y a comprobar que los manuales de procedimientos abordan sus sistemas y servicios críticos debidamente, así como que puedan ampliarse o recuperarse de forma oportuna. 
+  Fomentar una cultura de resiliencia: los días de juego pueden ayudar a cultivar una mentalidad de resiliencia en una organización. Al implicar a equipos multidisciplinarios y a las partes interesadas, estos ejercicios fomentan la concienciación, la colaboración y una comprensión compartida de la importancia de la resiliencia en toda la organización. 
+  Mejorar y adaptarse continuamente: los días de juego practicados con regularidad ayudan a evaluar y adaptar continuamente las estrategias de resiliencia, de modo que sigan siendo relevantes y eficaces aunque cambien las circunstancias. 
+  Aumentar la confianza en el sistema: los días de juego ejecutados correctamente pueden ayudar a generar confianza en la capacidad del sistema para resistir las interrupciones y recuperarse de ellas. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Una vez que haya diseñado e implementado las medidas de resiliencia necesarias, organice un día de juego para comprobar que todo funciona según lo previsto durante la fase de producción. Un día de juego, sobre todo el primero, debe incluir a todos los miembros del equipo, y se debe informar con antelación a todas las partes interesadas y participantes sobre la fecha, la hora y los escenarios simulados. 

 Durante el día de juego, los equipos participantes simulan varios eventos y posibles escenarios de acuerdo con los procedimientos prescritos. Los participantes monitorean y evalúan de cerca el impacto de estos eventos simulados. Si el sistema funciona según lo diseñado, los mecanismos automatizados de detección, escalado y recuperación automática deberían activarse y tener un impacto mínimo o nulo en los usuarios. Si el equipo observa algún impacto negativo, anula la prueba y soluciona los problemas identificados, ya sea mediante medios automatizados o mediante una intervención manual documentada en los manuales aplicables. 

 Para mejorar continuamente la resiliencia, es fundamental documentar e incorporar las lecciones aprendidas. Este proceso es un *ciclo de retroalimentación* que recopila de forma sistemática la información obtenida durante los días de juego y la utiliza para mejorar los sistemas, los procesos y las capacidades de los equipos. 

 Para ayudarlo a reproducir situaciones reales en las que los componentes o servicios del sistema podrían fallar inesperadamente, utilice la simulación de fallos como ejercicio para un día de juego. Los equipos pueden probar la resiliencia y la tolerancia a los fallos de sus sistemas y simular sus procesos de respuesta y recuperación ante incidentes en un entorno controlado. 

 En AWS, los días de juego se pueden llevar a cabo con réplicas de su entorno de producción utilizando la infraestructura como código. Mediante este proceso, puede realizar las pruebas en un entorno seguro que se parece mucho a su entorno de producción. Puede utilizar [AWS Fault Injection Service](https://aws.amazon.com/fis/) para crear diferentes escenarios de error. Use servicios como [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) y [AWS X-Ray](https://aws.amazon.com/xray/) para monitorear el comportamiento del sistema durante los días de juego. Use [AWS Systems Manager](https://aws.amazon.com/systems-manager/) para administrar y ejecutar guías de estrategia, y utilice [AWS Step Functions](https://aws.amazon.com/step-functions/) para organizar los flujos de trabajo recurrentes del día del juego. 

### Pasos para la implementación
<a name="implementation-steps"></a>
+  **Establezca un programa para los días de juego:** desarrolle un programa estructurado que defina la frecuencia, el alcance y los objetivos de los días de juego. Incluya a las principales partes interesadas y a los expertos en la materia en la planificación y ejecución de estos ejercicios. 
+  **Prepare el día de juego:** 

  1.  Identifique los principales servicios críticos para la empresa en los que se centrará el día de juego. Catalogue y mapee las personas, los procesos y las tecnologías que respaldan esos servicios. 

  1.  Establezca la agenda para el día de juego y prepare a los equipos implicados para que participen en el evento. Prepare sus servicios de automatización para simular los escenarios planificados y ejecutar los procesos de recuperación adecuados. Los servicios de AWS, como [AWS Fault Injection Service](https://aws.amazon.com/fis/), [AWS Step Functions](https://aws.amazon.com/step-functions/) y [AWSSystems Manager](https://aws.amazon.com/systems-manager/) pueden ayudarlo a automatizar varios aspectos de los días de juego, como la inyección de errores y el inicio de las acciones de recuperación. 
+  **Ejecute su simulación:** el día de juego, ejecute el escenario planificado. Observe y documente cómo reaccionan las personas, los procesos y las tecnologías ante el evento simulado. 
+  **Realice revisiones después del ejercicio:** después del día de juego, realice una sesión retrospectiva para repasar las lecciones aprendidas. Identifique las áreas de mejora y cualquier acción necesaria para mejorar la resiliencia operativa. Documente sus resultados y realice un seguimiento de los cambios necesarios para mejorar sus estrategias de resiliencia y su preparación para llevarlas a cabo. 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [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) 
+  [REL12-BP04 Pruebas de resiliencia mediante ingeniería del caos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html) 
+  [OPS04-BP01 Identificación de los indicadores clave de rendimiento](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html) 
+  [OPS07-BP03 Uso de manuales de procedimientos para llevar a cabo los procedimientos](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) 
+  [OPS10-BP01 Uso de un proceso para la administración de eventos, incidentes y problemas](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html) 

 **Documentos relacionados:** 
+  [¿Qué es AWS GameDay?](https://aws.amazon.com/gameday/) 

 **Videos relacionados:** 
+  [AWS re:Invent 2023 - Practice like you play: How Amazon scales resilience to new heights](https://www.youtube.com/watch?v=r3J0fEgNCLQ&t=1734s) 

 **Ejemplos relacionados:** 
+  [AWS Workshop - Navigate the storm: Unleashing controlled chaos for resilient systems](https://catalog.us-east-1.prod.workshops.aws/workshops/eb89c4d5-7c9a-40e0-b0bc-1cde2df1cb97) 
+  [Build Your Own Game Day to Support Operational Resilience](https://aws.amazon.com/blogs/architecture/build-your-own-game-day-to-support-operational-resilience/) 

# Planificación de la recuperación de desastres (DR)
<a name="plan-for-disaster-recovery-dr"></a>

 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
<a name="rel_planning_for_recovery_objective_defined_recovery"></a>

 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
<a name="implementation-guidance"></a>

 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. 

<a name="worksheet"></a>![\[Hoja de trabajo\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/worksheet.png)


### Pasos para la implementación
<a name="implementation-steps"></a>

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
<a name="resources"></a>

 **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
<a name="rel_planning_for_recovery_disaster_recovery"></a>

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
<a name="implementation-guidance"></a>

 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
<a name="resources"></a>

 **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
<a name="rel_planning_for_recovery_dr_tested"></a>

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
<a name="implementation-guidance"></a>

 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
<a name="resources"></a>

 **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
<a name="rel_planning_for_recovery_config_drift"></a>

 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
<a name="implementation-guidance"></a>

 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
<a name="implementation-steps"></a>

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
<a name="resources"></a>

 **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
<a name="rel_planning_for_recovery_auto_recovery"></a>

 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
<a name="implementation-guidance"></a>

 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
<a name="implementation-steps"></a>

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
<a name="resources"></a>

 **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)