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