# Administración de errores
**Topics**
+ [REL 9 ¿Cómo realiza una copia de seguridad de los datos?](w2aac19b9c11b5.md)
+ [REL 10 ¿Cómo usa el aislamiento de errores para proteger su carga de trabajo?](w2aac19b9c11b7.md)
+ [REL 11 ¿Cómo diseña su carga de trabajo para que soporte los errores de los componentes?](w2aac19b9c11b9.md)
+ [REL 12 ¿Cómo pone a prueba la fiabilidad?](w2aac19b9c11c11.md)
+ [REL 13 ¿Cómo planifica la recuperación de desastres (DR)?](w2aac19b9c11c13.md)
# REL 9 ¿Cómo realiza una copia de seguridad de los datos?
Realice una copia de seguridad de los datos, las aplicaciones y la configuración para satisfacer sus requisitos de objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO).
**Topics**
+ [REL09-BP01 Identificar todos los datos de los que se debe hacer una copia de seguridad y crearla o reproducir los datos a partir de los orígenes](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 Proteger y cifrar copias de seguridad](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 Realizar copias de seguridad de los datos automáticamente](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 Realizar una recuperación periódica de los datos para verificar la integridad de la copia de seguridad y los procesos](rel_backing_up_data_periodic_recovery_testing_data.md)
# REL09-BP01 Identificar todos los datos de los que se debe hacer una copia de seguridad y crearla o reproducir los datos a partir de los orígenes
Todos los almacenes de datos de AWS ofrecen capacidades de copia de seguridad. En los servicios como Amazon RDS y Amazon DynamoDB además se pueden hacer copias de seguridad automatizadas, que facilita la recuperación a 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 capacidad de copiar copias de seguridad en otra Región de AWS. AWS Backup es una herramienta que permite centralizar y automatizar la protección de datos entre servicios de AWS.
Amazon S3 puede usarse como destino de 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 realizar copias de seguridad de los datos locales en Nube de AWS con [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) o bien [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). Los buckets de Amazon S3 se pueden usar para almacenar estos datos en AWS. Amazon S3 ofrece varios niveles de almacenamiento, como [Amazon Glacier o S3 Glacier Deep Archive,](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) para reducir el coste del almacenamiento de datos.
Es posible que pueda satisfacer las necesidades de recuperación de datos reproduciendo los datos desde otros orígenes. Por ejemplo, [los nodos de réplicas de Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) o bien [las réplicas de lectura de RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) podrían usarse para reproducir datos si se pierde la principal. En casos en los que orígenes como este puedan usarse para cumplir su [objetivo de punto de recuperación (RPO) y su objetivo de tiempo de recuperación (RTO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html), puede que no necesite una copia de seguridad. Otro ejemplo: si trabaja con Amazon EMR, puede que no sea necesario crear copias de seguridad de sus almacenes de datos HDFS, en la medida en que puede [reproducir los datos en EMR desde 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.
**Resultado deseado:**
Los orígenes de datos se han identificado y clasificado en función del nivel de criticidad. A continuación, establece 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 la pérdida de datos, la estrategia implementada permite la recuperación o reproducción de datos dentro de los RPO y RTO definidos.
**Fase de madurez de la nube:** Foundational
**Patrones de uso no recomendados comunes:**
+ No ser consciente de todos los orígenes de datos para la carga de trabajo y su nivel de criticidad.
+ No realizar copias de seguridad de orígenes de datos críticos.
+ Realizar 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 las copias de seguridad son necesarias e implementar un mecanismo para crear copias de seguridad, o ser capaz de reproducir los datos desde una fuente externa mejora la capacidad de restaurar y recuperar datos durante una interrupción.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
Conozca y use las funciones de copia de seguridad de los servicios y recursos de AWS usados por su carga de trabajo. La mayoría de los servicios de AWS ofrecen capacidades para realizar copias de seguridad de los datos de la carga de trabajo.
**Pasos de implementación:**
1. **Identifique todos los orígenes de datos para la carga de trabajo**. Los datos se pueden almacenar en diversos recursos, como [gestionadas](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 distintos servicios de AWS en los que se almacenan los datos y la capacidad de copia de seguridad que proporcionan estos servicios.
1. **Clasifique los orígenes de datos en función de 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. **Use 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 la creación de copias de seguridad de diferentes orígenes de datos en AWS. La mayoría de estos servicios 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 ver información sobre cómo crear copias de seguridad de datos desde distintos servicios de AWS.
1. **En el caso de los datos que no tengan copia de seguridad, establezca un mecanismo de reproducción de datos**. Puede decidir no crear una copia de seguridad de datos que puedan reproducirse desde otros orígenes 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 coste 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 una 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 de copia 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
**Prácticas recomendadas relacionadas:**
[REL13-BP01 Definir objetivos de recuperación para la inactividad y la pérdida de datos](rel_planning_for_recovery_objective_defined_recovery.md)
[REL13-BP02 Usar estrategias de recuperación definidas para cumplir los objetivos de recuperación](rel_planning_for_recovery_disaster_recovery.md)
**Documentos relacionados:**
+ [¿Qué es AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [¿Qué es AWS DataSync?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [¿Qué es una puerta de enlace de volumen?](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)
+ [Copia de seguridad de Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Copia de seguridad de Amazon FSx para Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [Copia de seguridad y restauración de ElastiCache for Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Crear una instantánea de un clúster de base de datos en Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)
+ [Crear una instantánea de base de datos](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [Crear una regla de EventBridge que se active de acuerdo con una programación](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/)
+ [Exportación de datos de registro a Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Administración del ciclo de vida de los objetos](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [Backup y restauración bajo demanda para DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [Recuperación a un momento dado para DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Trabajo con instantáneas de índices de Amazon OpenSearch Service](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2021: copia de seguridad, recuperación de desastres y protección contra ransomware con AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [Demostración de AWS Backup: copia de seguridad entre cuentas y entre regiones](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: análisis en profundidad de AWS Backup con Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Ejemplos relacionados:**
+ [Laboratorio de Well-Architected: implementación de la replicación bidireccional entre regiones (CRR) de Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
+ [Laboratorio de Well-Architected: probar la copia de seguridad y restauración de los datos](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Laboratorio de Well-Architected: copia de seguridad y restauración con conmutación por recuperación para cargas de trabajo de análisis](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [Laboratorio de Well-Architected: recuperación de desastres, copia de seguridad y restauración](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)
# REL09-BP02 Proteger y cifrar copias de seguridad
Controle y detecte el acceso a las copias de seguridad con autenticación y autorización, como AWS 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 lado del servidor, Amazon S3 acepta sus objetos como datos sin cifrar y después los cifra a medida que se almacenan. Utilizando el cifrado del cliente, su aplicación de 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 utilizando 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 estarán cifradas también. Las copias de seguridad de DynamoDB siempre están cifradas.
**Patrones de uso no recomendados comunes:**
+ 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
**Beneficios de establecer esta práctica recomendada:** Proteger 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 por error.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Use el cifrado en cada uno de sus almacenes de datos. Si los datos de origen están cifrados, la copia de seguridad también estará cifrada.
+ Habilite el cifrado en RDS. Puede configurar el cifrado en reposo usando AWS Key Management Service al crear una instancia de RDS.
+ [Cifrado de recursos de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ Habilite el cifrado en volúmenes de EBS. Puede configurar el cifrado predeterminado o especificar una clave única al crear los volúmenes.
+ [Cifrado de Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ Use el cifrado de Amazon DynamoDB necesario. DynamoDB cifra todos los datos en reposo. Puede utilizar una clave AWS KMS propiedad de AWS o una clave KMS administrada por AWS, especificando una clave que esté almacenada en su cuenta.
+ [Cifrado en reposo de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Administrar las tablas cifradas](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ Cifre los datos almacenados en Amazon EFS. Configure el cifrado cuando cree el sistema de archivos.
+ [Cifrar datos y metadatos en EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ 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.
+ [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)
+ Implemente permisos de privilegios mínimos 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.
+ [Pilar de seguridad: AWS Well-Architected](./wat.pillar.security.en.html)
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: productos que pueden usarse para la copia de seguridad](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Cifrado de Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ [Amazon S3: protección de datos mediante 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 de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Cifrado de recursos de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [Cifrar datos y metadatos en EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [Cifrado de copias de seguridad en AWS](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [Administrar las tablas cifradas](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [Pilar de seguridad: AWS Well-Architected](./wat.pillar.security.en.html)
**Ejemplos relacionados:**
+ [Laboratorio de Well-Architected: Implementación de la replicación bidireccional entre regiones (CRR) de Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 Realizar copias de seguridad de los datos automáticamente
Configure las copias de seguridad para que se realicen 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 realizar 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.
AWS Backup se puede usar para crear copias de seguridad de los datos automatizadas para varios orígenes de datos de AWS. Es posible realizar 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 a un momento dado (PITR) en un punto específico del historial de copias de seguridad. Para otros orígenes de datos de AWS, como los volúmenes 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 ofrecen también capacidades de copia de seguridad nativas. Entre los servicios de AWS que ofrecen copia de seguridad automatizada con recuperación a un momento dado se incluyen [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) —la restauración se puede realizar a un punto temporal específico dentro 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 a un momento dado. El control de versiones de Amazon S3, una vez activado, es automático. [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) se puede utilizar para automatizar la creación, copia 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.
Para disfrutar de 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 local utilizando 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.
**Resultado deseado:**
Un proceso automatizado que crea copias de seguridad de los orígenes de datos a un ritmo establecido.
**Patrones de uso no recomendados comunes:**
+ Realizar 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:** la automatización de las copias de seguridad garantiza que se realicen con regularidad en función del RPO, y emite una alerta en caso contrario.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
1. **Identifique los orígenes de datos** de los que se están haciendo copias de seguridad de forma manual actualmente. Consulte [REL09-BP01 Identificar todos los datos de los que se debe hacer una copia de seguridad y crearla o reproducir los datos a partir de los orígenes](rel_backing_up_data_identified_backups_data.md) para ver una guía sobre esto.
1. **Determine el RPO** para la carga de trabajo. Consulte [REL13-BP01 Definir objetivos de recuperación para la inactividad y la pérdida de datos](rel_planning_for_recovery_objective_defined_recovery.md) para ver una guía sobre esto.
1. **Utilice una solución de copia de seguridad o un servicio administrado automatizados**. AWS Backup es un servicio totalmente administrado que facilita la [centralización y automatización de la protección de datos entre servicios de AWS, en la nube y en el entorno local](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). Los planes de copia de seguridad son una característica de AWS Backup que permite la creación de reglas que definen 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. [Este laboratorio de Well-Architected](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) ofrece orientación práctica sobre cómo crear copias de seguridad automatizadas con AWS Backup. La mayoría de servicios de AWS que almacenan datos ofrecen capacidades de copia de seguridad nativas. Por ejemplo, se puede utilizar RDS para realizar copias de seguridad automatizadas con recuperación a un momento dado (PITR).
1. **Para los orígenes de datos no compatibles** con un servicio administrado o solución de copia de seguridad automatizada, como los orígenes de datos o las colas de mensajes locales, plantéese el uso de 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 AWS Lambda Functions 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 ejecutarla a una frecuencia basada en su RPO (según se establece en el paso 2).
**Nivel de esfuerzo para el plan de implementación:** Bajo
## Recursos
**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)
+ [Crear una regla de EventBridge que se active de acuerdo con una programación](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)
**Vídeos relacionados:**
+ [AWS re:Invent 2019: análisis en profundidad de AWS Backup con Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Ejemplos relacionados:**
+ [Laboratorio de Well-Architected: probar la copia de seguridad y restauración de los datos](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL09-BP04 Realizar una recuperación periódica de los datos para verificar la integridad de la copia de seguridad y los procesos
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.
Con AWS, puede crear un entorno de prueba y restaurar sus copias de seguridad para evaluar a 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 a un momento dado (PITR). Mediante la copia de seguridad continua, puede restaurar su conjunto de datos al estado en el que se encontrara en una fecha y hora específicas.
**Resultado deseado:** los datos de las copias de seguridad se recuperan periódicamente utilizando mecanismos bien definidos para garantizar que la recuperación sea posible dentro del objetivo de tiempo de recuperación (RTO) determinado 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 de uso no recomendados comunes:**
+ Restaurar una copia de seguridad, pero no consultar ni recuperar ningún dato para garantizar que la restauración es 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 ad hoc, sin usar un runbook, o fuera de un procedimiento automatizado.
**Beneficios de establecer esta práctica recomendada:** comprobar la recuperación de las copias de seguridad garantiza que los datos puedan restaurarse cuando sea necesario sin tener que preocuparse por si los datos faltan o están dañados, por si la restauración y la recuperación son o no posibles dentro del RTO para la carga de trabajo y por si la pérdida de datos se ajusta al RPO de la carga de trabajo.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
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 realizarse son la comprobación
de si todos los datos están disponibles, no están dañados, son 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.
1. **Identifique los orígenes de datos** de los que se estén haciendo copias de seguridad y dónde se están almacenando dichas copias. Consulte [REL09-BP01 Identificar todos los datos de los que se debe hacer una copia de seguridad y crearla o reproducir los datos a partir de los orígenes](rel_backing_up_data_identified_backups_data.md) para obtener orientación sobre cómo implementar esto.
1. **Establezca 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. Plantéese 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 RTO y RPO** para restaurar los datos sobre la base de la importancia crítica de los datos. Consulte [REL13-BP01 Definir objetivos de recuperación para la inactividad y la pérdida de datos](rel_planning_for_recovery_objective_defined_recovery.md) para obtener orientación sobre cómo implementar esto.
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 llevar a cabo una evaluación de su 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. **Realice una restauración de prueba** con los procesos establecidos actualmente utilizados en producción para la restauración de datos. Estos procesos dependen de cómo se haya realizado 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 utilizó AWS Elastic Disaster Recovery, puede [lanzar un simulacro de recuperación](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **Valide la recuperación de datos** desde el recurso restaurado (desde el paso anterior) en función de los criterios que estableciera anteriormente para la validación de datos en el paso 2. ¿Los datos restaurados y recuperados contienen el registro/elemento más reciente en el momento de la copia de seguridad? ¿Estos datos se ajustan al RPO de la carga de trabajo?
1. **Mida el tiempo necesario** para la restauración y la recuperación y compárelo con el RTO establecido antes en el paso 3. ¿Este proceso se ajusta al RTO para 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 para el momento de finalización de la validación debería quedar registrada mediante su lógica de validación. Si se utiliza un proceso automatizado, se pueden usar 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 *Empleo*, y estos Trabajos contienen información con marca de tiempo como parte de estos metadatos, que se pueden utilizar para medir el tiempo necesario para la restauración y la recuperación.
1. **Notifique a las partes interesadas** si falla la validación de 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 haga esto, [como en este laboratorio](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/), se pueden usar servicios como Amazon Simple Notification Service (Amazon SNS) para enviar notificaciones push, por ejemplo por correo electrónico o SMS, a los interesados. [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 usarse para [crear tareas como OpsItems con AWS Systems Manager OpsCenter](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, servicios como AWS Lambda o una máquina de estados en AWS Step Functions se pueden usar para automatizar los procesos de restauración y recuperación, y Amazon EventBridge se puede usar para desencadenar este flujo de trabajo de automatización periódicamente como se muestra en el siguiente diagrama de arquitectura. Descubra 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, [este laboratorio de Well-Architected](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) contiene una experiencia práctica sobre una forma de llevar a cabo la automatización de varios de los pasos que aparecen aquí.
![\[Diagrama que muestra un proceso de copia de seguridad y restauración automatizado\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/automated-backup-restore-process.png)
**Nivel de esfuerzo para el plan de implementación:** de moderado a alto, en función de la complejidad de los criterios de validación.
## Recursos
**Documentos relacionados:**
+ [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/)
+ [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)
+ [Crear una regla de EventBridge que se active de acuerdo con una programación](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://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
**Ejemplos relacionados:**
+ [Laboratorio de Well-Architected: probar la copia de seguridad y restauración de los datos](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL 10 ¿Cómo usa el aislamiento de errores para proteger su carga de trabajo?
Los límites aislados de los errores acotan el efecto de un error en una carga de trabajo a un número limitado de componentes. Los componentes fuera del límite no resultan afectados por el error. Mediante el uso de varios límites aislados de error, puede acotar el impacto en su carga de trabajo.
**Topics**
+ [REL10-BP01 Implementar la carga de trabajo en varias ubicaciones](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Seleccionar las ubicaciones adecuadas para el despliegue en varias ubicaciones](rel_fault_isolation_select_location.md)
+ [REL10-BP03 Automatizar la recuperación de los componentes restringidos a una sola ubicación](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 Usar arquitecturas herméticas para limitar el alcance del impacto](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 Implementar la carga de trabajo en varias ubicaciones
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. Estas ubicaciones pueden ser tan diversas como sea necesario.
Uno de los principios fundamentales para el diseño de servicios en AWS es evitar puntos únicos de error en la infraestructura física subyacente. Esto nos motiva a desarrollar software y sistemas que utilizan múltiples zonas de disponibilidad y son resistentes a errores de una sola zona. Del mismo modo, los sistemas están diseñados para resistir los errores de un solo nodo de informática, un solo volumen de almacenamiento o una sola instancia de una base de datos. Cuando se desarrolla un sistema que depende de componentes redundantes, es importante asegurarse de que estos componentes funcionen de forma independiente y, en el caso de las Regiones de AWS, de forma autónoma. Los beneficios que se obtienen de los cálculos teóricos de disponibilidad con componentes redundantes solo son válidos si esto se cumple.
**Zonas de disponibilidad (AZ)**
Las Regiones de AWS tienen varias zonas de disponibilidad diseñadas para ser independientes entre sí. Cada zona de disponibilidad está separada por una distancia física significativa de otras zonas para evitar situaciones de error correlacionadas debido a peligros ambientales como incendios, inundaciones o tornados. Cada zona de disponibilidad también tiene una infraestructura física independiente: conexiones exclusivas para el suministro eléctrico, fuentes de energía de reserva independientes, servicios mecánicos independientes y conectividad de red independiente dentro y fuera de la zona de disponibilidad. Este diseño limita los errores en cualquiera de estos sistemas a la única AZ afectada. Pese a estar separadas geográficamente, las zonas de disponibilidad están situadas en la misma zona regional, lo que permite las redes de alto rendimiento y baja latencia. La totalidad de la Región de AWS (a través de todas las zonas de disponibilidad, que se componen de múltiples centros de datos físicamente independientes) se puede tratar como un único objetivo de despliegue lógico para su carga de trabajo, incluida la capacidad de replicar datos de forma síncrona (por ejemplo, entre bases de datos). De este modo, puede utilizar las zonas de disponibilidad en una configuración activa/activa o activa/en espera.
Las zonas de disponibilidad son independientes y, por lo tanto, la disponibilidad de la carga de trabajo se incrementa cuando esta se diseña para utilizar varias zonas. Algunos servicios de AWS (incluido el plano de datos de instancia Amazon EC2) se despliegan como servicios estrictamente zonales en los que tienen un destino compartido con la zona de disponibilidad en la que se encuentran. Las instancias Amazon EC2 de las demás AZ no se verán afectadas y seguirán funcionando. Del mismo modo, si un error en una zona de disponibilidad provoca el error de una base de datos de Amazon Aurora, es posible que una instancia de Aurora de réplica de lectura en una zona de disponibilidad no afectada se promueva automáticamente a principal. Los servicios de AWS regionales, como Amazon DynamoDB, utilizan internamente varias zonas de disponibilidad en una configuración activa/activa para alcanzar los objetivos de diseño de disponibilidad para ese servicio, sin que sea necesario configurar la ubicación AZ.
![\[Diagrama que muestra la arquitectura de varios niveles desplegada en tres zonas de disponibilidad. Tenga en cuenta que Amazon S3 y Amazon DynamoDB son siempre Multi-AZ automáticamente. El ELB también se despliega en las tres zonas.\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/multi-tier-architecture.png)
Si bien los planos de control de AWS generalmente ofrecen la capacidad de administrar recursos en toda la región (múltiples zonas de disponibilidad), ciertos planos de control (incluidos Amazon EC2 y Amazon EBS) pueden filtrar los resultados en una única zona de disponibilidad. Al hacerlo, la solicitud se procesa solo en la zona de disponibilidad indicada, lo que reduce la exposición a interrupciones en otras zonas de disponibilidad. Este ejemplo de AWS CLI ilustra la obtención de información de instancias Amazon EC2 solo de la zona de disponibilidad us-east-2c:
```
AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```
*Zonas locales de AWS*
Las zonas locales de AWS actúan de forma similar a las zonas de disponibilidad en su Región de AWS correspondiente en el sentido de que pueden seleccionarse como ubicación de recursos de AWS zonales, como subredes e instancias EC2. Lo que las hace especiales es que no están situadas en la Región de AWS asociada, sino cerca de los grandes centros de población, de la industria y de TI, donde no hay ninguna Región de AWS en la actualidad. Sin embargo, siguen reteniendo un gran ancho de banda y una conexión segura entre las cargas de trabajo de la zona local y las que se ejecutan en la Región de AWS. Debe utilizar las zonas locales de AWS para desplegar las cargas de trabajo más cerca de sus usuarios para cumplir los requisitos de baja latencia.
**Red periférica global de Amazon**
La red periférica global de Amazon consta de ubicaciones periféricas en ciudades de todo el mundo. Amazon CloudFront utiliza esta red para entregar contenido a los usuarios finales con una latencia menor. AWS Global Accelerator le permite crear sus puntos de conexión de la carga de trabajo en estas ubicaciones periféricas para proporcionar la incorporación a la red global de AWS cerca de sus usuarios. Amazon API Gateway permite que los puntos de conexión de la API optimizados para la periferia utilicen una distribución de CloudFront para facilitar el acceso de los clientes a través de la ubicación periférica más cercana.
*Regiones de AWS*
Las Regiones de AWS se han diseñado para ser autónomas, por lo que, para utilizar un enfoque multirregión, habría que desplegar copias dedicadas de los servicios en cada región.
Un enfoque multirregión es habitual en las estrategias de *recuperación de desastres* para cumplir los objetivos de recuperación cuando se producen eventos puntuales a gran escala. Consulte [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) para obtener más información sobre estas estrategias. Sin embargo, aquí nos centramos en la *disponibilidad*, cuya finalidad es entregar un objetivo de tiempo de actividad medio a lo largo del tiempo. En el caso de los objetivos de alta disponibilidad, una arquitectura multirregión se diseñará generalmente para ser activa/activa, donde cada copia de servicio (en sus respectivas regiones) está activa (sirviendo solicitudes).
**Recomendación**
Los objetivos de disponibilidad para la mayoría de las cargas de trabajo pueden satisfacerse mediante una estrategia Multi-AZ en una sola Región de AWS. Considere la posibilidad de usar arquitecturas multirregión solo cuando las cargas de trabajo tengan requisitos extremos de disponibilidad, u otros objetivos empresariales, que requieran una arquitectura multirregión.
AWS le proporciona las capacidades para utilizar los servicios entre regiones. Por ejemplo, AWS proporciona una replicación continua y asíncrona de datos mediante la replicación de Amazon Simple Storage Service (Amazon S3), réplicas de lectura de Amazon RDS (incluidas las réplicas de lectura de Aurora) y las tablas globales de Amazon DynamoDB. Con la replicación continua, las versiones de sus datos están disponibles para usarse casi inmediatamente en cada una de sus regiones activas.
Con AWS CloudFormation, puede definir su infraestructura y desplegarla de forma coherente en varias Cuentas de AWS y Regiones de AWS. Y AWS CloudFormation StackSets amplía esta funcionalidad al permitirle crear, actualizar o eliminar pilas de AWS CloudFormation en varias cuentas y regiones con una sola operación. En el caso de los despliegues de instancias Amazon EC2, se utiliza una AMI (imagen de máquina de Amazon) para suministrar información como la configuración del hardware y el software instalado. Puede implementar una canalización del generador de imágenes de Amazon EC2 que cree las ANU que necesita y copiarlas en sus regiones activas. Esto garantiza que estas *AMI doradas* tiene todo lo que necesita para desplegar y escalar su carga de trabajo en cada nueva región.
Para enrutar el tráfico, tanto Amazon Route 53 como AWS Global Accelerator permiten la definición de políticas que determinen qué usuarios van a cada punto de conexión regional activo. Con Global Accelerator se establece un regulador de tráfico para controlar el porcentaje de tráfico que se dirige a cada punto de conexión de la aplicación. Route 53 es compatible con este enfoque porcentual y también con varias políticas disponibles, incluidas las basadas en la geoproximidad y la latencia. Global Accelerator aprovecha automáticamente la amplia red de servidores periféricos de AWS, para integrar el tráfico en la estructura de red de AWS de lo antes posible, lo que se traduce en menores latencias de solicitudes.
El funcionamiento de todas estas capacidades permite preservar la autonomía de cada región. Existen muy pocas excepciones a este enfoque, incluidos nuestros servicios que proporcionan entrega periférica global (como Amazon CloudFront y Amazon Route 53), junto con el plano de control para el servicio AWS Identity and Access Management (IAM). La gran mayoría de los servicios funcionan completamente en una sola región.
**Centro de datos local**
En el caso de las cargas de trabajo que se ejecutan en un centro de datos local, diseñe una experiencia híbrida cuando sea posible. AWS Direct Connect proporciona una conexión de red dedicada desde su entorno local a AWS, lo que le permite la ejecución en ambos.
Otra opción es ejecutar la infraestructura y los servicios de AWS localmente mediante AWS Outposts. AWS Outposts es un servicio completamente administrado que extiende la infraestructura de AWS, los servicios de AWS, las API y las herramientas a su centro de datos. La misma infraestructura de hardware que se utiliza en la Nube de AWS se instala en su centro de datos. AWS Outposts se conectan a las Región de AWS. A continuación, puede usar AWS Outposts para respaldar las cargas de trabajo que tengan requisitos de baja latencia o de procesamiento local de datos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Use varias zonas de disponibilidad y Regiones de AWS. 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. Estas ubicaciones pueden ser tan diversas como sea necesario.
+ Los servicios regionales se implementan en las zonas de disponibilidad.
+ Esto incluye Amazon S3, Amazon DynamoDB y AWS Lambda (cuando no está conectado a una VPC)
+ Implemente su contenedor, instancia y cargas de trabajo basadas en funciones en múltiples zonas de disponibilidad. Use los almacenes de datos multizona, incluidas las memorias caché. Use las características de EC2 Auto Scaling, ubicación de tareas de ECS, configuración de la función AWS Lambda cuando se ejecute en su VPC y clústeres ElastiCache.
+ Utilice subredes en zonas de disponibilidad distintas cuando implemente grupos de Auto Scaling.
+ [Ejemplo: distribución de instancias en zonas de disponibilidad](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Estrategias de asignación de tareas de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Configurar una función AWS Lambda para obtener acceso a los recursos en una Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ [Elección de regiones y zonas de disponibilidad](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Utilice subredes en zonas de disponibilidad distintas cuando implemente grupos de Auto Scaling.
+ [Ejemplo: distribución de instancias en zonas de disponibilidad](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ Utilice los parámetros de colocación de tareas de ECS, especificando grupos de subred de base de datos
+ [Estrategias de asignación de tareas de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ Utilice subredes en múltiples zonas de disponibilidad cuando configure una función para que se ejecute en su VPC.
+ [Configurar una función AWS Lambda para obtener acceso a los recursos en una Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ Utilice múltiples zonas de disponibilidad con clústeres ElastiCache.
+ [Elección de regiones y zonas de disponibilidad](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Si la carga de trabajo se debe desplegar en varias regiones, elija una estrategia multirregión. La mayoría de los requisitos de fiabilidad se pueden satisfacer con una sola Región de AWS que use una estrategia de varias zonas de disponibilidad. Use una estrategia multirregión cuando sea necesario para satisfacer las necesidades del negocio.
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Patrones de arquitectura para aplicaciones activas-activas en varias regiones) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ Contar con otra Región de AWS puede añadir otra capa de seguridad en cuanto a la disponibilidad de los datos.
+ Algunas cargas de trabajo tienen requisitos normativos que exigen una estrategia multirregión.
+ Evalúe AWS Outposts para su carga de trabajo. Si su carga de trabajo requiere baja latencia en el centro de datos local o si tiene requisitos de procesamiento de datos locales, A continuación, ejecute la infraestructura de AWS y los servicios locales con AWS Outposts.
+ [¿Qué es AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
+ Determine si las zonas locales de AWS le ayudan a prestar servicio a sus usuarios. Si tiene requisitos de baja latencia, compruebe si las zonas locales de AWS están cerca de sus usuarios. En caso afirmativo, úselas para implementar las cargas de trabajo más cerca de esos usuarios.
+ [Preguntas frecuentes sobre las zonas locales de AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
## Recursos
**Documentos relacionados:**
+ [Infraestructura global de AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [Preguntas frecuentes sobre las zonas locales de AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Estrategias de asignación de tareas de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Elección de regiones y zonas de disponibilidad](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ [Ejemplo: distribución de instancias en zonas de disponibilidad](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Tablas globales: replicación multirregión con DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Uso de las bases de datos globales de Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Serie de blog Creating a Multi-Region Application with AWS Services blog series (Creación de una aplicación multirregión con servicios de AWS)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [¿Qué es AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Patrones de arquitectura para aplicaciones activas-activas en varias regiones) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure (Innovación y funcionamiento de la infraestructura de red global de AWS) (NET339)](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 Seleccionar las ubicaciones adecuadas para el despliegue en varias ubicaciones
## Resultado deseado
Para obtener una alta disponibilidad, despliegue siempre (cuando sea posible) sus componentes de carga de trabajo en varias zonas de disponibilidad (AZ), como se muestra en la figura 10. En el caso de cargas de trabajo con requisitos de resiliencia extremos, evalúe cuidadosamente las opciones de una arquitectura multirregión.
![\[Diagrama que muestra un despliegue de base de datos multi-AZ resiliente con copia de seguridad en otra región de AWS\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/multi-az-architecture.png)
## Patrones de uso no recomendados comunes
+ Elegir el diseño de una arquitectura multirregión cuando una arquitectura multi-AZ satisfaría los requisitos.
+ No tener en cuenta las dependencias entre los componentes de la aplicación si los requisitos de resiliencia y multiubicación difieren entre esos componentes.
## Beneficios de establecer esta práctica recomendada
Para obtener resiliencia, debe utilizar un enfoque que cree capas de defensa. Una capa protege de las interrupciones más pequeñas y comunes 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 los desastres naturales generalizados y las interrupciones en el nivel de la región. Esta segunda capa implica la arquitectura de su aplicación para que abarque múltiples Regiones de AWS.
+ La diferencia entre una disponibilidad del 99,5 % y del 99,99 % es de más de 3,5 horas al mes. La disponibilidad prevista de una carga de trabajo solo puede alcanzar los «cuatro nueves» si se encuentra en varias AZ.
+ Al ejecutar su carga de trabajo en varias AZ, puede aislar las interrupciones de energía eléctrica, refrigeración y redes, y la mayoría de los desastres naturales como incendios e inundaciones.
+ La implementación de una estrategia multirregión para su carga de trabajo le ayuda a protegerla de desastres naturales generalizados 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 multirregión puede ser significativamente complejo y no suele ser necesario para la mayoría de las cargas de trabajo.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
En el caso de un evento de desastre provocado por la interrupción o pérdida parcial de una zona de disponibilidad, la implementación de una carga de trabajo con alta disponibilidad en varias zonas de disponibilidad en una sola Región de AWS contribuye a mitigar los desastres naturales o técnicos. Cada Región de AWS consta de varias zonas de disponibilidad, cada una aislada de los errores de las demás zonas y separadas por una distancia significativa. Sin embargo, en el caso de un evento de desastre que implique el riesgo de perder varios componentes de zona de disponibilidad que están alejados entre sí, debe implementar opciones de recuperación de desastres para mitigar los errores de alcance regional. Para las cargas de trabajo que requieren una resiliencia extrema (infraestructuras críticas, aplicaciones relacionadas con la sanidad, infraestructuras de sistemas financieros, etc.), puede ser necesaria una estrategia multirregión.
## Pasos de implementación
1. Evalúe su carga de trabajo y determine si las necesidades de resiliencia se pueden satisface con un enfoque multi-AZ (una sola Región de AWS) o si requieren un enfoque multirregión. La implementación de una arquitectura de multirregión para satisfacer estos requisitos supondrá una complejidad adicional, por lo que deberá considerar detenidamente su caso de uso y sus requisitos. Los requisitos de resiliencia se pueden cumplir casi siempre con una sola Región de AWS. Tenga en cuenta los siguientes requisitos posibles a la hora de determinar si necesita utilizar varias regiones:
1. **Recuperación de desastres (DR)**: en el caso de un evento de desastre provocado por la interrupción o pérdida parcial de una zona de disponibilidad, la implementación de una carga de trabajo con alta disponibilidad en varias zonas de disponibilidad en una sola Región de AWS contribuye a mitigar los desastres naturales o técnicos. En el caso de un evento de desastre que implique el riesgo de perder varios componentes de zona de disponibilidad que están alejados entre sí, debe implementar opciones de recuperación de desastres en varias regiones para mitigar los desastres naturales o los errores técnicos de alcance regional.
1. **Alta disponibilidad**: se puede utilizar una arquitectura de multirregión (mediante varias AZ en cada región) para lograr una disponibilidad superior a cuatro nueves (> 99,99 %).
1. **Localización de pilas**: al desplegar una carga de trabajo para una audiencia global, puede desplegar pilas localizadas en diferentes Regiones de AWS para atender a las audiencias de esas regiones. La localización puede incluir el idioma, la moneda y los tipos de datos almacenados.
1. **Proximidad a los usuarios:** al desplegar una carga de trabajo para una audiencia global, puede reducir la latencia si despliega las pilas en Regiones de AWS cerca de donde están los usuarios finales.
1. **Residencia de los datos**: algunas cargas de trabajo están sujetas a requisitos de residencia de datos, en los que los datos de ciertos usuarios deben permanecer dentro de las fronteras de un país específico. En función de la normativa en cuestión, puede optar por desplegar una pila completa, o solo los datos, en la Región de AWS en esas fronteras.
1. A continuación, se presentan algunos ejemplos de la funcionalidad multi-AZ proporcionada por los servicios de AWS:
1. Para proteger las cargas de trabajo que utilizan EC2 o ECS, despliegue un equilibrador de carga elástico ante los recursos de computación. Elastic Load Balancing proporciona la solución para detectar las instancias en zonas con estado incorrecto y enrutar el tráfico a las que lo tienen correcto.
1. [Introducción a Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html)
1. [Introducción a los equilibradores de carga de red](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html)
1. En el caso de las instancias EC2 que ejecutan software estándar comercial y que no admiten el equilibrio de carga, puede conseguir una forma de tolerancia a errores mediante la implementación de una metodología de recuperación de desastres multi-AZ.
1. [REL13-BP02 Usar estrategias de recuperación definidas para cumplir los objetivos de recuperación](rel_planning_for_recovery_disaster_recovery.md)
1. Para las tareas de Amazon ECS, despliegue su servicio de forma homogénea en tres zonas de disponibilidad para lograr un equilibrio entre la disponibilidad y el coste.
1. [Amazon ECS availability best practices \$1 Containers (Prácticas recomendadas de disponibilidad de Amazon ECS \$1 Contenedores](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/)
1. En el caso de Aurora Amazon RDS, puede elegir Multi-AZ como una opción de configuración. En caso de error de la instancia de la base de datos principal, Amazon RDS promociona automáticamente una base de datos en espera para recibir el tráfico en otra zona de disponibilidad. También se pueden crear réplicas de lectura multirregión para mejorar la resiliencia.
1. [Despliegues multi-AZ de Amazon RDS](https://aws.amazon.com/rds/features/multi-az/)
1. [Creación de una réplica de lectura en una Región de AWS diferente](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html)
1. A continuación, se presentan algunos ejemplos de la funcionalidad multirregión proporcionada por los servicios de AWS:
1. Para las cargas de trabajo de Amazon S3, en las que la disponibilidad multi-AZ la proporciona automáticamente el servicio, considere la posibilidad de utilizar puntos de acceso multirregión si se necesita un despliegue multirregión.
1. [Puntos de acceso multirregión en Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)
1. En el caso de las tablas de DynamoDB, en las que el servicio proporciona automáticamente la disponibilidad multi-AZ, puede convertir fácilmente las tablas existentes en tablas globales para aprovechar las ventajas de múltiples regiones.
1. [Convert Your Single-Region Amazon DynamoDB Tables to Global Tables (Convierta sus tablas de Amazon DynamoDB de una sola región en tablas globales)](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/)
1. Si su carga de trabajo está encabezada por Application Load Balancers o equilibradores de carga de red, use AWS Global Accelerator para mejorar la disponibilidad de su aplicación mediante el direccionamiento del tráfico a varias regiones que contengan puntos de conexión con el estado correcto.
1. [Endpoints for standard accelerators in AWS Global Accelerator - AWS Global Accelerator (Puntos de conexión para aceleradores estándar en AWS Global Accelerator - AWS Global Accelerator) (amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html)
1. En el caso de las aplicaciones que utilizan AWS EventBridge, considere la posibilidad de utilizar buses entre regiones para reenviar los eventos a otras Regiones que seleccione.
1. [Sending and receiving Amazon EventBridge events between Regiones de AWS (Envío y recepción de eventos de Amazon EventBridge entre Regiones de AWS)](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
1. En el caso de las bases de datos de Amazon Aurora, considere de usar bases de datos globales de Aurora, que abarcan varias regiones de AWS. Los clústeres existentes pueden modificarse para agregar también nuevas regiones.
1. [Introducción a las bases de datos globales de Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html)
1. Si su carga de trabajo incluye claves de cifrado de AWS Key Management Service (AWS KMS), considere si las claves multirregión son adecuadas para su aplicación.
1. [Claves multirregión en AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
1. Para conocer otras características de servicios de AWS, consulte esta serie de blog en [Serie Creating a Multi-Region Application with AWS Services blog series (Creación de una aplicación multirregión con servicios de AWS)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
**Nivel de esfuerzo para el plan de implementación: **De moderado a alto
## Recursos
**Documentos relacionados:**
+ [Serie Creating a Multi-Region Application with AWS Services blog series (Creación de una aplicación multirregión con servicios de AWS)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active (Arquitectura de recuperación de desastres (DR) en AWS, parte IV: activa-activa multisitio)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)
+ [Infraestructura global de AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [Preguntas frecuentes sobre las zonas locales de AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud (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/)
+ [La recuperación de desastres es diferente en la nube](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html)
+ [Tablas globales: replicación multirregión con DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Patrones de arquitectura para aplicaciones activas-activas en varias regiones) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Auth0: arquitectura de alta disponibilidad en varias regiones que se amplía a más de 1500 millones de inicios de sesión en un mes con conmutación por error automatizada](https://www.youtube.com/watch?v=vGywoYc_sA8)
**Ejemplos relacionados:**
+ [Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud (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/)
+ [DTCC consigue un nivel de resiliencia mayor del que podría obtener localmente](https://aws.amazon.com/solutions/case-studies/DTCC/)
+ [Expedia Group usa una arquitectura de varias regiones y varias zonas de disponibilidad con un servicio DNS propio para agregar resiliencia a las aplicaciones](https://aws.amazon.com/solutions/case-studies/expedia/)
+ [Uber: recuperación de desastres para Kafka en varias regiones](https://eng.uber.com/kafka/)
+ [Netflix: estrategia activa-activa para la resiliencia multirregional](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b)
+ [Cómo creamos Data Residency for Atlassian Cloud](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud)
+ [Intuit TurboTax se ejecuta en dos regiones](https://www.youtube.com/watch?v=286XyWx5xdQ)
# REL10-BP03 Automatizar la recuperación de los componentes restringidos a una sola ubicación
Si los componentes de la carga de trabajo solo se pueden ejecutar en una zona de disponibilidad o en un centro de datos local, debe implementar la capacidad de volver a crear la carga de trabajo de acuerdo con los objetivos de recuperación definidos.
Si la práctica recomendada de desplegar 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, reimplementar las aplicaciones y recrear los datos necesarios para estos casos.
Por ejemplo, Amazon EMR lanza todos los nodos para un clúster determinado en la misma zona de disponibilidad, ya que 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 desplegar el clúster y sus datos. Además, para Amazon EMR, debería aprovisionar la redundancia de formas diferentes al uso de Multi-AZ. Puede aprovisionar [diferentes nodos](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). Con [el sistema de archivos EMR (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html), los datos en EMR se pueden almacenar en Amazon S3, lo que a su vez puede replicarse entre varias zonas de disponibilidad o Regiones de AWS.
De modo similar, en el caso de Amazon Redshift, aprovisiona de forma predeterminada el clúster 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.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ 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 Auto Scaling 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.
+ [¿Qué es EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Escalado automático del servicio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ Los datos de usuario de la configuración 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 EC2 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.
+ [Recupere la instancia.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ 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 EC2 o los eventos de ECS para automatizar la autorrecuperación cuando no se pueda utilizar el escalado automático ni la recuperación de EC2.
+ [Enlaces de ciclo de vida de EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Eventos de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ Utilice los eventos para invocar la automatización que reparará su componente de acuerdo con la lógica de proceso que necesita.
## Recursos
**Documentos relacionados:**
+ [Eventos de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [Enlaces de ciclo de vida de EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Recupere la instancia.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Escalado automático del servicio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [¿Qué es EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL10-BP04 Usar arquitecturas herméticas para limitar el alcance del impacto
Al igual que las cubiertas de un barco, este patrón garantiza que los errores estén contenidos en un pequeño subconjunto de solicitudes o usuarios para limitar el número de solicitudes con errores y que la mayoría pueda continuar sin producir error. Las cubiertas de los datos se denominan a menudo particiones y las de los servicios, celdas.
En una *arquitectura basada en celdas*, cada celda es una instancia completa e independiente del servicio y tiene un tamaño máximo fijo. Cuando aumenta la carga, aumentan también las cargas de trabajo con más celdas. En el tráfico entrante, se usa una clave de partición para determinar la celda que procesará la solicitud. Cualquier error está contenido en la celda en la que se produce, con lo que se limita el número de solicitudes con error y las demás celdas pueden continuar funcionando sin errores. Es importante identificar la clave de partición adecuada para reducir al mínimo las interacciones entre celdas y evitar tener que recurrir a servicios de asignación complejos en cada solicitud. Los servicios que requieren asignación compleja terminan trasladando el problema a los servicios de asignación, mientras que los servicios que requieren interacciones entre celdas crean dependencias entre ellas (y, por lo tanto, reducen las supuestas mejoras en la disponibilidad de hacerlo).
![\[Diagrama que muestra una arquitectura basada en celdas\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
En esta publicación de blog de AWS, Colm MacCarthaigh explica cómo utiliza Amazon Route 53 el concepto de [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) para aislar las solicitudes de los clientes en particiones. En este caso, una partición consiste en dos o más celdas. En función de la clave de partición, el tráfico procedente de un cliente (o de recursos, o de lo que quiera aislar) se enruta a su partición asignada. En el caso de ocho celdas con dos celdas por partición, y si los clientes están divididos entre las cuatro particiones, el 25 % de los clientes experimentaría un impacto en caso de que hubiese un problema.
![\[Diagrama que muestra un servicio dividido en particiones tradicionales\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
Con la partición aleatoria, crea particiones virtuales de dos celdas cada una y asigna a sus clientes a una de esas particiones virtuales. Cuando ocurre un problema, puede seguir perdiendo una cuarta parte de ese servicio, pero la forma en que se asignan los clientes o los recursos supone que el ámbito del impacto con la partición aleatoria es considerablemente menor al 25 %. Con ocho celdas, hay 28 combinaciones únicas de dos celdas, lo que significa que hay 28 particiones aleatorias posibles (particiones virtuales). Si tiene cientos o miles de clientes y asigna cada cliente a una partición aleatoria, el ámbito del impacto debido a un problema es solamente de 1/28. Esto es siete veces mejor que la partición ordinaria.
![\[Diagrama que muestra un servicio dividido en particiones aleatorias.\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
Una partición se puede usar para servidores, colas u otros recursos además de las celdas.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Use arquitecturas herméticas. Al igual que las cubiertas de un barco, este patrón garantiza que los errores estén contenidos en un pequeño subconjunto de solicitudes o usuarios para limitar el número de solicitudes con errores y que la mayoría pueda continuar sin producir error. Las cubiertas de los datos se denominan a menudo particiones y las de los servicios, celdas.
+ [Laboratorio de Well-Architected: aislamiento de errores con particionamiento aleatorio](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [Particionamiento aleatorio: AWS re:Invent 2019: Presentación de la Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: cómo minimiza AWS el radio de alcance de los errores (ARC338)](https://youtu.be/swQbA4zub20)
+ Evalúe la arquitectura basada en celdas de la carga de trabajo. En una arquitectura basada en celdas, cada celda es una instancia completa e independiente del servicio y tiene un tamaño máximo fijo. Cuando aumenta la carga, aumentan también las cargas de trabajo con más celdas. En el tráfico entrante, se usa una clave de partición para determinar la celda que procesará la solicitud. Cualquier error está contenido en la celda en la que se produce, con lo que se limita el número de solicitudes con error y las demás celdas pueden continuar funcionando sin errores. Es importante identificar la clave de partición adecuada para reducir al mínimo las interacciones entre celdas y evitar tener que recurrir a servicios de asignación complejos en cada solicitud. Los servicios que requieren asignación compleja terminan trasladando el problema a los servicios de asignación, mientras que los servicios que requieren interacciones entre celdas reducen la autonomía de estas celdas (y, por lo tanto, las supuestas mejoras en la disponibilidad de hacerlo).
+ En su entrada de blog de AWS, Colm MacCarthaigh explica cómo usa Amazon Route 53 el concepto de particionamiento aleatorio para aislar las solicitudes de los clientes en particiones.
+ [Particionamiento aleatorio: aislamiento de errores masivo y mágico](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## Recursos
**Documentos relacionados:**
+ [Particionamiento aleatorio: aislamiento de errores masivo y mágico](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [La Amazon Builders' Library: Aislamiento de cargas de trabajo con particionamiento aleatorio](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: cómo minimiza AWS el radio de alcance de los errores (ARC338)](https://youtu.be/swQbA4zub20)
+ [Particionamiento aleatorio: AWS re:Invent 2019: presentación de la Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**Ejemplos relacionados:**
+ [Laboratorio de Well-Architected: aislamiento de errores con particionamiento aleatorio](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
# REL 11 ¿Cómo diseña su carga de trabajo para que soporte los errores de los componentes?
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 Supervisar todos los componentes de la carga de trabajo para detectar errores](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Conmutar por error a recursos en estado correcto](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Automatizar la reparación en todas las capas](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Confiar en el plano de datos y no en el plano de control durante la recuperación](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Usar la estabilidad estática para evitar el comportamiento bimodal](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Enviar notificaciones cuando los eventos afecten a la disponibilidad](rel_withstand_component_failures_notifications_sent_system.md)
# REL11-BP01 Supervisar todos los componentes de la carga de trabajo para detectar errores
Supervise continuamente el estado de las cargas de trabajo para que usted y los sistemas automatizados sepan cuándo se produce una degradación o un error 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 de ofrecer valor empresarial, de modo que los indicadores clave de rendimiento (KPI) que midan esto tengan que formar parte de su estrategia de detección y corrección.
**Patrones de uso no recomendados comunes:**
+ 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 supervisa activamente la capa de la carga de trabajo orientada 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.
**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
+ Determine el intervalo de recopilación de sus componentes en función de sus objetivos de recuperación.
+ Su intervalo de supervisión dependerá 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.
+ Determine si es necesaria la supervisión detallada de las instancias de EC2 y Auto Scaling. 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.
+ [Habilitar o deshabilitar la supervisión detallada de su instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Supervise los grupos de escalado automático y las instancias con Amazon CloudWatch.](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ Determine si se necesita la supervisión mejorada 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 de una instancia de RDS.
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ Cree métricas personalizadas para medir los indicadores clave de rendimiento (KPI) del negocio. Las cargas de trabajo implementan funciones empresariales clave. Estas funciones deben usarse como KPI para ayudar a identificar cuándo se produce un problema indirecto.
+ [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Supervise la experiencia del usuario para detectar errores mediante valores controlados de usuario. Las pruebas de transacciones sintéticas (denominadas pruebas de valores controlados, que no deben confundirse con las implementaciones de valores controlados) 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.
+ [Amazon CloudWatch Synthetics le permite crear pruebas de valores controlados de usuario.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ Cree métricas personalizadas que controlen la experiencia del usuario. Si puede instrumentar la experiencia del cliente, puede determinar cuándo se degrada la experiencia del cliente.
+ [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Defina alarmas 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 se pueden mostrar visualmente en paneles, pueden enviar alertas a través de Amazon SNS o correo electrónico y funcionan con el escalado automático para escalar o desescalar verticalmente los recursos de una carga de trabajo.
+ [Uso de alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ Cree paneles 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.
+ [Uso de paneles de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## Recursos
**Documentos relacionados:**
+ [Amazon CloudWatch Synthetics le permite crear pruebas de valores controlados de usuario.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Habilitar o deshabilitar la supervisión detallada de su instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Supervise los grupos de escalado automático y las instancias con 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 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)
**Ejemplos relacionados:**
+ [Laboratorio de Well-Architected: Nivel 300: Implementación de comprobaciones de estado y administración de dependencias para mejorar la fiabilidad](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 Conmutar por error a recursos en estado correcto
Asegúrese de que, si se produce un error en un recurso, los recursos en buen estado puedan seguir atendiendo las solicitudes. Para errores de ubicación (como zonas de disponibilidad o Región de AWS), asegúrese de que dispone de sistemas para conmutar por error a recursos en buen estado en ubicaciones sin problemas.
Los servicios de AWS, como Elastic Load Balancing y AWS Auto Scaling, 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 EC2) o el deterioro de una zona de disponibilidad puede mitigarse si se desplaza el tráfico a los recursos restantes con estado correcto. Para las cargas de trabajo multirregión, esto es más complicado. Por ejemplo, las réplicas de lectura entre regiones le permiten desplegar los datos en varias Regiones de AWS, pero aun así debe promocionar la réplica de lectura a una réplica principal y dirigir el tráfico a ella si se produce una conmutación por error. Amazon Route 53 y AWS Global Accelerator pueden ayudar a enrutar el tráfico a través de Regiones de AWS.
Si su carga de trabajo usa servicios de AWS como Amazon S3 o Amazon DynamoDB, estos se implementan automáticamente en varias zonas de disponibilidad. En caso de error, el plano de control de AWS dirige automáticamente el tráfico a ubicaciones con estado correcto. Los datos se almacenan de forma redundante en varias zonas de disponibilidad y siguen estando disponibles. En Amazon RDS, debe elegir Multi-AZ como opción de configuración para que, en caso de error, AWS dirija automáticamente el tráfico a una instancia con estado correcto. Para las instancias Amazon EC2, las tareas de Amazon ECS o los pods de Amazon EKS, elija las zonas de disponibilidad en las que se realizará el despliegue. Elastic Load Balancing proporciona la solución para detectar las instancias en las zonas que no tienen un estado correcto y enrutar el tráfico a las que sí lo tienen. Elastic Load Balancing incluso puede enrutar el tráfico a los componentes de su centro de datos local.
Para los enfoques multirregión (que también pueden incluir centros de datos locales), Amazon Route 53 proporciona una forma de definir dominios de Internet y asignar políticas de enrutamiento, que pueden incluir comprobaciones de estado para garantizar que el tráfico se dirige a regiones con estado correcto. Por su lado, AWS Global Accelerator proporciona direcciones IP estáticas que actúan como un punto de entrada fijo a la aplicación y dirige el tráfico a puntos de conexión de las Regiones de AWS de su elección mediante la red global de AWS en lugar de Internet para proporcionar un mejor rendimiento y mayor fiabilidad.
AWS aborda el diseño de nuestros servicios teniendo en cuenta la recuperación de errores. 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 almacenan de forma duradera en múltiples réplicas en una región. Estos servicios y recursos incluyen Amazon Aurora, instancias de base de datos Multi-AZ de Amazon Relational Database Service (Amazon RDS), Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service (Amazon SQS) y Amazon Elastic File System (Amazon EFS). Se han diseñado para utilizar el aislamiento basado en celdas y utilizar 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.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Conmute por error a recursos en estado correcto. Asegúrese de que, si se produce un error en un recurso, los recursos en buen estado puedan seguir atendiendo las solicitudes. Para errores de ubicación (como zonas de disponibilidad o Región de AWS), asegúrese de que dispone de sistemas para conmutar por error a recursos en estado correcto en ubicaciones sin problemas.
+ Si su carga de trabajo usa servicios de AWS como Amazon S3 o Amazon DynamoDB, estos se implementan automáticamente en varias zonas de disponibilidad. En caso de error, el plano de control de AWS dirige automáticamente el tráfico a ubicaciones con estado correcto.
+ En Amazon RDS, debe elegir Multi-AZ como opción de configuración para que, en caso de error, AWS dirija automáticamente el tráfico a una instancia con estado correcto.
+ [Alta disponibilidad (Multi-AZ) de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Para las instancias Amazon EC2 o las tareas de Amazon ECS, elija las zonas de disponibilidad en las que se realizará el despliegue. Elastic Load Balancing proporciona la solución para detectar las instancias en las zonas que no tienen un estado correcto y enrutar el tráfico a las que sí lo tienen. Elastic Load Balancing incluso puede enrutar el tráfico a los componentes de su centro de datos local.
+ Para los enfoques multirregión (que podrían incluir también centros de datos locales), asegúrese de que los datos y recursos de ubicaciones en buen estado puedan seguir atendiendo las solicitudes.
+ Por ejemplo, las réplicas de lectura entre regiones le permiten desplegar los datos en varias Regiones de AWS, pero aun así debe promocionar la réplica de lectura a una réplica maestra y dirigir el tráfico a ella si se produce un error de ubicación principal.
+ [Información general de las réplicas de lectura de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ Amazon Route 53 proporciona una forma de definir dominios de Internet y asignar políticas de enrutamiento, que pueden incluir comprobaciones de estado para garantizar que el tráfico se dirige a regiones en estado correcto. Por su lado, AWS Global Accelerator proporciona direcciones IP estáticas que actúan como un punto de entrada fijo a la aplicación y dirige el tráfico a puntos de conexión de las Regiones de AWS de su elección mediante la red global de AWS en lugar del Internet público para proporcionar un mejor rendimiento y mayor fiabilidad.
+ [Amazon Route 53: selección de una política de enrutamiento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [¿Qué es AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## Recursos
**Documentos relacionados:**
+ [APN Partner: 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)
+ [AWS OpsWorks: uso de la autorreparación para reemplazar instancias en estado de error](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53: selección de una política de enrutamiento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Alta disponibilidad (Multi-AZ) de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Información general de las réplicas de lectura de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Estrategias de asignación de tareas de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Creating Kubernetes Auto Scaling Groups for Multiple Availability Zones (Creación de grupos de escalado automático de Kubernetes para varias zonas de disponibilidad)](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [¿Qué es AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**Ejemplos relacionados:**
+ [Laboratorio de Well-Architected: Nivel 300: Implementación de comprobaciones de estado y administración de dependencias para mejorar la fiabilidad](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 Automatizar la reparación en todas las capas
Cuando se detecte un error, utilice las funciones automatizadas para tomar medidas correctivas.
*La capacidad de reiniciar* es una herramienta importante para corregir errores. Como ya hablamos anteriormente en relación con los sistemas distribuidos, una práctica recomendada es hacer que los servicios no tengan estado cuando sea posible. Esto evita la pérdida de datos o disponibilidad tras el reinicio. En la nube, puede (y generalmente debería) sustituir todo el recurso (por ejemplo, la instancia de EC2 o la función Lambda) 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. En lugar de construir nuevos mecanismos para encapsular, identificar y corregir cada uno de los distintos tipos de errores, asigne muchas categorías de errores diferentes a la misma estrategia de recuperación. Una instancia podría fallar debido a un error de hardware, un error del sistema operativo, una filtración en la memoria u otras causas. En lugar de aportar un remedio personalizado para cada situación, trátelas como si se tratase de errores de instancia. Finalice la instancia y permita que AWS Auto Scaling la sustituya. Posteriormente, lleve a cabo el análisis del recurso fallido fuera de banda.
Otro ejemplo es la capacidad de reiniciar una solicitud 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 informática orientada a la recuperación y en las arquitecturas de clústeres de alta disponibilidad.
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 de los eventos, se puede desencadenar AWS Lambda, AWS, Systems Manager Automation u otros destinos para ejecutar lógica de reparación personalizada en su carga de trabajo.
Amazon EC2 Auto Scaling se puede configurar para comprobar el estado de la instancia de EC2. Si la instancia está en un estado que no sea el de ejecución, o si el estado del sistema se ve impedido, Amazon EC2 Auto Scaling considera que la instancia no está en buen estado y lanza una instancia de sustitución. Con AWS OpsWorks, puede configurar la autorreparación de las instancias de EC2 en el nivel de la capa de Ops Works.
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 en lugar de intentar obtener varios recursos nuevos a la vez.
**Patrones de uso no recomendados comunes:**
+ Desplegar 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.
**Beneficios de establecer esta práctica recomendada:** La reparación automatizada, aunque la carga de trabajo solo esté implementada en una ubicación en un momento dado, reducirá el tiempo medio de recuperación y garantizará la disponibilidad de la carga de trabajo.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Use grupos de escalado automático para desplegar niveles en una carga de trabajo. El escalado automático puede realizar una autorreparación de aplicaciones sin estado, y añadir y eliminar capacidad.
+ [Cómo funciona AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Implemente la recuperación automática en instancias de EC2 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 Amazon EBS y los puntos de montaje en Elastic File Systems o File Systems para Lustre y Windows.
+ [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)
+ [¿Qué es Amazon FSx para Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [¿Qué es Amazon FSx para Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ Con AWS OpsWorks, puede configurar la autorreparación de las instancias de EC2 en el nivel de capa.
+ [AWS OpsWorks: uso de la autorreparación para reemplazar instancias en estado de error](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ Implemente la recuperación automática mediante AWS Step Functions y AWS Lambda 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.
+ [¿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)
+ 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 de los eventos, se puede desencadenar AWS Lambda (u otros destinos) para ejecutar lógica de reparación personalizada en su carga de trabajo.
+ [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Uso de alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Recursos
**Documentos relacionados:**
+ [APN Partner: 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)
+ [AWS OpsWorks: uso de la autorreparación para reemplazar instancias en estado de error](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.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)
+ [Cómo funciona AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Uso de alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.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)
+ [Automatización de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [¿Qué es AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [¿Qué es Amazon FSx para Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [¿Qué es Amazon FSx para Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
**Vídeos relacionados:**
+ [Estabilidad estática en AWS: AWS re:Invent 2019: Presentación de la Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**Ejemplos relacionados:**
+ [Laboratorio de Well-Architected: Nivel 300: Implementación de comprobaciones de estado y administración de dependencias para mejorar la fiabilidad](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 Confiar en el plano de datos y no en el plano de control durante la recuperación
El plano de control se usa para configurar recursos y el plano de datos proporciona servicios. Los planos de datos tienen normalmente objetivos de diseño de mayor disponibilidad que los planos de control y suelen ser menos complejos. Al implementar respuestas de recuperación o mitigación a eventos que puedan afectar a la resiliencia, el uso de operaciones del plano de control puede reducir la resiliencia general de su arquitectura. Por ejemplo, puede usar el plano de datos de Amazon Route 53 para enviar de manera fiable las consultas DNS basadas en las comprobaciones de estado, pero para actualizar las políticas de enrutamiento de Route 53 se usa el plano de control, por lo que no debe usarlo 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 globalmente distribuidos y diseñados para un [acuerdo de nivel de servicio (SLA) del 100 % de disponibilidad.](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 priorizar la sólida coherencia y durabilidad que necesita al administrar DNS. Para conseguirlo, los planos de control se localizan en una única región, US East (N. 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 comunes 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 facilitar la mejor fiabilidad posible.
Para obtener más información sobre los planos de datos, los planos de control y cómo AWS crea servicios para cumplir los objetivos de alta disponibilidad, consulte el informe [Estabilidad estática con zonas de disponibilidad](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) y la [Amazon Builders’ Library.](https://aws.amazon.com/builders-library/)
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Use el plano de datos y no el plano de control cuando utilice Amazon Route 53 para la recuperación de desastres. Route 53 Application Recovery Controller le ayuda a administrar y coordinar la conmutación por error mediante comprobaciones de preparación y controles de enrutamiento. 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 localmente.
+ [¿Qué es Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Crear mecanismos de recuperación de desastres mediante Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Crear aplicaciones altamente resilientes mediante Amazon Route 53 Application Recovery Controller, parte 1: pila de una sola región](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Crear aplicaciones altamente resilientes mediante Amazon Route 53 Application Recovery Controller, parte 2: pila de varias regiones](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/)
+ Saber qué operaciones están en el plano de datos y cuáles están en el plano de control.
+ [La Amazon Builders' Library: Evitar la sobrecarga de los sistemas distribuidos asumiendo el control del servicio más pequeño](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)
+ [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)
## Recursos
**Documentos relacionados:**
+ [APN Partner: 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)
+ [La Amazon Builders' Library: Evitar la sobrecarga de los sistemas distribuidos asumiendo el control del servicio más pequeño](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)
+ [Crear aplicaciones altamente resilientes mediante Amazon Route 53 Application Recovery Controller, parte 1: pila de una sola región](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Crear aplicaciones altamente resilientes mediante Amazon Route 53 Application Recovery Controller, parte 2: pila de varias regiones](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/)
+ [Crear mecanismos de recuperación de desastres mediante Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [¿Qué es Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**Ejemplos relacionados:**
+ [Introducción de Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 Usar la estabilidad estática para evitar el comportamiento bimodal
El comportamiento bimodal es 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. En lugar de ello, debe crear cargas de trabajo que sean estables estáticamente y operen en un solo modo. En este caso, aprovisione suficientes instancias en cada zona de disponibilidad para administrar la carga de trabajo si se elimina una zona de disponibilidad y, a continuación, use Elastic Load Balancing o las comprobaciones de estado de Amazon Route 53 para retirar la carga de las instancias en mal estado.
La estabilidad estática para despliegues de computación (como instancias EC2 o contenedores) dará como resultado la máxima fiabilidad. Deben evaluarse sus pros y sus contras teniendo en cuenta los costes. Resulta menos costoso aprovisionar una menor capacidad de computación y confiar en el lanzamiento de nuevas instancias en caso de error. Sin embargo, ante errores a gran escala (como los errores de zona de disponibilidad), este enfoque resulta menos efectivo porque depende de la reacción a los contratiempos a medida que se presentan, en lugar de plantear una preparación ante esos contratiempos antes de que ocurran. Su solución debería sopesar la fiabilidad en comparación con las necesidades de costes de su carga de trabajo. Al utilizar más zonas de disponibilidad, la cantidad de computación adicional que necesita para la estabilidad estática disminuye.
![\[Diagrama que muestra la estabilidad estática de las instancias EC2 entre zonas de disponibilidad\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/static-stability.png)
Una vez que el tráfico ha cambiado, use AWS Auto Scaling para sustituir de forma asíncrona las instancias de la zona con errores y lanzarlas en las zonas en buen estado.
Otro ejemplo de comportamiento bimodal sería un tiempo de espera agotado de la red que podría hacer 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 falle y desencadene otras consecuencias inesperadas. Este bucle de retroalimentación negativa afecta a la disponibilidad de su carga de trabajo. En lugar de ello, debe crear cargas de trabajo que sean estables estáticamente y operen en un solo modo. Un diseño estáticamente estable supondría realizar un trabajo constante y actualizar continuamente el estado de configuración a una cadencia establecida. Cuando una llamada genera un error, la carga de trabajo utiliza el valor almacenado en caché anteriormente y activa una alarma.
Otro ejemplo de comportamiento bimodal es permitir que los clientes eludan 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 no debe permitirse, ya que cambia notablemente la demanda de la carga de trabajo y es probable que produzca un error.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Use la estabilidad estática para evitar el comportamiento bimodal. El comportamiento bimodal es 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.
+ [Minimizar las dependencias en un plan de recuperación de desastres](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [La Amazon Builders' Library: Estabilidad estática con zonas de disponibilidad](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Estabilidad estática en AWS: AWS re:Invent 2019: presentación de la Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ En lugar de ello, debe crear cargas de trabajo que sean estables estáticamente y operen en un solo modo. En este caso, aprovisione suficientes instancias en cada zona para administrar la carga de trabajo si se elimina una zona de disponibilidad y, a continuación, use Elastic Load Balancing o las comprobaciones de estado de Amazon Route 53 para retirar la carga de las instancias en mal estado.
+ Otro ejemplo de comportamiento bimodal es permitir que los clientes eludan 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 no debe permitirse, ya que cambia notablemente la demanda de la carga de trabajo y es probable que produzca un error.
## Recursos
**Documentos relacionados:**
+ [Minimizar las dependencias en un plan de recuperación de desastres](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [La Amazon Builders' Library: Estabilidad estática con zonas de disponibilidad](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**Vídeos relacionados:**
+ [Estabilidad estática en AWS: AWS re:Invent 2019: presentación de la Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 Enviar notificaciones cuando los eventos afecten a la disponibilidad
Las notificaciones se envían al detectar eventos importantes, incluso si el problema causado por el evento se solucionó automáticamente.
La corrección automática permite que la carga de trabajo sea fiable. Sin embargo, también puede disimular problemas subyacentes que deberían abordarse. Implemente una supervisión y unos eventos apropiados 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 raíz. Las alarmas de Amazon CloudWatch se pueden activar sobre la base de los errores que se produzcan. También pueden activarse sobre la base de las acciones de corrección automática que se ejecuten. 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.
**Patrones de uso no recomendados comunes:**
+ Enviar alarmas sobre las que nadie emprende medidas
+ Realizar la automatización de la autorreparación, pero no notificar que se necesita una reparación
**Beneficios de establecer esta práctica recomendada:** Las notificaciones de eventos de recuperación garantizarán que no se omitan problemas que ocurren con poca frecuencia.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Alarmas sobre indicadores clave de rendimiento (KPI) empresariales cuando superen un umbral bajo. Al tener una alarma de umbral bajo en sus KPI empresariales, podrá detectar cuándo su carga de trabajo no está disponible o no es funcional.
+ [Crear una alarma de CloudWatch basada en un umbral estático](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ Alarmas sobre eventos que invocan una automatización de corrección. Puede invocar directamente una API de SNS para enviar notificaciones con cualquier automatización que cree.
+ [¿Qué es Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
## Recursos
**Documentos relacionados:**
+ [Crear 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)
+ [¿Qué es Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
# REL 12 ¿Cómo pone a prueba la fiabilidad?
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.
**Topics**
+ [REL12-BP01 Usar guías de estrategias para investigar los errores](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 Realizar un análisis después del incidente](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 Comprobar los requisitos funcionales](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 Requisitos de escalado y rendimiento de las pruebas](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 Probar la resiliencia mediante la ingeniería del caos](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 Planificación regular de días de juego](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 Usar guías de estrategias para investigar los errores
Puede obtener respuestas sistemáticas e inmediatas a escenarios de error que no se entiendan bien documentando el proceso de investigación en guías de estrategias. Las guías de estrategias son pasos predefinidos realizados 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 haya identificado o deba derivarse.
Las guías de estrategias implican una planificación proactiva que debe llevar a cabo para poder emprender acciones reactivas de forma eficaz. Cuando se encuentran en producción casos de error que no están contemplados en la guía de estrategias, primero debe solucionar el problema (apagar el fuego). Luego, deberá volver y analizar los pasos que ha seguido para abordar el problema y, sobre ellos, añadir una nueva entrada en la guía.
Tenga en cuenta que las guías de estrategias se usan en respuesta a incidentes específicos y los runbooks se usan para conseguir resultados determinados. A menudo, los runbooks se usan para actividades rutinarias, mientras que las guías de estrategias se utilizan para responder a eventos no rutinarios.
**Antipatrones usuales:**
+ 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 sobre de qué sistemas se recopilan registros y métricas cuando se investiga un evento
+ No conservar 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 guías de estrategias garantiza que el proceso pueda seguirse sistemáticamente. La creación de guías de estrategias limita la introducción de errores de la actividad manual. La automatización de guías de estrategias reduce el tiempo para responder a un evento al eliminar el requisito de intervención de un miembro del equipo o al disponer 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
+ Use guías de estrategias para identificar problemas. Las guías de estrategias son procesos documentados para investigar problemas. Permita las respuestas sistemáticas e inmediatas a escenarios de error documentando los procesos en guías de estrategias. Las guías 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 (realizar un análisis después del incidente).
+ Implemente en código las guías de estrategias. Realice sus operaciones como código creando scripts de sus guías de estrategias para garantizar la sistematicidad y reducir los errores causados por los procesos manuales. Las guías 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 programar o realizar actividades de runbook como parte de las actividades de una guía de estrategias, o se puede solicitar la ejecución de una guía de estrategias en respuesta a eventos identificados.
+ [Automatizar las guías de estrategias operativas 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 alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Recursos
**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)
+ [Automatizar las guías de estrategias operativas con AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Uso de alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Uso de valores controlados (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:**
+ [Automatización de operaciones con guías de estrategias y runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 Realizar un análisis después del incidente
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.
**Patrones de uso no recomendados comunes:**
+ 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
**Beneficios de establecer esta práctica recomendada:** Realizar 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
+ Establezca un estándar para el análisis posterior a un incidente. Un buen análisis posterior a un incidente ofrece oportunidades de proponer soluciones comunes para problemas con patrones arquitectónicos que se utilizan en otros lugares de los sistemas.
+ Asegúrese de que los factores que han contribuido al problema son sinceros y están libres de reproches.
+ Si no documenta los problemas actuales, no podrá corregirlos.
+ Asegúrese de que el análisis después de un incidente se realice sin reproches para que las medidas correctivas propuestas sean imparciales y para fomentar la autoevaluación y colaboración honestas en sus equipos de aplicaciones.
+ Use un proceso para determinar los factores que han contribuido al problema. Disponga de un proceso para identificar y documentar los factores que han contribuido al problema, de manera que se puedan elaborar medidas de mitigación para limitar o prevenir su repetición y se puedan desarrollar procedimientos para dar respuestas rápidas y eficaces. Comunique los factores que han contribuido al problema según corresponda, adaptados al público de destino.
+ [¿Qué es el análisis de registros?](https://aws.amazon.com/log-analytics/)
## Recursos
**Documentos relacionados:**
+ [¿Qué es el análisis de registros?](https://aws.amazon.com/log-analytics/)
+ [Por qué debería desarrollar una corrección de errores (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
# REL12-BP03 Comprobar los requisitos funcionales
Use técnicas como pruebas unitarias y pruebas de integración que validen la funcionalidad necesaria.
Conseguirá los mejores resultados cuando estas pruebas se lleven a cabo automáticamente como parte de las acciones de compilación y despliegue. Por ejemplo, al utilizar AWS CodePipeline, los desarrolladores confirman los cambios en un repositorio de origen en el que CodePipeline detecta los cambios automáticamente. Esos cambios se incorporan y se realizan pruebas. Una vez completadas las pruebas, el código compilado se implementa en los servidores provisionales para comprobarlo. Desde el servidor provisional, CodePipeline ejecuta más pruebas, como pruebas de integración o carga. Una vez completadas correctamente esas pruebas, CodePipeline implementa el código comprobado y aprobado en instancias de producción.
Además, la experiencia demuestra que las pruebas de transacciones sintéticas (denominadas también *pruebas de valores controlados*, que no deben confundirse con las implementaciones de valores controlados) 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. Amazon CloudWatch Synthetics le permite [crear valores controlados](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) para supervisar sus puntos de conexión y API.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Compruebe los requisitos funcionales. Entre estas se incluyen las pruebas unitarias y las pruebas de integración que validan la funcionalidad necesaria.
+ [Use CodePipeline y AWS CodeBuild para probar el código y ejecutar compilaciones](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS CodePipeline añade compatibilidad a las pruebas unitarias y de integración personalizadas con AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Entrega continua e integración continua](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Uso de valores controlados (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Automatización de pruebas de software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudar con la implementación de una canalización de integración continua](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration)
+ [AWS CodePipeline añade compatibilidad a las pruebas unitarias y de integración personalizadas con AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [AWS Marketplace: productos que pueden usarse para la integración continua](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration)
+ [Entrega continua e integración continua](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Automatización de pruebas de software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [Use CodePipeline y AWS CodeBuild para probar el código y ejecutar compilaciones](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [Uso de valores controlados (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
# REL12-BP04 Requisitos de escalado y rendimiento de las pruebas
Use 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 su carga de trabajo. Si ejecuta estas pruebas en una infraestructura desescalada verticalmente, debe escalar los resultados observados a lo que cree que ocurrirá en producción. Las pruebas de carga y rendimiento también pueden realizarse en producción si se tiene cuidado de no afectar a los usuarios reales y se etiquetan los datos de prueba para que no se mezclen con los datos de usuarios reales y alteren las estadísticas de uso o los informes de producción.
Con las pruebas, asegúrese de que sus recursos base, la configuración de escalado, las cuotas de servicio y el diseño de resiliencia funcionan del modo esperado bajo carga.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Pruebe los requisitos de escalado y de rendimiento. Realice pruebas de carga para validar que la carga de trabajo satisface los requisitos de escalado y rendimiento.
+ [Pruebas de carga distribuida en AWS: simular miles de usuarios conectados](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
+ Implemente la aplicación en un entorno idéntico al de producción y ejecute una prueba de carga.
+ Utilice conceptos de infraestructura como código para crear un entorno tan similar al entorno de producción como sea posible.
## Recursos
**Documentos relacionados:**
+ [Pruebas de carga distribuida en AWS: simular miles de usuarios conectados](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
# REL12-BP05 Probar la resiliencia mediante la ingeniería del caos
Realice 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 los despliegues.
+ 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 ganar confianza sobre el hecho 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
La ingeniería del caos proporciona a sus equipos capacidades para inyectar continuamente interrupciones del mundo real (simulaciones) de forma controlada a nivel de 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 fallos y observen, midan y mejoren la resiliencia de sus cargas de trabajo, además de validar que las alertas se disparen y que los equipos reciban notificaciones en caso de algún evento.
Cuando se realiza de forma continua, la ingeniería del caos puede poner de manifiesto deficiencias en sus cargas de trabajo que, si no se abordan, podrían afectar negativamente 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 es capaz de soportar estas interrupciones, el experimento del caos debería mantenerse como una prueba de regresión automatizada. De este modo, los experimentos de caos deben realizarse como parte de su ciclo de vida de desarrollo de sistemas (SDLC) y como parte de su canalización de CI/CD.
Para asegurarse de que su carga de trabajo puede sobrevivir a los errores de los componentes, inyecte eventos del mundo real como parte de sus 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 su carga de trabajo no se ve afectada (o solo mínimamente). 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 recuperación o 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 bloqueando el 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 sus servicios. Las fuentes 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, que incluyen 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 realizar experimentos de inserció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 juego de ingeniería del caos. Admite la introducción simultánea de errores en diferentes tipos de recursos, 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 Amazon CloudWatch Alarms, puede configurar las condiciones de parada como barreras de protección para revertir un experimento si provoca un impacto inesperado.
![\[Diagrama que muestra la integración de AWS Fault Injection Service con los recursos de AWS para permitirle ejecutar experimentos de inserción de errores para sus cargas de trabajo.\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/fault-injection-simulator.png)
También hay varias opciones de terceros para los experimentos de inserción de errores. Incluyen herramientas de código abierto como [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/) y [Litmus Chaos](https://litmuschaos.io/), además de opciones comerciales como Gremlin. Para ampliar el alcance de los 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 utilizando errores de Chaos Mesh o Litmus mientras termina un porcentaje seleccionado al azar de nodos del clúster utilizando acciones de error de AWS FIS.
## Pasos para la aplicación
+ 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 utilizando las prácticas recomendadas del [Marco de buena arquitectura](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)) tienen en cuenta los riesgos basados en 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 estas listas, consulte el [documento técnico Revisión de la preparación operativa](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) que le orienta sobre cómo crear un proceso para evitar que se repitan incidentes anteriores. El proceso de análisis de modos de error y efectos (AMFE) le proporciona un marco para realizar un análisis de los fallos a nivel de componente y cómo afectan a su carga de trabajo. Adrian Cockcroft describe con más detalle el AMFE en [Failure Modes and Continuous Resilience (Modos de error y resiliencia continua)](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5).
+ Asigne una prioridad a cada error.
Comience con una categorización gruesa como alta, media o baja. Para evaluar la prioridad, hay que tener en cuenta la frecuencia del error y el impacto del mismo 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 realice 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 buena fuente de datos para comprender tanto la frecuencia como el impacto de los modos de error.
Utilice la prioridad asignada para determinar con qué fallos experimentar primero y el orden con el que desarrollar nuevos experimentos de inyección de errores.
+ En cada experimento que realice, siga la ingeniería del caos y el volante de resiliencia continua.
![\[Diagrama del volante de ingeniería del caos y resiliencia continua, que muestra las fases de Mejora, Estado estable, Hipótesis, Ejecución del experimento y Verificación.\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/chaos-engineering-flywheel.png)
+ 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.
+ 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 fue diseñada 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 el *error específico* , la carga de trabajo *nombre de carga de trabajo* , *describirá los controles mitigantes* 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 caen, 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 disparan 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 lado del servidor (5xx) (estado estable).
+ Si la instancia de la base de datos primaria de Amazon RDS falla, 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).
+ Realiza el experimento inyectando el error.
Un experimento debería ser por defecto a prueba de errores y tolerado por la carga de trabajo. Si sabe que la carga de trabajo va a fallar, no realice el experimento. Debe utilizarse la ingeniería del caos para encontrar conocidos-desconocidos o desconocidos-desconocidos. *Conocidos-desconocidos* son cosas de las que es consciente pero no comprende del todo, y *desconocidos-desconocidos* son cosas de las que no es consciente ni comprende del todo. Experimentar con una carga de trabajo que sabe que está rota no proporcionará nuevas ideas. Su experimento debe estar cuidadosamente planificado, tener un alcance claro de impacto y proporcionar un mecanismo de retroceso que pueda aplicarse en caso de turbulencias inesperadas. Si su diligencia demuestra que su carga de trabajo debería sobrevivir al experimento, siga adelante con el mismo. Hay varias opciones para inyectar los errores. Para cargas de trabajo en AWS, [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) proporciona muchas simulaciones de errores predefinidas llamadas [acciones](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). También puede definir acciones personalizadas que se ejecuten en AWS FIS utilizando [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 realizar experimentos con un alcance claramente definido y mecanismos de seguridad que reviertan el experimento en el caso de que introduzca turbulencias inesperadas. Para conocer una mayor variedad de experimentos con AWS FIS, consulte también el [Laboratorio de Aplicaciones resilientes y bien diseñadas con ingeniería del caos](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á su 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 fallos se simulen primero en un entorno no productivo antes de ejecutarlos en producción.
Los experimentos deben realizarse en producción bajo carga real utilizando [despliegue de valores controlados](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) que acelera tanto el despliegue de un sistema de control como el experimental, cuando es factible. 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 realizar experimentos utilizando tráfico sintético en la infraestructura de producción contra los despliegues 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 seguridad 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 que defina. Esto debería incluir las métricas para el estado estable de la carga de trabajo, así como la métrica contra los componentes en los que está inyectando el error. Una [monitorización sintética](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (también conocida como valor controlado) es una métrica que normalmente debería 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, permitiendo 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 realizar el experimento primero en un entorno de no producción, verificando que los umbrales para las condiciones de parada se activan como se espera durante un experimento y la observabilidad está implantada para detectar una excepción, en lugar de experimentar directamente en la producción.
Cuando se realicen 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 a estos equipos herramientas de comunicación para que informen a los que dirigen el experimento si observan algún efecto adverso.
Debe restablecer la carga de trabajo y sus sistemas subyacentes al estado bueno conocido original. A menudo, el diseño resistente de la carga de trabajo se autorrepara. Pero algunos diseños de errores o experimentos fallidos pueden dejar su 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) dentro de los parámetros de la acción. Una acción posterior devuelve el objetivo al estado en el que se encontraba antes de ejecutar la acción. Ya sean automatizadas (como el uso de 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.
+ 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 los atributos internos del mismo. Las mediciones de esa producción durante un corto periodo de tiempo 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 en 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 cómo funciona.
En nuestros dos ejemplos anteriores, incluimos las métricas de estado estable de menos del 0,01 % de aumento de errores del lado 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 un cliente de la carga de trabajo experimentará directamente. 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 fallidas de los clientes o los errores que aparecen en el cliente. Además, incluya una monitorización sintética (también conocida como valor controlado) en cualquier API o URI al que acceda directamente el cliente de su carga de trabajo.
+ Mejore el diseño de la carga de trabajo para la resiliencia.
Si el estado estable no se mantuvo, entonces investigue cómo se puede mejorar el diseño de la carga de trabajo para mitigar el error, aplicando las mejores prácticas del [Pilar de fiabilidad de AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Se pueden encontrar orientaciones y recursos adicionales en la [AWS Builder’s Library](https://aws.amazon.com/builders-library/)que aloja artículos sobre cómo [mejorar las comprobaciones de estado](https://aws.amazon.com/builders-library/implementing-health-checks/) o bien [emplear reintentos con retroceso en el código de su aplicación](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/), entre otros.
Una vez aplicados estos cambios, vuelva a realizar 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.
+ Realice experimentos con regularidad.
Un experimento de caos es un ciclo, y los experimentos deben realizarse 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 saber cómo hacerlo, consulte este blog sobre [cómo ejecutar 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 de AWS FIS periódicos 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 juego (consulte [REL12-BP06 Planificación regular de días de juego](rel_testing_resiliency_game_days_resiliency.md)). En los días de juego se simula un error o un evento para verificar los sistemas, los procesos y las respuestas de los equipos. El objetivo es, de hecho, realizar las acciones que llevaría a cabo el equipo si se produjera un evento excepcional.
+ 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 de control, volcados CSV de la base de datos de su métrica o un registro escrito a mano de los eventos y observaciones del experimento. [Experimentar el registro con AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) puede formar parte de esta captura de datos.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL08-BP03 Integrar las pruebas de resiliencia como parte de su despliegue](rel_tracking_change_management_resiliency_testing.md)
+ [REL13-BP03 Probar 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/)
+ [Ingeniería del caos: Planificar su primer experimento](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Ingeniería de resiliencia: aprender a asumir los errores](https://queue.acm.org/detail.cfm?id=2371297)
+ [Historias de ingeniería del caos](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [Evitar los planes alternativos en los sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [Despliegue de valores controlados para experimentos de caos](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**Vídeos relacionados:**
+ [AWS re:Invent 2020: Pruebas de resistencia mediante la ingeniería del caos (ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: Mejorar la resiliencia con la ingeniería del caos (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Realizar ingeniería del caos en un mundo sin servidores (CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA)
**Ejemplos relacionados:**
+ [Laboratorio de Well-Architected: Nivel 300: pruebas de resiliencia de Amazon EC2, Amazon RDS y Amazon S3](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
+ [Laboratorio de ingeniería del caos en AWS](https://chaos-engineering.workshop.aws/en/)
+ [Laboratorio de aplicaciones resilientes y bien diseñadas con ingeniería del caos](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)
+ [Laboratorio de caos sin servidor](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless)
+ [Medir y mejorar la resiliencia de sus aplicaciones con laboratorio de AWS Resilience Hub](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab)
** Herramientas relacionadas: **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ AWS Marketplace: [Gremlin Chaos Engineering Platform (Plataforma de ingeniería del caos de Gremlin)](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP06 Planificación regular de días de juego
Utilice días de juego para poner en práctica frecuentemente sus procedimientos para responder a los eventos y los errores lo más cerca de la fecha de lanzamiento a producción posible (incluidos los entornos de producción) con las personas que trabajarán en los escenarios de error reales. Los días de juego sirven para imponer medidas que garanticen que los eventos de producción no afecten a los usuarios.
En los días de juego se simula un error o un evento para probar los sistemas, los procesos y las respuestas de los equipos. El objetivo es, de hecho, realizar las acciones que llevaría a cabo el equipo si se produjera un evento excepcional. Esto ayudará a comprender dónde se pueden realizar mejoras y a desarrollar la experiencia organizacional en la gestión de eventos. Deberían hacerse habitualmente para que el equipo desarrolle *“memoria muscular”* sobre cómo responder.
Una vez que cuente con un diseño de resiliencia y que lo haya probado en entornos que no sean de producción, los días de juego son la fórmula ideal para garantizar que todo funcione según lo previsto en el entorno de producción. Un día de juego, especialmente el primero, es una actividad para todo el equipo en la que los ingenieros y el personal de operaciones están informados de cuándo ocurrirá y de qué pasará. Hay runbooks preparados. Se ejecutan eventos simulados, incluidos los posibles eventos de error, en los sistemas de producción y de la forma prescrita y, entonces, se evalúa el impacto. Si todos los sistemas funcionan según lo diseñado, la detección y la autocorrección se producirán con un impacto mínimo o inexistente. Sin embargo, si se observa algún impacto negativo, se da marcha atrás a la prueba y los problemas con la carga de trabajo se remedian, de forma manual si fuera necesario (utilizando el runbook). Dado que los días de juego suelen desarrollarse en el entorno de producción, deben tomarse todas las precauciones necesarias para garantizar que no haya ningún impacto sobre la disponibilidad para los clientes.
**Antipatrones usuales:**
+ Documentar los procedimientos, pero no ponerlos nunca en práctica
+ No incluir a los responsables de la toma de decisiones del negocio en los ejercicios de prueba
**Beneficios de establecer esta práctica recomendada:** Realizar días de juego periódicamente garantiza que todos los empleados sigan las políticas y los procedimientos cuando se produzca un incidente real y valida que esas políticas y procedimientos son apropiados.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Programe días de juego para practicar con las guías de estrategias y runbooks. Todo el mundo que pueda verse involucrado en un evento de producción debe participar en los días de juego: el propietario de la empresa, el personal de desarrollo, el personal de operaciones y los equipos de respuesta a incidentes.
+ Ejecute sus pruebas de carga o rendimiento y después su inyección de errores.
+ Busque anomalías en los runbooks y oportunidades para poner en práctica las guías de estrategias.
+ Si se desvía de los runbooks, mejórelos o corrija este comportamiento. Si utiliza la guía de estrategias, identifique el runbook que debería haberse usado o cree uno nuevo.
## Recursos
**Documentos relacionados:**
+ [¿Qué es AWS GameDay?](https://aws.amazon.com/gameday/)
**Videos relacionados:**
+ [AWS re:Invent 2019: Mejorar la resiliencia con la ingeniería del caos (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
**Ejemplos relacionados:**
+ [Laboratorios de AWS Well-Architected: comprobación de resiliencia](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL 13 ¿Cómo planifica la recuperación de desastres (DR)?
Disponer de copias de seguridad y de componentes de cargas de trabajo redundantes es el principio de su estrategia de DR. [El RTO y el RPO son sus objetivos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) para la restauración de su carga de trabajo. Estos se definen en función de las necesidades del negocio. Implemente una estrategia para satisfacer estos objetivos teniendo en cuenta las ubicaciones y la función de los recursos de las cargas de trabajo y los datos. La probabilidad de una interrupción y el coste de recuperación son también factores clave que ayudan a conocer el valor empresarial de proporcionar recuperación de desastres para una carga de trabajo.
**Topics**
+ [REL13-BP01 Definir objetivos de recuperación para la inactividad y la pérdida de datos](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Usar estrategias de recuperación definidas para cumplir los objetivos de recuperación](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Probar la implementación de recuperación de desastres para validarla](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Administrar la desviación de la configuración en el sitio de o en la región de recuperación de desastres](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Automatizar la recuperación](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Definir objetivos de recuperación para la inactividad y la pérdida de datos
La carga de trabajo tiene un objetivo de tiempo de recuperación (RTO) y un objetivo de punto de recuperación (RPO).
*Objetivo de tiempo de recuperación (RTO)* es el retraso máximo aceptable entre la interrupción del servicio y su restablecimiento. Esto determina lo que se considera un intervalo de tiempo aceptable cuando el servicio no está disponible.
*Objetivo de punto de recuperación (RPO)* es el periodo de tiempo máximo aceptable desde el último punto de recuperación de datos. Determina lo que se considera una pérdida aceptable de datos entre el último punto de recuperación y la interrupción del servicio.
Los valores de RTO y RPO son consideraciones importantes a la hora de seleccionar una estrategia de recuperación de desastres (DR) adecuada para su carga de trabajo. Estos objetivos los determina la empresa y los utilizan los equipos técnicos para seleccionar e implementar una estrategia de recuperación de desastres.
**Resultado deseado:**
Cada carga de trabajo tiene un RTO y un RPO asignados, definidos en función del impacto empresarial. La carga de trabajo se asigna en un nivel predefinido, lo que define la disponibilidad del servicio y la pérdida de datos aceptable, con un RTO y un RPO asociados. Si no es posible esta jerarquización, se puede asignar de forma personalizada por carga de trabajo, con la intención de crear niveles más adelante. RTO y RPO se utilizan como una de las principales consideraciones para la selección de la implementación de una estrategia de recuperación de desastres para la carga de trabajo. Otras consideraciones a la hora de elegir una estrategia de recuperación de desastres son las restricciones de costes, las dependencias de la carga de trabajo y los requisitos operativos.
Para RTO, entienda el impacto basado en la duración de una interrupción. ¿Es lineal o hay implicaciones no lineales? (por ejemplo, después de cuatro horas, se cierra una línea de fabricación hasta el comienzo del siguiente turno).
Una matriz de recuperación de desastres, como la siguiente, puede ayudarle a entender cómo se relaciona la criticidad de la carga de trabajo con los objetivos de recuperación. (Tenga en cuenta que los valores reales de los ejes X e Y deben adaptarse a las necesidades de su organización).
![\[Gráfico que muestra la matriz de recuperación de desastres\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**Patrones de uso no recomendados comunes:**
+ No hay objetivos de recuperación definidos.
+ Seleccionar objetivos de recuperación arbitrarios.
+ Seleccionar objetivos de recuperación demasiado permisivos y no satisfacer los objetivos empresariales
+ No entender el impacto del tiempo de inactividad y la pérdida de datos.
+ Seleccionar objetivos de recuperación poco realistas, como el tiempo de recuperación cero y la pérdida de datos cero, que pueden no ser alcanzables para la configuración de su carga de trabajo.
+ Seleccionar objetivos de recuperación más estrictos que los objetivos empresariales reales Esto obliga a realizar implementaciones de recuperación de desastres más costosas y complejas de lo que necesita la carga de trabajo.
+ Seleccionar objetivos de recuperación incompatibles con los de una carga de trabajo dependiente.
+ Sus objetivos de recuperación no tienen en cuenta los requisitos de cumplimiento normativo.
+ RTO y RPO definidos para una carga de trabajo, pero nunca se han probado.
**Beneficios de establecer esta práctica recomendada:** Los objetivos de recuperación de tiempo y pérdida de datos son necesarios para guiar su implementación de DR.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
Para la carga de trabajo dada, debe entender el impacto del tiempo de inactividad y la pérdida de datos en su empresa. Por lo general, el impacto aumenta con un mayor tiempo de inactividad o pérdida de datos, pero la forma de este crecimiento puede variar en función del tipo de carga de trabajo. Por ejemplo, puede ser capaz de tolerar un tiempo de inactividad de hasta una hora con poco impacto, pero después el impacto aumenta rápidamente. El impacto en la empresa se manifiesta de muchas formas, como el coste económico (por ejemplo, la pérdida de ingresos), la confianza de los clientes (y el impacto en la reputación), los problemas operativos (por ejemplo, la pérdida de nóminas o la disminución de la productividad) y el riesgo normativo. Siga estos pasos para entender estos impactos y establecer RTO y RPO para su carga de trabajo.
**Pasos de implementación**
1. Determine las partes interesadas de su empresa para esta carga de trabajo y colabore con ellas para implementar estos pasos. Los objetivos de recuperación de una carga de trabajo son una decisión empresarial. Después, los equipos técnicos trabajan con las partes interesadas de la empresa para utilizar estos objetivos para seleccionar una estrategia de recuperación de desastres.
**nota**
Para los pasos 2 y 3, puede usar la [Hoja de trabajo de implementación](#implementation-worksheet).
1. Responda a las preguntas siguientes para reunir la información necesaria a fin de tomar una decisión.
1. ¿Tiene categorías o niveles de criticidad para el impacto de la carga de trabajo en su organización?
1. En caso afirmativo, asigne esta carga de trabajo a una categoría.
1. En caso contrario, establezca estas categorías. Cree un máximo de cinco categorías y ajuste el intervalo de su objetivo de tiempo de recuperación para cada una. Algunos ejemplos de categorías son: crítica, alta, media, baja. Para entender cómo se asignan las cargas de trabajo a las categorías, considere si la carga de trabajo es de misión crítica, importante para la empresa o no lo es.
1. Establezca el RTO y el RPO de la carga de trabajo en función de la categoría. Acceda a este paso para elegir siempre una categoría más estricta (RTO y RPO más bajos) que los valores sin procesar calculados. Si esto da lugar a un cambio de valor inadecuado, considere la posibilidad de crear una nueva categoría.
1. Según estas respuestas, asigne los valores de RTO y RPO a la carga de trabajo. Se puede hacer directamente o mediante la asignación de la carga de trabajo a un nivel de servicio predefinido.
1. Documente el plan de recuperación de desastres (DRP) de esta carga de trabajo, que forma parte del [plan de continuidad del negocio (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)de su organización, en una ubicación accesible al equipo de la carga de trabajo y las partes interesadas.
1. Registre el RTO y el RPO, así como la información utilizada para determinar estos valores. Incluya la estrategia que se utiliza para evaluar el impacto de la carga de trabajo en la empresa.
1. Registre otras métricas, además de RTO y RPO, de las que hace un seguimiento o planifica hacerlo para los objetivos de recuperación de desastres.
1. Agregará los detalles de su estrategia de recuperación de desastres y su runbook a este plan cuando los cree.
1. Si busca la criticidad de la carga de trabajo en una matriz como la de la figura 15, puede empezar a establecer los niveles de servicio predefinidos para su organización.
1. Después de haber implementado una estrategia de recuperación de desastres (o una prueba de concepto para una estrategia de este tipo) según [REL13-BP02 Usar estrategias de recuperación definidas para cumplir los objetivos de recuperación](rel_planning_for_recovery_disaster_recovery.md), pruebe esta estrategia para determinar la capacidad de tiempo de recuperación (RTC) y de punto de recuperación (RPC) reales de la carga de trabajo. Si no cumplen los objetivos de recuperación previstos, es posible colaborar con las partes interesadas de su empresa para ajustar dichos objetivos o realizar cambios en la estrategia de RD para cumplir los objetivos previstos.
**Preguntas principales**
1. ¿Cuál es el tiempo máximo que la carga de trabajo puede estar inactiva antes de que se produzca un impacto grave en la empresa?
1. Determine el coste económico (impacto financiero directo) para la empresa por minuto si se interrumpe la carga de trabajo.
1. Considere que el impacto no siempre es lineal. El impacto puede ser limitado al principio e ir aumentando rápidamente a partir de un punto crítico.
1. ¿Cuál es la cantidad máxima de datos que puede perderse antes de que se produzca un impacto grave en la empresa?
1. Considere este valor para su almacén de datos más crítico. Identifique la criticidad correspondiente de otros almacenes de datos.
1. ¿Se pueden recrear los datos de la carga de trabajo si se pierden? Si esto es operativamente más fácil que la copia de seguridad y la restauración, elija el RPO en función de la criticidad de los orígenes de los datos que se utilizan para recrear los datos de la carga de trabajo.
1. ¿Cuáles son los objetivos de recuperación y las expectativas de disponibilidad de las cargas de trabajo de las que depende esta (descendente), o de las cargas de trabajo que dependen de esta (ascendente)?
1. Elija objetivos de recuperación que permitan a esta carga de trabajo cumplir los requisitos de las dependencias ascendentes.
1. Elija objetivos de recuperación que sean alcanzables teniendo en cuenta las capacidades de recuperación de las dependencias descendentes. Se pueden excluir las dependencias descendentes no críticas (aquellas que puede «resolver»). O bien, trabaje con las dependencias críticas posteriores para mejorar sus capacidades de recuperación cuando sea necesario.
**Preguntas adicionales**
Considere estas preguntas y cómo pueden aplicarse a esta carga de trabajo:
1. ¿Tiene diferentes RTO y RPO en función del tipo de interrupción región con respecto a AZ, etc.)?
1. ¿Hay algún momento específico (estacionalidad, eventos de ventas, lanzamientos de productos) en el que pueda cambiar su RTO/RPO? Si es así, ¿cuál es el límite de medida y tiempo diferente?
1. ¿Cuántos clientes se verán afectados si se interrumpe la carga de trabajo?
1. ¿Cuál es el impacto en la reputación si se interrumpe la carga de trabajo?
1. ¿Qué otros impactos operativos pueden producirse si se interrumpe la carga de trabajo? Por ejemplo, el impacto en la productividad de los empleados si los sistemas de correo electrónico no están disponibles o si los sistemas de nómina no pueden enviar las transacciones.
1. ¿Cómo se alinean el RTO y el RPO de la carga de trabajo con la línea de negocio y la estrategia organizativa de recuperación de desastres?
1. ¿Existen obligaciones contractuales internas para la prestación de un servicio? ¿Existen sanciones por incumplirlas?
1. ¿Cuáles son las restricciones normativas o de cumplimiento con los datos?
## Hoja de trabajo de implementación
Puede utilizar esta hoja de trabajo para implementar los pasos 2 y 3. Puede ajustar esta hoja de trabajo para adaptarla a sus necesidades específicas, por ejemplo, puede agregar preguntas adicionales.
![\[Hoja de trabajo\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/worksheet.png)
**Nivel de esfuerzo para el plan de implementación: **Bajo
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL09-BP04 Realizar una recuperación periódica de los datos para verificar la integridad de la copia de seguridad y los procesos](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 Usar estrategias de recuperación definidas para cumplir los objetivos de recuperación](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Probar la implementación de recuperación de desastres para validarla](rel_planning_for_recovery_dr_tested.md)
**Documentos relacionados:**
+ [Blog de arquitectura de AWS: serie de recuperación de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperación de desastres de las cargas de trabajo en AWS: recuperación en la nube (documento técnico de AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Managing resiliency policies with AWS Resilience Hub (Administración de las políticas de resiliencia con AWS Resilience Hub)](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [Socio de APN: socios que pueden ayudar con la recuperación de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: productos que pueden usarse para la recuperación de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Patrones de arquitectura para aplicaciones activas-activas en varias regiones) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Disaster Recovery of Workloads on AWS (Recuperación de desastres de cargas de trabajo en AWS)](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 Usar estrategias de recuperación definidas para cumplir los objetivos de recuperación
Defina una estrategia de recuperación de desastres (DR) que se ajuste a los objetivos de recuperación de su carga de trabajo. Elija una estrategia como copia de seguridad y restauración, estado de espera (activa/pasiva) o activa/activa.
Una estrategia de DR depende de la capacidad de poner en marcha su carga de trabajo en un sitio de recuperación si su ubicación principal deja de estar disponible para la ejecución de dicha carga de trabajo. Los objetivos de recuperación más comunes son el RTO y el RPO, como explicamos en [REL13-BP01 Definir objetivos de recuperación para la inactividad y la pérdida de datos](rel_planning_for_recovery_objective_defined_recovery.md).
Una estrategia de DR en varias zonas de disponibilidad (AZ) dentro de una única Región de AWS puede ofrecer mitigación contra eventos de desastres como incendios, inundaciones y cortes de suministro eléctrico considerables. Si es necesario implementar medidas de protección contra un evento poco probable que evite que su carga de trabajo pueda ejecutarse en una Región de AWS determinada, puede seguir una estrategia de DR que abarque múltiples regiones.
A la hora de diseñar una estrategia de DR en varias regiones, debería elegir una de las siguientes estrategias. Se indican en orden ascendente de coste y complejidad y en orden descendente en cuanto al RTO y RPO. *Una región de recuperación* es una Región de AWS diferente a la principal que se usa para su carga de trabajo.
![\[Diagrama que muestra estrategias de DR\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **Generación de copias de seguridad y restauración** (RPO en horas, RTO en 24 horas o menos): cree una copia de seguridad de sus datos y aplicaciones en la región de recuperación. El uso de copias de seguridad automatizadas o continuas permitirá la recuperación a un momento dado, lo que puede reducir el RPO a hasta 5 minutos en algunos casos. En caso de desastre, desplegará su infraestructura (utilizando la infraestructura como código para reducir el RTO), desplegará su código y restaurará los datos desde la copia de seguridad para recuperarse del desastre en la región de recuperación.
+ **Luz piloto** (RPO en minutos, RTO en decenas de minutos): aprovisione una copia de la infraestructura principal de su carga de trabajo en la región de recuperación. Replique sus datos en la región de recuperación y cree copias de seguridad de estos allí. Los recursos necesarios para permitir la replicación y copia de seguridad de los datos, como el almacenamiento de bases de datos y objetos, están siempre disponibles. Otros elementos, como los servidores de aplicaciones o la computación sin servidor, no se despliegan, pero pueden crearse cuando sea necesario con la configuración y el código de aplicación pertinentes.
+ **Espera semiactiva** (RPO en segundos, RTO en minutos): mantenga una versión reducida pero totalmente funcional de su carga de trabajo ejecutándose continuamente en la región de recuperación. Los sistemas críticos se duplican en su totalidad y siempre están activos, pero con una flota reducida. Los datos se replican y están activos en la región de recuperación. Cuando llegue el momento de la recuperación, el sistema se amplía rápidamente para asumir la carga de producción. Cuanto mayor sea la escala de la espera semiactiva, menor será el RTO y la fiabilidad del plano de control. Cuando alcanza su plena escala, la espera pasa a denominarse **espera activa**.
+ **Activa-activa multirregión (multisitio)** (RPO próximo a cero, RTO potencial de cero): la carga de trabajo está desplegada en varias Regiones de AWS y entrega tráfico de forma activa desde estas regiones. Esta estrategia requiere que sincronice datos entre regiones. Los posibles conflictos causados por escrituras en el mismo registro en dos diferentes réplicas regionales deben evitarse o gestionarse, lo que puede resultar complejo. La replicación de datos es útil para la sincronización de datos y le protegerá ante algunos tipos de desastres, pero no ante el daño o la destrucción de datos a no ser que su solución incluya también opciones para una recuperación a un momento dado.
**nota**
La diferencia entre la luz piloto y la espera semiactiva a veces puede ser difícil de comprender. Ambos métodos incluyen un entorno en su región de recuperación con copias de los activos de su región principal. La distinción es que la luz piloto no puede procesar solicitudes sin tomar primero acciones adicionales, mientras que la espera semiactiva puede gestionar el tráfico (a niveles de capacidad reducidos) inmediatamente. La luz piloto exige que active servidores, posiblemente que despliegue infraestructura adicional (no principal) y que escale verticalmente, mientras que la espera semiactiva solo requiere que escale verticalmente (ya está todo desplegado y en ejecución). Elija una de estas opciones en función de sus necesidades de RTO y RPO.
**Resultado deseado:**
Para cada carga de trabajo, existe una estrategia de DR definida e implementada que permite que esa carga de trabajo alcance los objetivos de DR. Las estrategias de DR entre cargas de trabajo emplean patrones reutilizables (como las estrategias descritas anteriormente).
**Patrones de uso no recomendados comunes:**
+ Implementar procedimientos de recuperación incoherentes para cargas de trabajo con objetivos de DR similares.
+ Dejar la estrategia de DR para implementarla ad hoc cuando se produzca un desastre.
+ No tener plan de DR.
+ Depender de las operaciones del plano de control durante la recuperación.
**Beneficios de establecer esta práctica recomendada:**
+ El uso de estrategias de recuperación definidas le permite emplear herramientas y procedimientos de prueba comunes.
+ El uso de estrategias de recuperación definidas permite un intercambio de conocimiento más eficiente entre equipos y una implementación más sencilla de la DR en las cargas de trabajo que se encuentran bajo su responsabilidad.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
+ Sin una estrategia de DR planificada, implementada y probada, es poco probable que consiga sus objetivos de recuperación en caso de desastre.
## Guía para la implementación
Consulte más abajo los detalles de cada uno de estos pasos.
1. Determine una estrategia de DR que satisfaga los requisitos de recuperación de esta carga de trabajo.
1. Revise los patrones de implementación de la estrategia de DR seleccionada.
1. Evalúe los recursos de su carga de trabajo y cuál será su configuración en la región de recuperación antes de la conmutación por error (durante la operación normal).
1. Determine e implemente cómo preparará su región de recuperación para la conmutación por error cuando sea necesario (durante un evento de desastre).
1. Determine e implemente cómo redirigirá su tráfico a la conmutación por error cuando sea necesario (durante un evento de desastre).
1. Diseñe un plan para la recuperación tras error de su carga de trabajo.
**Pasos de implementación**
1. **Determine una estrategia de DR que satisfaga los requisitos de recuperación de esta carga de trabajo.**
La selección de una estrategia de DR requiere alcanzar un punto de equilibrio entre la reducción del tiempo de inactividad y la pérdida de datos (RTO y RPO) por un lado, y los costes y la complejidad de implementar la estrategia por otro lado. Debería evitar implementar una estrategia que sea más exigente de lo necesario, ya que esto supone costes innecesarios.
Por ejemplo, en el siguiente diagrama, la empresa ha determinado su RTO máximo permisible y el límite de gasto en su estrategia de restauración del servicio. Dados los objetivos de la empresa, las estrategias de DR de luz piloto o espera semiactiva satisfarán tanto el RTO como los criterios de coste.
![\[Gráfico que muestra una estrategia de DR basada en el RTO y el coste\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)
Para obtener más información, consulte el [Plan de continuidad del negocio (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **Revise los patrones de implementación de la estrategia de DR seleccionada.**
Este paso implica comprender cómo implementará la estrategia seleccionada. Las estrategias se explican utilizando Regiones de AWS para determinar un sitio principal y otro de recuperación. Sin embargo, también puede decidir utilizar zonas de disponibilidad en una única región como estrategia de DR, que utiliza los elementos de varias de estas estrategias.
En los pasos posteriores a este, aplicará la estrategia a su carga de trabajo específica.
**Generación de copias de seguridad y restauración**
*Generación de copias de seguridad y restauración* es la estrategia menos compleja de implementar, pero requiere más tiempo y esfuerzo para restaurar la carga de trabajo, lo que genera un mayor RTO y RPO. Se recomienda realizar siempre copias de seguridad de los datos y copiarlas en otro sitio (por ejemplo, otra Región de AWS).
![\[Diagrama que muestra una arquitectura de copia de seguridad y restauración\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)
Para obtener más información sobre esta estrategia, consulte [Arquitectura de recuperación de desastres (DR) en AWS, parte II: copia de seguridad y restauración con recuperación rápida](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**Luz piloto**
Con el enfoque de *luz piloto* , replica sus datos de la región principal en la región de recuperación. Los recursos principales utilizados para la infraestructura de la carga de trabajo se despliegan en la región de recuperación; sin embargo, se siguen necesitando recursos adicionales y las dependencias pertinentes para que esta pila sea funcional. Por ejemplo, en la figura 20 no se despliegan instancias de computación.
![\[Diagrama que muestra una arquitectura de luz piloto\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
Para obtener más información sobre esta estrategia, consulte [Arquitectura de recuperación de desastres (DR) en AWS, parte III: luz piloto y espera semiactiva](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Espera semiactiva**
La *espera semiactiva* supone garantizar que exista una copia con desescalada vertical pero con plena funcionalidad de su entorno de producción en otra región. Este enfoque extiende el concepto de luz piloto y reduce el tiempo de recuperación ya que su carga de trabajo tiene disponibilidad permanente en otra región. Si la región de recuperación se despliega a plena capacidad, esto se denomina *espera activa*.
![\[Diagrama que muestra la figura 21 con arquitectura de espera semiactiva\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)
El uso de la espera semiactiva o la luz piloto requiere escalar verticalmente los recursos en la región de recuperación. Para garantizar que la capacidad esté disponible cuando sea necesario, piense en usar [reservas de capacidad](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) para instancias EC2. Si usa AWS Lambda, la [concurrencia aprovisionada](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) puede garantizar los entornos de ejecución de modo que estén preparados para responder inmediatamente a las invocaciones de su función.
Para obtener más información sobre esta estrategia, consulte [Arquitectura de recuperación de desastres (DR) en AWS, parte III: luz piloto y espera semiactiva](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Activa-activa multisitio**
Puede ejecutar su carga de trabajo de forma simultánea en varias regiones como parte de una estrategia *activa-activa multisitio* . La estrategia activa-activa multisitio sirve tráfico desde todas las regiones en las que se despliega. Los clientes podrían seleccionar esta estrategia por motivos ajenos a la DR. Se puede usar para aumentar la disponibilidad o cuando se despliega una carga de trabajo para una audiencia global (para colocar el punto de conexión más cerca de los usuarios o para desplegar pilas localizadas para la audiencia de esa región). Como estrategia de DR, si la carga de trabajo no es compatible en una de las Regiones de AWS en la que esté desplegada, esa región se evacúa y las regiones restantes se usan para mantener la disponibilidad. La estrategia activa-activa multisitio es la más compleja operativamente de las estrategias de DR y solamente debería seleccionarse cuando los requisitos empresariales lo exijan.
![\[Diagrama que muestra una arquitectura activa-activa multisitio\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)
Para obtener más información sobre esta estrategia, consulte [Arquitectura de recuperación de desastres (DR) en AWS, parte IV: activa-activa multisitio](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**Prácticas adicionales para la protección de datos**
Con todas las estrategias, también debe mitigar los posibles desastres de datos. La replicación de datos continua le protegerá ante algunos tipos de desastres, pero no ante el daño o la destrucción de datos a no ser que su estrategia incluya también control de versiones para una recuperación a un momento dado. También debe realizar una copia de seguridad de los datos replicados en el sitio de recuperación para crear copias de seguridad a un momento dado además de las réplicas.
**Uso de varias zonas de disponibilidad (AZ) en una única Región de AWS**
Al usar varias AZ en una única región, su implementación de DR utiliza varios elementos de las estrategias anteriores. Primero, debe crear una arquitectura de alta disponibilidad utilizando varias AZ, como se muestra en la figura 23. Esta arquitectura emplea una estrategia activa-activa multisitio, ya que las [instancias Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) y el [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) tienen recursos desplegados en varias AZ y gestionan activamente las solicitudes. La arquitectura también demuestra espera activa, mediante la que si la instancia [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) principal falla (o si falla la AZ en sí), la instancia en espera pasa a ser la principal.
![\[Diagrama que muestra la figura 23 con arquitectura multi-AZ\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
Además de esta arquitectura de alta disponibilidad, necesita agregar copias de seguridad con todos los datos necesarios para ejecutar su carga de trabajo. Esto es especialmente importante para datos que estén limitados a una única zona, como los [volúmenes de Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) o bien [los clústeres de Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Si falla una AZ, tendrá que restaurar estos datos en otra AZ. Siempre que sea posible, deberá copiar las copias de seguridad de los datos en otra Región de AWS como capa de protección adicional.
La DR multi-AZ es un enfoque alternativo menos habitual a la región única, y se ejemplifica en esta publicación de blog: [Crear aplicaciones altamente resilientes mediante Amazon Route 53 Application Recovery Controller, parte 1: pila de una sola región](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/). Aquí, la estrategia es mantener la máxima cantidad posible de aislamiento entre las AZ, igual que funcionan las regiones. Al utilizar esta estrategia alternativa, puede elegir un enfoque activo-activo o activo-pasivo.
Nota: Algunas cargas de trabajo tienen requisitos normativos de residencia de los datos. Si esto se aplica a su carga de trabajo en una ubicación que actualmente tenga solo una Región de AWS, el enfoque multirregión no se adaptará a sus necesidades empresariales. Las estrategias multi-AZ ofrecen una buena protección contra la mayor parte de los desastres.
1. **Evalúe los recursos de su carga de trabajo y cuál será su configuración en la región de recuperación antes de la conmutación por error (durante la operación normal).**
Para la infraestructura y los recursos de AWS, use infraestructura como código, como [AWS CloudFormation](https://aws.amazon.com/cloudformation) , o herramientas de terceros, como Hashicorp Terraform. Para desplegar en varias cuentas y regiones con una única operación, puede usar [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). En las estrategias activa-activa multisitio o de espera activa, la infraestructura desplegada en su región de recuperación tiene los mismos recursos que su región principal. En las estrategias de luz piloto y espera semiactiva, la infraestructura desplegada requerirá acciones adicionales para prepararse para la producción. En CloudFormation, con sus [parámetros](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) y [su lógica condicional](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html), puede controlar si una pila desplegada está activa o en espera con una única plantilla. Un ejemplo de una de estas plantillas de CloudFormation se incluye en [esta publicación de blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
Todas las estrategias de DR requieren que los orígenes de datos tengan una copia de seguridad en la Región de AWS y que esta se copie en la región de recuperación. [AWS Backup](https://aws.amazon.com/backup/) ofrece una vista centralizada desde la que puede configurar, programar y supervisar copias de seguridad de esos recursos. En el caso de las opciones de luz piloto, espera semiactiva y activa-activa multisitio, también debería replicar los datos de la región principal en los recursos de datos de la región de recuperación, como las instancias de base de datos de [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) o las tablas de [Amazon DynamoDB](https://aws.amazon.com/dynamodb) . De esta forma, estos recursos de datos estarán activos y preparados para responder a solicitudes en la región de recuperación.
Para obtener más información sobre cómo los servicios de AWS operan entre regiones, consulte esta serie de blog sobre la [creación de una aplicación multirregión con servicios de AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Determine e implemente cómo preparará su región de recuperación para la conmutación por error cuando sea necesario (durante un evento de desastre).**
En el caso de la opción activa-activa multisitio, la conmutación por error implica evacuar una región y recurrir a las regiones activas restantes. En general, esas regiones están listas para aceptar tráfico. En las estrategias de luz piloto y espera semiactiva, sus acciones de recuperación tendrán que desplegar los recursos faltantes, como las instancias EC2 en la figura 20, además de otros recursos faltantes.
En todas las estrategias anteriores, es posible que tenga que promover instancias de solo lectura de bases de datos para que se conviertan en la instancia de lectura y escritura principal.
En la copia de seguridad y la restauración, la restauración de datos desde una copia de seguridad crea recursos para esos datos, como volúmenes EBS, instancias de bases de datos RDS y tablas de DynamoDB. También tiene que restaurar la infraestructura y desplegar el código. Puede usar AWS Backup para restaurar datos en la región de recuperación. Consulte [REL09-BP01 Identificar todos los datos de los que se debe hacer una copia de seguridad y crearla o reproducir los datos a partir de los orígenes](rel_backing_up_data_identified_backups_data.md) para obtener más información. La reconstrucción de la infraestructura incluye la creación de recursos como instancias EC2 además de las [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), las subredes y los grupos de seguridad necesarios. Puede automatizar gran parte del proceso de restauración. Para aprender cómo, consulte [esta publicación de blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **Determine e implemente cómo redirigirá su tráfico a la conmutación por error cuando sea necesario (durante un evento de desastre).**
Esta operación de conmutación por error se puede iniciar automáticamente o manualmente. La conmutación por error iniciada automáticamente basada en comprobaciones de estado o alarmas se debe usar con cuidado, ya que una conmutación por error innecesaria (falsa alarma) supone ciertos inconvenientes, como la falta de disponibilidad y la pérdida de datos. Por tanto, la conmutación por error iniciada manualmente es la que se suele utilizar. En este caso, debe seguir automatizando los pasos de la conmutación por error, de modo que la iniciación manual sea como pulsar un botón.
Hay varias opciones de administración del tráfico que tener en cuenta al usar servicios de AWS. Una opción es usar [Amazon Route 53](https://aws.amazon.com/route53). Al usar Amazon Route 53, puede asociar varios puntos de conexión de IP en una o varias Regiones de AWS con un nombre de dominio de Route 53. Para implementar la conmutación por error iniciada manualmente, puede usar [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/), que proporciona una API de plano de datos con alta disponibilidad para redirigir el tráfico a la región de recuperación. Al implementar la conmutación por error, use las operaciones del plano de datos y evite las del plano de control, como se describe en [REL11-BP04 Confiar en el plano de datos y no en el plano de control durante la recuperación](rel_withstand_component_failures_avoid_control_plane.md).
Para obtener más información sobre esta y otras opciones, consulte [esta sección del documento técnico sobre recuperación de desastres](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **Diseñe un plan para la recuperación tras error de su carga de trabajo.**
La recuperación tras error es cuando se devuelve la operación de una carga de trabajo a la región principal una vez que amaina un evento de desastre. El aprovisionamiento de la infraestructura y el código en la región principal generalmente sigue los mismos pasos que se utilizaron inicialmente, recurriendo a la infraestructura como código y las canalizaciones de despliegue del código. El reto que plantea la recuperación tras error es restaurar los almacenes de datos y asegurarse de que sean coherentes con la región de recuperación en funcionamiento.
En el estado de conmutación por error, las bases de datos en la región de recuperación están activas y tienen los datos actualizados. El objetivo es resincronizar desde la región de recuperación a la región principal, garantizando así que esté actualizada.
Algunos servicios de AWS harán esto automáticamente. Si utiliza [tablas globales de Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/), incluso si la tabla en la región principal ha dejado de estar disponible, cuando vuelva a estar online, DynamoDB volverá a propagar las escrituras pendientes. Si utiliza [una base de datos global de Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) y utiliza la [conmutación por error planificada administrada](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), entonces se mantiene la topología de replicación existente de la base de datos global de Aurora. Por tanto, la instancia de lectoescritura anterior en la región principal se convertirá en una réplica y recibirá actualizaciones desde la región de recuperación.
En los casos en los que esto no se haga automáticamente, tendrá que restablecer la base de datos en la región principal como una réplica de la base de datos en la región de recuperación. En muchos casos, esto supondrá eliminar la antigua base de datos principal y crear nuevas réplicas. Por ejemplo, para ver instrucciones sobre cómo hacer esto con una base de datos global de Amazon Aurora suponiendo una conmutación por error *no planificada* , consulte este laboratorio: [Recuperación tras error de una base de datos global](https://awsauroralabsmy.com/global/failback/).
Tras una conmutación por error, si puede seguir operando en su región de recuperación, plantéese convertir esta región en la nueva región principal. Seguiría realizando los pasos anteriores para hacer que la antigua región principal fuera una región de recuperación. Algunas organizaciones llevan a cabo una rotación programada y cambian sus regiones principal y de recuperación periódicamente (por ejemplo, cada tres meses).
Todos los pasos necesarios para la conmutación por error y la restauración tras error deben mantenerse en una guía de estrategias que esté a disposición de todos los miembros del equipo y se revise periódicamente.
**Nivel de esfuerzo para el plan de implementación**: alto
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL09-BP01 Identificar todos los datos de los que se debe hacer una copia de seguridad y crearla o reproducir los datos a partir de los orígenes](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Confiar en el plano de datos y no en el plano de control durante la recuperación](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 Definir objetivos de recuperación para la inactividad y la pérdida de datos](rel_planning_for_recovery_objective_defined_recovery.md)
**Documentos relacionados:**
+ [Blog de arquitectura de AWS: serie de recuperación de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperación de desastres de las cargas de trabajo en AWS: recuperación en la nube (documento técnico de AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Opciones de recuperación de desastres en la nube](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Crear una solución backend activa-activa sin servidor en varias regiones en una hora](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Backend sin servidor en varias regiones: actualizado](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: replicación de una réplica de lectura entre regiones](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: configuración de la conmutación por error de DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: replicación entre regiones](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [¿Qué es AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [¿Qué es Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: primeros pasos - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [Socio de APN: socios que pueden ayudar con la recuperación de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: productos que pueden usarse para la recuperación de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Vídeos relacionados:**
+ [Recuperación de desastres de cargas de trabajo en AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: patrones de arquitectura para aplicaciones activas-activas en varias regiones (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Introducción a AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**Ejemplos relacionados:**
+ [Laboratorios de AWS Well-Architected : recuperación de desastres](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - Serie de talleres en los que se ilustran las estrategias de DR
# REL13-BP03 Probar la implementación de recuperación de desastres para validarla
Compruebe habitualmente la conmutación por error a su sitio de recuperación para garantizar un funcionamiento adecuado y que se cumplan el RTO y el RPO.
Un patrón que debe evitarse es el desarrollo de rutas de recuperación que se pongan en práctica pocas veces. Por ejemplo, puede tener un almacén de datos secundario que se utilice para consultas de solo lectura. Cuando escribe en un almacén de datos y el almacén principal falla, es posible que quiera conmutar por error al almacén de datos secundario. Si no se prueba frecuentemente esta conmutación por error, es posible que sus suposiciones sobre las capacidades del almacén de datos secundario sean incorrectas. Es posible que la capacidad del almacén de datos secundario, que quizás fuera suficiente cuando se probó por última vez, ya no pueda tolerar la carga en esta situación. Nuestra experiencia ha demostrado que la única forma de recuperación de errores que funciona es aquella que prueba constantemente. Por ello, es mejor tener un número reducido de rutas de recuperación. Puede establecer patrones de recuperación y probarlos con frecuencia. Si tiene una ruta de recuperación compleja o crítica, todavía debe llevar a efecto ese error en producción periódicamente para asegurarse de que la ruta funcione. En el ejemplo que acabamos de comentar, se debe conmutar por error al modo de espera con regularidad, sin importar si es necesario.
**Patrones de uso no recomendados comunes:**
+ No llevar a cabo nunca conmutaciones por error en producción.
**Beneficios de establecer esta práctica recomendada:** Las pruebas periódicas del plan de recuperación de desastres garantizan que el plan funcione cuando llegue el momento y que su equipo sepa cómo ejecutar la estrategia.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Diseñe sus cargas de trabajo para que se puedan recuperar. Compruebe periódicamente sus rutas de recuperación. La informática orientada a la recuperación identifica las características en los sistemas que mejoran la recuperación. Estas características son: aislamiento y redundancia, capacidad en todo el sistema para revertir los cambios, capacidad para supervisar y determinar el estado, capacidad para proporcionar diagnósticos, recuperación automatizada, diseño modular y capacidad para reiniciar. Ponga en práctica la ruta de recuperación para asegurarse de que pueda cumplir la recuperación en el tiempo especificado para el estado especificado. Use sus runbooks durante esta recuperación para documentar los problemas y encontrar soluciones para ellos antes de la próxima prueba.
+ [Proyecto de informática orientada a la recuperación de Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ Use Recuperación de desastres de CloudEndure para implementar y probar su estrategia de recuperación de desastres.
+ [Probar la solución de recuperación de desastres con CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Recuperación de desastres de CloudEndure en AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudar con la recuperación de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog de arquitectura de AWS: serie de recuperación de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: productos que pueden usarse para la recuperación de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Recuperación de desastres de las cargas de trabajo en AWS: recuperación en la nube (documento técnico de AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Probar la solución de recuperación de desastres con CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [Proyecto de informática orientada a la recuperación de Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ [¿Qué es AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Patrones de arquitectura para aplicaciones activas-activas en varias regiones (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Copia de seguridad y restauración y soluciones de recuperación de desastres con AWS (STG208)](https://youtu.be/7gNXfo5HZN8)
**Ejemplos relacionados:**
+ [Laboratorios de AWS Well-Architected: comprobación de resiliencia](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 Administrar la desviación de la configuración en el sitio de o en la región de recuperación de desastres
Asegúrese de que la infraestructura, los datos y la configuración estén cuando se necesiten en el sitio o región de DR. Por ejemplo, compruebe que las AMI y las cuotas de servicio están actualizadas.
AWS Config supervisa y registra continuamente las configuraciones de sus recursos de AWS. Puede detectar la desviación y desencadenar [Automatización de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) para solucionarlo y generar alarmas. Además, AWS CloudFormation puede detectar la desviación en las pilas que ha desplegado.
**Patrones de uso no recomendados comunes:**
+ No realizar actualizaciones en sus ubicaciones de recuperación, cuando realice cambios de configuración o de infraestructura en sus ubicaciones primarias.
+ No considerar las posibles limitaciones (como las diferencias en los servicios) en las ubicaciones principales y de recuperación.
**Beneficios de establecer esta práctica recomendada:** Comprobar que su entorno de DR es coherente con el entorno existente garantiza una recuperación completa.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Asegúrese de que sus canalizaciones de entrega realizan la entrega tanto al sitio principal como al de copia de seguridad. Las canalizaciones de entrega para implementar aplicaciones en producción deben distribuir la entrega a todas las ubicaciones de la estrategia de recuperación de desastres especificadas, incluidos los entornos de desarrollo y pruebas.
+ Habilite AWS Config para realizar un seguimiento de las posibles ubicaciones con desviaciones. Use reglas de AWS Config para crear sistemas que apliquen sus estrategias de recuperación de desastres y creen alertas si detectan divergencias.
+ [Corrección de recursos de AWS disconformes con Reglas de AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [Automatización de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Use AWS CloudFormation para desplegar su infraestructura. AWS CloudFormation puede detectar la desviación entre lo que especifican sus plantillas de CloudFormation y lo que realmente está desplegado.
+ [AWS CloudFormation: detectar desviaciones en una pila completa de CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudar con la recuperación de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog de arquitectura de AWS: serie de recuperación de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation: detectar desviaciones en una pila completa de CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Marketplace: productos que pueden usarse para la recuperación de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [Automatización de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Recuperación de desastres de las cargas de trabajo en AWS: recuperación en la nube (documento técnico de AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [¿Cómo implemento una solución de administración de la configuración de la infraestructura en AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Corrección de recursos de AWS disconformes con Reglas de AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Patrones de arquitectura para aplicaciones activas-activas en varias regiones) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05 Automatizar la recuperación
Use AWS o herramientas de terceros para automatizar la recuperación del sistema y dirigir el tráfico al sitio o región de DR.
En función de las comprobaciones de estado configuradas, los servicios de AWS, como Elastic Load Balancing y AWS Auto Scaling, pueden distribuir la carga a zonas de disponibilidad en buen estado mientras que los servicios, como Amazon Route 53 y AWS Global Accelerator, pueden dirigir la carga a Regiones de AWS en buen estado. Amazon Route 53 Application Recovery Controller le ayuda a administrar y coordinar la conmutación por error mediante comprobaciones de idoneidad y funciones de control de enrutamiento. Estas características supervisan continuamente la capacidad de la aplicación de recuperarse de los errores, de modo que pueda controlar la recuperación de la aplicación en las distintas Regiones de AWS, zonas de disponibilidad y localmente.
Para cargas de trabajo en centros de datos físicos o virtuales existentes o nubes privadas, [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/), disponible en AWS Marketplace, permite a las organizaciones configurar una estrategia de recuperación de desastres automatizada en AWS. CloudEndure también admite la recuperación de desastres entre regiones o AZ en AWS.
**Antipatrones usuales:**
+ La implementación de técnicas de conmutación por error y de conmutación por recuperación idénticas puede producir una alteración cuando surge un error.
**Beneficios de establecer esta práctica recomendada:** La recuperación automatizada reduce el tiempo de recuperación al eliminar la posibilidad de que se produzcan errores manuales.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Automatice las rutas de recuperación. Para tiempos de recuperación cortos, las decisiones y las acciones humanas no pueden usarse para escenarios de alta disponibilidad. El sistema debe recuperarse automáticamente en cada situación.
+ Use la recuperación de desastres de Cloudendure para la conmutación por error y la restauración tras error automatizadas. La recuperación de desastres de CloudEndure replica continuamente las máquinas (incluido el sistema operativo, la configuración de estado del sistema, las bases de datos, las aplicaciones y los archivos) en un área de ensayo de bajo costo en su Cuenta de AWS de destino y región preferida. En caso de desastre, puede indicar a CloudEndure Disaster Recovery que lance automáticamente miles de máquinas en su estado aprovisionado completo en solo unos minutos.
+ [Realizar la conmutación por error y la conmutación por recuperación de recuperación de desastres](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudar con la recuperación de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog de arquitectura de AWS: serie de recuperación de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: productos que pueden usarse para la recuperación de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Recuperación de desastres de CloudEndure en AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [Recuperación de desastres de las cargas de trabajo en AWS: recuperación en la nube (documento técnico de AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**Videos relacionados:**
+ [AWS re:Invent 2018: Patrones de arquitectura para aplicaciones activas-activas en varias regiones (ARC209-R2)](https://youtu.be/2e29I3dA8o4)