# Fiabilidad
**Topics**
+ [Fundamentos](a-foundations.md)
+ [Arquitectura de la carga de trabajo](a-workload-architecture.md)
+ [Administración de cambios](a-change-management.md)
+ [Administración de errores](a-failure-management.md)
# Fundamentos
**Topics**
+ [REL 1 ¿Cómo administra las cuotas de servicio y las restricciones?](w2aac19b9b5b5.md)
+ [REL 2 ¿Cómo planifica la topología de la red?](w2aac19b9b5b7.md)
# REL 1 ¿Cómo administra las cuotas de servicio y las restricciones?
Para las arquitecturas de carga de trabajo basadas en la nube, existen cuotas de servicio (que también se denominan límites de servicio). Estas cuotas existen para evitar aprovisionar por accidente más recursos de los necesarios y para limitar las tasas de solicitud en las operaciones de la API de modo que los servicios queden protegidos ante posibles abusos. También existen limitaciones de recursos, por ejemplo, la velocidad a la que se pueden introducir bits en un cable de fibra óptica o la cantidad de almacenamiento de un disco físico.
**Topics**
+ [REL01-BP01 Conocimiento de las cuotas y restricciones del servicio](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 Administrar cuotas de servicio entre cuentas y regiones](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 Adaptar las cuotas de servicio fijas y las restricciones a través de la arquitectura](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 Supervisar y administrar cuotas](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 Automatizar la administración de cuotas](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 Garantizar que exista una diferencia suficiente entre las cuotas actuales y el uso máximo para permitir la conmutación por error](rel_manage_service_limits_suff_buffer_limits.md)
# REL01-BP01 Conocimiento de las cuotas y restricciones del servicio
Está al tanto de sus cuotas predeterminadas y de las solicitudes de aumento de cuota para su arquitectura de carga de trabajo. Además, sabe qué restricciones de recursos, como el disco o la red, pueden causar impacto.
Service Quotas es un servicio de AWS que le ayuda a administrar sus cuotas para más de 100 servicios de AWS desde una sola ubicación. Además de consultar los valores de las cuotas, también puede solicitar y realizar un seguimiento de los aumentos de las cuotas desde la consola de Service Quotas o a través del SDK de AWS. AWS Trusted Advisor ofrece una comprobación de las cuotas de servicio que muestra su uso y las cuotas para algunos aspectos de algunos servicios. Las cuotas de servicio predeterminadas por servicio también están en la documentación de AWS del servicio respectivo, por ejemplo, consulte [Cuotas de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html). Los límites de velocidad en las API limitadas se establecen en API Gateway mediante la configuración de un plan de uso. Otros límites que se establecen como configuración en sus respectivos servicios son las IOPS aprovisionadas, el almacenamiento de RDS asignado y las asignaciones de volumen EBS. Amazon Elastic Compute Cloud (Amazon EC2) tiene su propio panel de límites de servicio que puede ayudarle a administrar sus límites de instancia, Amazon Elastic Block Store (Amazon EBS) y de dirección IP elástica. Si tiene un caso de uso en el que las cuotas de servicio repercuten en el rendimiento de su aplicación y no se ajustan a sus necesidades, contacte con AWS Support para ver si existen mitigaciones.
**Patrones de uso no recomendados comunes:**
+ Desplegar una carga de trabajo sin tener en cuenta las cuotas de los servicios de AWS utilizados.
+ Diseñar una carga de trabajo sin investigar ni tener en cuenta las restricciones de diseño de los servicios de AWS.
+ Desplegar una carga de trabajo con un uso significativo que reemplaza una carga de trabajo existente conocida sin configurar las cuotas necesarias ni contactar con AWS Support con antelación.
+ Planificar un evento para atraer tráfico a su carga de trabajo, pero no configurar las cuotas necesarias ni contactar con AWS Support con antelación.
**Beneficios de establecer esta práctica recomendada:** conocer las cuotas de servicio, las limitaciones de la API y las restricciones de diseño le permitirá tenerlas en cuenta en su diseño, implementación y funcionamiento de la carga de trabajo.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Revise las cuotas de servicio de AWS en la documentación publicada y Service Quotas
+ [AWS Service Quotas (antes se denominaban límites)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ Consulte el código de despliegue para determinar todos los servicios que necesita su carga de trabajo.
+ Use AWS Config para encontrar todos los recursos de AWS que se usan en sus Cuentas de AWS.
+ [AWS Config Supported AWS Resource Types and Resource Relationships (Tipos de recursos de AWS admitidos por AWS Config y relaciones de recursos)](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)
+ También puede usar su AWS CloudFormation para determinar los recursos de AWS utilizados. Examine los recursos que se han creado en la Consola de administración de AWS o mediante el comando list-stack-resources de la CLI. También puede ver los recursos configurados para desplegarse en la propia plantilla.
+ [Visualización de recursos y datos de la pila de AWS CloudFormation en la Consola de administración de AWS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html)
+ [AWS CLI para CloudFormation: list-stack-resources](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html)
+ Determine las cuotas de servicio que se aplican. Utilice la información accesible mediante programación a través de Trusted Advisor y Service Quotas.
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: productos de CMDB que ayudan a hacer un seguimiento de los límites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (denominados anteriormente límites de servicio)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Comprobaciones de prácticas recomendadas de AWS Trusted Advisor (consulte la sección Límites de servicio)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Limit Monitor en AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Límites de servicio de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [¿Qué es Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP02 Administrar cuotas de servicio entre cuentas y regiones
Si utiliza múltiples Cuentas de AWS o Regiones de AWS, asegúrese de que solicita las cuotas pertinentes en todos los entornos en los que se ejecutan sus cargas de trabajo de producción.
Las cuotas de servicio se controlan por cuenta. A no ser que se especifique lo contrario, cada cuota es específica a una Región de AWS. Además de los entornos de producción, administre también las cuotas en todos los entornos que no sean de producción pertinentes, de modo que las pruebas y el desarrollo no se vean limitados.
**Patrones de uso no recomendados comunes:**
+ Permitir que el uso de recursos en una zona aislada crezca sin ningún mecanismo que mantenga la capacidad en las demás.
+ Configurar manualmente todas las cuotas independientemente en las zonas de aislamiento.
+ No garantizar que los despliegues aislados regionalmente tengan el tamaño adecuado para dar cabida al incremento de tráfico desde otra región si se pierde un despliegue.
**Beneficios de establecer esta práctica recomendada:** al asegurarse de que puede afrontar su carga actual si una zona de aislamiento no está disponible, puede contribuir a reducir el número de errores que se producen durante la conmutación por error, en lugar de causar una denegación de servicio a los clientes.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Seleccione las cuentas y regiones que correspondan según sus requisitos de servicio, latencia, normativos y de recuperación de desastres (DR).
+ Identifique las cuotas de servicio en todas las cuentas, regiones y zonas de disponibilidad relevantes. Los límites están delimitados por cuenta y región.
+ [¿Qué es Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: productos de CMDB que ayudan a controlar los límites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (denominados anteriormente límites de servicio)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Comprobaciones de prácticas recomendadas de AWS Trusted Advisor (consulte la sección Límites de servicio)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Monitor de límites de AWS en las respuestas de AWS AWS](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [¿Qué es Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP03 Adaptar las cuotas de servicio fijas y las restricciones a través de la arquitectura
Conozca las cuotas de servicio y los recursos físicos no modificables, y realice el diseño para evitar que afecten a la fiabilidad.
Entre los ejemplos se encuentran el ancho de banda de la red, el tamaño de la carga útil AWS Lambda, la tasa de ampliación de limitación para API Gateway y las conexiones de usuarios simultáneas a un clúster de Amazon Redshift.
**Patrones de uso no recomendados comunes:**
+ Realizar la evaluación comparativa durante un periodo de tiempo demasiado breve, usar el límite de ampliación y, a continuación, esperar que el servicio rinda a esa capacidad durante periodos sostenidos.
+ Elegir un diseño que utilice un recurso de un servicio por usuario o cliente, sin saber que existen restricciones de diseño que provocarán que este diseño producirá un error en el escalado.
**Beneficios de establecer esta práctica recomendada:** el seguimiento de las cuotas fijas en los servicios de AWS y de las restricciones en otras partes de su carga de trabajo, como las restricciones de conectividad, las restricciones de direcciones IP y las restricciones en los servicios de terceros, le permite detectar cuándo se acerca a una cuota y le da la posibilidad de corregir la cuota antes de que se supere.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Conozca las cuotas de servicio fijas: conozca las cuotas de servicio fijas y las restricciones, y realice la arquitectura en torno a ellas.
+ [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: productos de CMDB que ayudan a hacer un seguimiento de los límites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (denominados anteriormente límites de servicio)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Comprobaciones de prácticas recomendadas de AWS Trusted Advisor (consulte la sección Límites de servicio)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Limit Monitor en AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Límites de servicio de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [¿Qué es Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP04 Supervisar y administrar cuotas
Evalúe el uso potencial y aumente las cuotas pertinentemente, permitiendo un crecimiento planificado del uso.
Para los servicios compatibles, puede administrar sus cuotas configurando alarmas de CloudWatch para supervisar el uso y alertarle cuando se aproxime el cumplimiento de las cuotas. Estas alarmas se pueden desencadenar desde Service Quotas o desde Trusted Advisor. También puede usar filtros de métricas en CloudWatch Logs para buscar y extraer patrones en registros de modo que pueda determinar si el uso se aproxima a los umbrales de las cuotas.
**Patrones de uso no recomendados comunes:**
+ Configurar alarmas de aproximación para Service Quotas sin contar con ningún proceso para responder a una alerta.
+ Configurar solamente alarmas para servicios compatibles con Service Quotas y no supervisar otros servicios.
**Beneficios de establecer esta práctica recomendada:** el control automático de las cuotas de servicio de AWS y la supervisión del uso en comparación con dichas cuotas le permitirá comprobar cuándo se acerca al límite de una cuota. También puede usar estos datos de supervisión para evaluar cuándo podría reducir las cuotas para ahorrar costes.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Supervise y administre sus cuotas. Evalúe el uso potencial en AWS, aumente sus cuotas de servicio regionales convenientemente y permita un crecimiento planificado del uso.
+ Capture el consumo de recursos actual (por ejemplo, buckets o instancias). Use operaciones de API de servicios como la API DescribeInstances de Amazon EC2 para recopilar el consumo de recursos actual.
+ Capture sus cuotas actuales. Use AWS Service Quotas, AWS Trusted Advisor y la documentación de AWS.
+ Use AWS Service Quotas, un servicio de AWS que le ayuda a administrar sus cuotas para más de 100 servicios de AWS desde una ubicación.
+ Use los límites de servicio de Trusted Advisor para determinar los límites de servicio actuales.
+ Use operaciones de API de servicio para determinar las cuotas de servicio actuales donde sea compatible.
+ Mantenga un registro de los aumentos de cuota que se han solicitado y sus estados. Después de haber aprobado un aumento de la cuota, asegúrese de actualizar sus registros para que se refleje el cambio de cuota.
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: productos de CMDB que ayudan a hacer un seguimiento de los límites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (denominadas anteriormente límites de servicio)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Comprobaciones de prácticas recomendadas de AWS Trusted Advisor para límites de servicio](https://docs.aws.amazon.com/awssupport/latest/user/service-limits.html)
+ [AWS Limit Monitor en las respuestas de AWS](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Límites de servicio de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [¿Qué es Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [Supervisión de Service Quotas con alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP05 Automatizar la administración de cuotas
Implemente herramientas para alertarle cuando se acerque a los límites. Puede automatizar las solicitudes de incremento de cuotas utilizando las API de AWS Service Quotas y automatizar las solicitudes de incremento de cuotas.
Si integra su base de datos de administración de configuraciones (CMDB) o su sistema de emisión de tiques con Service Quotas, puede automatizar el seguimiento de las solicitudes de aumento de cuotas y las cuotas actuales. Además del SDK de AWS, Service Quotas ofrece automatización utilizando AWS Command Line Interface (AWS CLI).
**Patrones de uso no recomendados comunes:**
+ Realizar el seguimiento de las cuotas y el uso en hojas de cálculo.
+ Ejecutar informes de uso cada día, semana o mes y después comparar el uso con las cuotas.
**Beneficios de establecer esta práctica recomendada:** El control automático de las cuotas de servicio de AWS y la supervisión del uso en comparación con dichas cuotas le permite comprobar cuándo se acerca a una cuota. Puede configurar la automatización para que le ayude a solicitar un aumento de cuota cuando resulte necesario. Es posible que quiera plantearse la reducción de algunas cuotas cuando su uso adopte una tendencia opuesta para materializar los beneficios de un menor riesgo (en caso de que sus credenciales se hayan visto comprometidas) y el ahorro de costes.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Configure una supervisión automatizada. Implemente herramientas con SDK para alertarle cuando se acerque a los límites.
+ Utilice Service Quotas y potencie el servicio con una solución de supervisión de cuotas automatizada, como AWS Limit Monitor o una oferta de AWS Marketplace.
+ [¿Qué es Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [Supervisor de cuotas en AWS: solución de AWS](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ Configure respuestas desencadenadas en función de umbrales de cuotas con las API de Amazon SNS y AWS Service Quotas.
+ Automatización de pruebas.
+ Configure umbrales de límites.
+ Integre con eventos de cambio de AWS Config, canalizaciones de despliegue, Amazon EventBridge o terceros.
+ Defina de forma artificial umbrales de cuota bajos para probar las respuestas.
+ Configure desencadenadores para realizar acciones pertinentes en las notificaciones y póngase en contacto con AWS Support cuando sea necesario.
+ Desencadene manualmente eventos de cambio.
+ Ejecute un día de juego para probar el proceso de cambio de aumento de cuotas.
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudar con la administración de la configuración](https://aws.amazon.com/partners/find/results/?keyword=Configuration+Management)
+ [AWS Marketplace: productos de CMDB que ayudan a hacer un seguimiento de los límites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (denominadas anteriormente límites de servicio)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Comprobaciones de prácticas recomendadas de AWS Trusted Advisor (consulte la sección Límites de servicio)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Supervisor de cuotas en AWS: solución de AWS](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Límites de servicio de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [¿Qué es Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP06 Garantizar que exista una diferencia suficiente entre las cuotas actuales y el uso máximo para permitir la conmutación por error
Cuando un recurso falla, puede que se siga contando con respecto a las cuotas hasta que se finalice correctamente. Asegúrese de que sus cuotas usen sustituciones para cubrir la superposición de todos los recursos con errores antes de que se finalicen dichos recursos. Debe tener en cuenta un error de zona de disponibilidad al calcular esta diferencia.
**Patrones de uso no recomendados comunes:**
+ Establecer cuotas de servicio sobre la base de las necesidades actuales sin tener en cuenta los casos de conmutación por error.
**Beneficios de establecer esta práctica recomendada:** cuando los eventos tienen un impacto potencial sobre la disponibilidad, la nube le permite llevar a cabo estrategias para mitigar estos eventos o recuperarse de ellos. Estas estrategias suelen incluir la creación de recursos adicionales para sustituir aquellos que han experimentado algún error. Su estrategia de cuotas debe dar cabida a estos recursos adicionales.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Asegúrese de que haya una diferencia suficiente entre la cuota de servicio y el uso máximo para permitir la conmutación por error.
+ Determine sus cuotas de servicio, teniendo en cuenta sus patrones de despliegue, los requisitos de disponibilidad y el crecimiento del consumo.
+ Solicite aumentos de la cuota si fuera necesario. Planifique el tiempo necesario para que se cumplan las solicitudes de aumentos de cuotas.
+ Determine sus requisitos de fiabilidad (también conocidos como «número de nueves»).
+ Establezca sus escenarios de error (por ejemplo, la pérdida de componentes, una zona de disponibilidad o una región).
+ Establezca su metodología de despliegue (por ejemplo, valor controlado, azul-verde, rojo-negro o continua).
+ Incluya un búfer adecuado (por ejemplo, del 15 %) en el límite actual.
+ Planifique el crecimiento de consumo (por ejemplo, supervise sus tendencias de consumo).
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: productos de CMDB que ayudan a hacer un seguimiento de los límites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (denominadas anteriormente límites de servicio)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Comprobaciones de prácticas recomendadas de AWS Trusted Advisor (consulte la sección Límites de servicio)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Límites de servicio de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [¿Qué es Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL 2 ¿Cómo planifica la topología de la red?
Suele haber cargas de trabajo en distintos entornos. Entre estos se incluyen los entornos de la nube (tanto públicamente accesibles como privados), y posiblemente la infraestructura del centro de datos existente. Los planes deben incluir consideraciones, como la conectividad dentro de los sistemas y entre ellos, la administración de las direcciones IP públicas, la administración de las direcciones IP privadas y la resolución de nombres de dominio.
**Topics**
+ [REL02-BP01 Usar conectividad de red de alta disponibilidad para los puntos de conexión públicos de la carga de trabajo](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 Aprovisionar conectividad redundante entre las redes privadas en la nube y los entornos locales](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 Garantizar que la asignación de subredes IP tenga en cuenta la expansión y la disponibilidad](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 Preferir topologías radiales (hub-and-spoke) a una conexión en malla de varios a varios](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 Emplear intervalos no superpuestos de direcciones IP privadas en todos los espacios de direcciones privadas que estén conectados](rel_planning_network_topology_non_overlap_ip.md)
# REL02-BP01 Usar conectividad de red de alta disponibilidad para los puntos de conexión públicos de la carga de trabajo
Estos puntos de conexión y el enrutamiento a ellos deben estar altamente disponibles. Para conseguirlo, use DNS, redes de entrega de contenido (CDN), API Gateway, un equilibrador de carga o proxies inversos con una alta disponibilidad.
Amazon Route 53, AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway y Elastic Load Balancing (ELB) proporcionan puntos de conexión públicos de alta disponibilidad. También puede interesarle evaluar los dispositivos de software de AWS Marketplace que proporcionen equilibrio de carga o uso de proxies.
Los consumidores del servicio que proporciona su carga de trabajo, ya sean usuarios finales u otros servicios, realizan solicitudes en estos puntos de conexión del servicio. Existen varios recursos de AWS que le permiten ofrecer puntos de conexión de alta disponibilidad.
Elastic Load Balancing proporciona equilibrio de carga en las zonas de disponibilidad, realiza el enrutamiento de la capa 4 (TCP) o de la capa 7 (http/https), se integra con AWS WAF y se integra con AWS Auto Scaling para crear una infraestructura de autorreparación y absorber el aumento de tráfico a la vez que libera recursos cuando este disminuye.
Amazon Route 53 es un servicio de sistema de nombres de dominio (DNS) escalable y de alta disponibilidad que conecta las solicitudes de usuario con la infraestructura que se ejecuta en AWS, como instancias de Amazon EC2, equilibradores de carga de Elastic Load Balancing o buckets de Amazon S3, y que también puede utilizarse para enrutar a los usuarios a la infraestructura fuera de AWS.
AWS Global Accelerator es un servicio de capa de red que puede utilizar para dirigir el tráfico a puntos de conexión óptimos a través de la red global de AWS.
Los ataques de denegación de servicio distribuido (DDoS) amenazan con cerrar el tráfico legítimo y reducir la disponibilidad para sus usuarios. AWS Shield proporciona protección automática contra estos ataques sin coste adicional para los puntos de conexión de servicio de AWS en su carga de trabajo. Puede aumentar estas características con dispositivos virtuales de los socios de APN y AWS Marketplace para satisfacer sus necesidades.
**Patrones de uso no recomendados comunes:**
+ Usar direcciones de Internet públicas en instancias o contenedores y administrar la conectividad a ellas a través de DNS
+ Usar direcciones IP (protocolo de Internet) en lugar de nombres de dominio para localizar los servicios
+ Proporcionar contenido (páginas web, activos estáticos, archivos multimedia) a una gran área geográfica y no usar una red de entrega de contenido
**Beneficios de establecer esta práctica recomendada:** Al implementar servicios altamente disponibles en su carga de trabajo, sabrá que esta carga de trabajo está disponible para sus usuarios.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
Asegúrese de que dispone de conectividad de alta disponibilidad para los usuarios de la carga de trabajo. Amazon Route 53, AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway y Elastic Load Balancing (ELB) proporcionan puntos de conexión de alta disponibilidad públicos. También puede interesarle evaluar los dispositivos de software de AWS Marketplace que proporcionen equilibrio de carga o uso de proxies.
+ Asegúrese de que tiene una conexión de alta disponibilidad con sus usuarios.
+ Asegúrese de que utiliza un DNS de alta disponibilidad para administrar los nombres de dominio de los puntos de conexión de la aplicación.
+ Si los usuarios acceden a su aplicación a través de Internet, use las operaciones de la API del servicio para confirmar el uso correcto de las puertas de enlace de Internet. Confirme también que las entradas de las tablas de enrutamiento de las subredes que alojan los puntos de conexión de su aplicación son correctas.
+ [DescribeInternetGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInternetGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ Asegúrese de que utiliza un proxy inverso o equilibrador de carga de alta disponibilidad ante su aplicación.
+ Si los usuarios acceden a su aplicación a través de su entorno local, asegúrese de que la conectividad entre AWS y su entorno local tenga alta disponibilidad.
+ Use Route 53 para administrar los nombres de dominio.
+ [¿Qué es Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ Utilice un proveedor de DNS de terceros que satisfaga sus requisitos.
+ Use Elastic Load Balancing.
+ [¿Qué es Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ Utilice un dispositivo de AWS Marketplace que satisfaga sus requisitos.
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudarle a planificar sus redes](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Recomendaciones sobre resiliencia de AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [AWS Marketplace para la infraestructura de red](https://aws.amazon.com/marketplace/b/2649366011)
+ [Documento técnico sobre las opciones de conectividad de Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Conectividad de red de alta disponibilidad en varios centros de datos](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Usar el kit de herramientas de resiliencia de Direct Connect para empezar](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [Puntos de conexión de VPC y servicios de punto de conexión de VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [¿Qué es AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [¿Qué es Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [¿Qué es una puerta de enlace de tránsito?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [¿Qué es Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [¿Qué es Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [¿Qué es Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Trabajar con puertas de enlace de Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (Diseño avanzado de VPC y funciones nuevas de Amazon VPC) (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (Arquitecturas de referencia de AWS Transit Gateway para muchas VPC) (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP02 Aprovisionar conectividad redundante entre las redes privadas en la nube y los entornos locales
Use varias conexiones de AWS Direct Connect o túneles VPN entre redes privadas desplegadas por separado. Use varias ubicaciones de Direct Connect para tener alta disponibilidad. Si utiliza varias Regiones de AWS, garantice la redundancia en al menos dos de ellas. Puede interesarle evaluar dispositivos de AWS Marketplace que terminen las VPN. Si utiliza dispositivos de AWS Marketplace, implemente instancias redundantes para obtener alta disponibilidad en diferentes zonas de disponibilidad.
AWS Direct Connect es una solución de servicios en la nube que facilita el establecimiento de una conexión de red dedicada desde su entorno local a AWS. Gracias a Direct Connect Gateway, su centro de datos local puede conectarse a varias VPC de AWS repartidas por varias Regiones de AWS.
Esta redundancia soluciona los posibles errores que afectan a la resiliencia de la conectividad:
+ ¿Cómo puede resistir los errores su topología?
+ ¿Qué pasa si no configuro correctamente algo y elimino la conectividad?
+ ¿Podrá gestionar un aumento inesperado del tráfico o del uso de sus servicios?
+ ¿Podrá absorber un intento de ataque de denegación de servicio distribuido (DDoS)?
Cuando conecte su VPC a su centro de datos local a través de una VPN, deberá tener en cuenta los requisitos de resiliencia y ancho de banda que necesita cuando seleccione el proveedor y el tamaño de la instancia en la que necesita ejecutar el dispositivo. Si usa un dispositivo VPN que no es resistente en su implementación, debe tener una conexión redundante mediante un segundo dispositivo. Para todas estas situaciones, debe definir un tiempo aceptable para la recuperación y hacer pruebas para asegurarse de que puede cumplir esos requisitos.
Si decide conectar su VPC a su centro de datos mediante una conexión de Direct Connect y necesita que esta conexión tenga una alta disponibilidad, disponga de conexiones de Direct Connect redundantes desde cada centro de datos. La conexión redundante debe utilizar una segunda conexión de Direct Connect desde una ubicación diferente a la primera. Si tiene varios centros de datos, asegúrese de que las conexiones terminen en diferentes ubicaciones. Use el [kit de herramientas de resiliencia de Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) como ayuda para su configuración.
Si decide conmutar por error a una VPN por Internet mediante Site-to-Site VPN, es importante entender que admite hasta 1,25 Gbps de rendimiento por túnel VPN, pero no admite rutas múltiples de igual coste (ECMP) para el tráfico de salida en el caso de múltiples túneles de AWS Managed VPN que terminen en el mismo VGW. No le recomendamos que utilice AWS Managed VPN como respaldo de las conexiones de Direct Connect, a menos que pueda tolerar velocidades inferiores a 1 Gbps durante la conmutación por error.
También puede utilizar los puntos de conexión de VPC para conectar de forma privada la VPC a los servicios de AWS admitidos y a los servicios de punto de conexión de VPC con tecnología de AWS PrivateLink sin atravesar la Internet pública. Los puntos de conexión son dispositivos virtuales. Son componentes de VPC escalados horizontalmente, redundantes y de alta disponibilidad. Permiten la comunicación entre las instancias de la VPC y los servicios sin que ello suponga riesgos de disponibilidad o restricciones de ancho de banda en el tráfico de su red.
**Patrones de uso no recomendados comunes:**
+ Tener un solo proveedor de conectividad entre la red local y AWS.
+ Usar las funciones de conectividad de la conexión de AWS Direct Connect, pero tener una sola conexión.
+ Tener una sola ruta para su conectividad de VPN
**Beneficios de establecer esta práctica recomendada:** al implementar la conectividad redundante entre el entorno en la nube y su entorno corporativo o local, puede garantizar que los servicios dependientes entre los entornos se puedan comunicar sin problemas.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Asegúrese de que tiene conectividad de alta disponibilidad entre AWS y el entorno local. Use varias conexiones de AWS Direct Connect o túneles VPN entre redes privadas desplegadas por separado. Use varias ubicaciones de Direct Connect para tener alta disponibilidad. Si utiliza varias Regiones de AWS, garantice la redundancia en al menos dos de ellas. Puede interesarle evaluar dispositivos de AWS Marketplace que terminen las VPN. Si utiliza dispositivos de AWS Marketplace, implemente instancias redundantes para obtener alta disponibilidad en diferentes zonas de disponibilidad.
+ Asegúrese de que dispone de una conexión redundante a su entorno local. Es posible que necesite conexiones redundantes a múltiples Regiones de AWS para lograr sus necesidades de disponibilidad.
+ [Recomendaciones sobre resiliencia de AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [Usar conexiones de VPN de sitio a sitio para proporcionar conmutación por error](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ Use operaciones de la API de servicio para identificar el uso correcto de los circuitos de AWS Direct Connect.
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ Si solo existe una conexión de Direct Connect o no existe ninguna, configure túneles VPN redundantes hacia sus puertas de enlace privadas virtuales.
+ [¿Qué es AWS Site-to-Site VPN?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ Capture su conectividad actual (por ejemplo, Direct Connect, puertas de enlace privadas virtuales, dispositivos de AWS Marketplace).
+ Use operaciones de la API de servicio para consultar la configuración de las conexiones de Direct Connect.
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ Utilice las operaciones de la API de servicios para recopilar las puertas de enlace privadas virtuales cuando las tablas de enrutamiento las utilicen.
+ [DescribeVpnGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpnGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ Utilice las operaciones de la API de servicios para recopilar las aplicaciones de AWS Marketplace en las que las tablas de enrutamiento las usan.
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudarle a planificar sus redes](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Recomendaciones sobre resiliencia de AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [AWS Marketplace para la infraestructura de red](https://aws.amazon.com/marketplace/b/2649366011)
+ [Documento técnico sobre las opciones de conectividad de Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Conectividad de red de alta disponibilidad en varios centros de datos](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Usar conexiones de VPN de sitio a sitio para proporcionar conmutación por error](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ [Usar el kit de herramientas de resiliencia de Direct Connect para empezar](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [Puntos de conexión de VPC y servicios de punto de conexión de VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [¿Qué es Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [¿Qué es una puerta de enlace de tránsito?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [¿Qué es AWS Site-to-Site VPN?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ [Trabajar con puertas de enlace de Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (Diseño avanzado de VPC y funciones nuevas de Amazon VPC) (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (Arquitecturas de referencia de AWS Transit Gateway para muchas VPC) (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP03 Garantizar que la asignación de subredes IP tenga en cuenta la expansión y la disponibilidad
Los intervalos de direcciones IP de Amazon VPC deben ser lo suficientemente amplios como para dar cabida a los requisitos de las cargas de trabajo, como la posible expansión futura y la asignación de direcciones IP a las subredes de las zonas de disponibilidad. Esto incluye equilibradores de carga, instancias de EC2 y aplicaciones basadas en contenedores.
Cuando planifica la topología de su red, el primer paso es definir el espacio de la dirección IP. Se deben asignar rangos de direcciones IP privadas para cada VPC (siguiendo las directrices de la RFC 1918). Facilite los siguientes requisitos como parte de este proceso:
+ Permita los espacios de direcciones IP para más de una VPC por región.
+ En una VPC, deje espacio para múltiples subredes que abarquen varias zonas de disponibilidad.
+ Deje siempre un espacio de bloque de CIDR sin usar en una VPC para posibles expansiones futuras..
+ Asegúrese de que haya espacio de direcciones IP suficiente como para satisfacer las necesidades de flotas transitorias de instancias EC2 que podría usar, como flotas de spot para el machine learning, clústeres de Amazon EMR o clústeres de Amazon Redshift.
+ Tenga en cuenta que las primeras cuatro direcciones IP y las últimas direcciones IP de cada bloque CIDR de subred están reservadas y no están disponibles para usar.
+ Debería planear la implementación de grandes bloques de CIDR de VPC. Tenga en cuenta que el bloque de CIDR de la VPC inicial asignado a su VPC no debe cambiar ni eliminarse, pero puede añadir bloques de CIDR adicionales que no se solapen a la VPC. Los CIDR IPv4 de subred no se pueden cambiar; sin embargo, los CIDR IPv6 sí. Tenga en cuenta que la implementación de la VPC más grande posible (/16) supone más de 65 000 direcciones IP. Solo en el espacio de la dirección IP 10.x.x.x base, puede aprovisionar 255 de estas VPC. Por tanto, de equivocarse, debería hacerlo por exceso y no por defecto, para que administrar sus VPC resulte más sencillo.
**Antipatrones usuales:**
+ Crear VPC pequeñas
+ Crear subredes pequeñas y tener que añadir subredes a las configuraciones conforme crezca
+ Calcular incorrectamente cuántas direcciones IP puede usar un equilibrador de carga elástico
+ Implementar muchos equilibradores carga de tráfico en las mismas subredes
**Beneficios de establecer esta práctica recomendada:** De esta forma, se asegurará de dar cabida al crecimiento de sus cargas de trabajo y seguir proporcionando disponibilidad cuando aumente la capacidad.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Planificar su red para que se adapte al crecimiento, la conformidad normativa y la integración con otros. El crecimiento se puede subestimar, la conformidad normativa puede variar y las adquisiciones y conexiones de redes privadas pueden ser difíciles de realizar sin una planificación adecuada.
+ Seleccione las regiones y Cuentas de AWS que correspondan según sus requisitos de servicio, latencia, normativos y de recuperación de desastres (DR).
+ Identifique sus necesidades para implementaciones regionales de VPC.
+ Identifique el tamaño de las VPC.
+ Determine si va a implementar la conectividad de varias VPC.
+ [¿Qué es una puerta de enlace de tránsito?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Conectividad de varias VPC en una sola región](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ Determine si necesita una red segregada para los requisitos normativos.
+ Haga las VPC tan grandes como sea posible. El bloque de CIDR de la VPC inicial asignado a su VPC no debe cambiar ni eliminarse, pero puede añadir bloques de CIDR adicionales que no se solapen a la VPC. Sin embargo, esto podría fragmentar sus intervalos de direcciones.
+ Haga las VPC tan grandes como sea posible. El bloque de CIDR de la VPC inicial asignado a su VPC no debe cambiar ni eliminarse, pero puede añadir bloques de CIDR adicionales que no se solapen a la VPC. Sin embargo, esto podría fragmentar sus intervalos de direcciones.
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudarle a planificar sus redes](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace para la infraestructura de red](https://aws.amazon.com/marketplace/b/2649366011)
+ [Documento técnico sobre las opciones de conectividad de Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Conectividad de red de alta disponibilidad en varios centros de datos](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Conectividad de varias VPC en una sola región](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ [¿Qué es Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
**Videos relacionados:**
+ [AWS re:Invent 2018: Diseño avanzado de VPC y funciones nuevas de Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: Arquitecturas de referencia de AWS Transit Gateway para muchas VPC (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP04 Preferir topologías radiales (hub-and-spoke) a una conexión en malla de varios a varios
Si se conectan más de dos espacios de direcciones de red (por ejemplo, VPC y redes locales) a través del emparejamiento de VPC, AWS Direct Connect o VPN, utilice un modelo radial hub-and-spoke como el proporcionado por AWS Transit Gateway.
Si tiene solo dos de esas subredes, puede conectarlas entre sí, pero si aumenta el número de redes, la complejidad de esas conexiones en malla se hace insostenible. AWS Transit Gateway proporciona una forma sencilla de mantener un modelo radial que permita el enrutamiento del tráfico entre sus distintas redes.
![\[Diagrama que muestra un caso en el que no se usa AWS Transit Gateway\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/without-transit-gateway.png)
![\[Diagrama que muestra un caso en el que sí se usa AWS Transit Gateway\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/with-transit-gateway.png)
**Patrones de uso no recomendados comunes:**
+ Usar el emparejamiento de VPC para conectarse a más de dos VPC.
+ Establecer varias sesiones de BGP para cada VPC para establecer conectividad que abarque las nubes virtuales privadas (VPC) repartidas entre las distintas Regiones de AWS.
**Beneficios de establecer esta práctica recomendada:** A medida que aumenta el número de redes, la complejidad de estas conexiones en malla se vuelve insostenible. AWS Transit Gateway proporciona una forma sencilla de mantener un modelo radial que permita el enrutamiento del tráfico entre sus distintas redes.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Priorice las topologías radiales (hub-and-spoke) sobre las conexiones en malla de varios a varios. Si se conectan más de dos espacios de direcciones de red (VPC y redes locales) a través del emparejamiento de VPC, AWS Direct Connect o VPN, utilice un modelo radial hub-and-spoke como el proporcionado por AWS Transit Gateway.
+ En el caso de haber solo dos de esas subredes, puede conectarlas entre sí, pero si aumenta el número de redes, la complejidad de esas conexiones en malla se hace insostenible. AWS Transit Gateway proporciona una forma sencilla de mantener un modelo radial que permita el enrutamiento del tráfico entre sus distintas redes.
+ [¿Qué es una puerta de enlace de tránsito?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudarle a planificar sus redes](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace para la infraestructura de red](https://aws.amazon.com/marketplace/b/2649366011)
+ [Conectividad de red de alta disponibilidad en varios centros de datos](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Puntos de conexión de VPC y servicios de punto de conexión de VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [¿Qué es Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [¿Qué es una puerta de enlace de tránsito?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: diseño avanzado de VPC y funciones nuevas de Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: arquitecturas de referencia de AWS Transit Gateway para muchas VPC (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP05 Emplear intervalos no superpuestos de direcciones IP privadas en todos los espacios de direcciones privadas que estén conectados
Los intervalos de direcciones IP de cada VPC no deben solaparse si se emparejan o conectan mediante VPN. Asimismo, debe evitar conflictos de direcciones IP entre una VPC y los entornos locales o con otros proveedores de servicios en la nube que utilice. También debe tener una forma de asignar intervalos de direcciones IP privadas cuando sea necesario.
Un sistema de administración de direcciones IP (IPAM) puede ayudar en este sentido. En AWS Marketplace hay disponibles varias IPAM.
**Patrones de uso no recomendados comunes:**
+ Usar el mismo intervalo de direcciones IP en la VPC local o en la red corporativa
+ No controlar los intervalos de direcciones IP de las VPC usadas para implementar sus cargas de trabajo
**Beneficios de establecer esta práctica recomendada:** La planificación activa de la red garantizará que no tenga varias instancias de la misma dirección IP en las redes interconectadas. Con esto evitará que se produzcan problemas de enrutamiento en las partes de la carga de trabajo que usan las diferentes aplicaciones.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Supervise y administre el uso de CIDR. Evalúe su potencial de uso en AWS, añada intervalos de CIDR a las VPC existentes y cree VPC para permitir un crecimiento planificado del uso.
+ Capture el consumo actual de CIDR (por ejemplo, VPC o subredes).
+ Use operaciones de la API de servicio para recopilar el consumo actual de CIDR.
+ Capture su uso actual de las subredes.
+ Use operaciones de la API de servicio para recopilar subredes por VPC en cada región.
+ [DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ Registre el uso actual.
+ Determine si ha creado intervalos de IP superpuestos.
+ Calcule la capacidad de reserva.
+ Identifique los intervalos de IP superpuestos. Puede migrar a un intervalo de direcciones nuevo o usar dispositivos de traducción de redes y puertos (NAT) de AWS Marketplace si necesita conectar los intervalos superpuestos.
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudarle a planificar sus redes](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace para la infraestructura de red](https://aws.amazon.com/marketplace/b/2649366011)
+ [Documento técnico sobre las opciones de conectividad de Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Conectividad de red de alta disponibilidad en varios centros de datos](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [¿Qué es Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [¿Qué es la IPAM?](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Diseño avanzado de VPC y funciones nuevas de Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: Arquitecturas de referencia de AWS Transit Gateway para muchas VPC (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# Arquitectura de la carga de trabajo
**Topics**
+ [REL 3 ¿Cómo diseña la arquitectura de servicio de su carga de trabajo?](w2aac19b9b7b5.md)
+ [REL 4 ¿Cómo diseña las interacciones en un sistema distribuido para evitar errores?](w2aac19b9b7b7.md)
+ [REL 5 ¿Cómo diseña las interacciones en un sistema distribuido para mitigar o tolerar errores?](w2aac19b9b7b9.md)
# REL 3 ¿Cómo diseña la arquitectura de servicio de su carga de trabajo?
Desarrolle cargas de trabajo escalables y fiables utilizando una arquitectura orientada a servicios (SOA) o una arquitectura de microservicios. La arquitectura orientada a servicios (SOA) es la práctica de hacer que los componentes de software se puedan reutilizar mediante interfaces de servicio. La arquitectura de microservicios va más allá, para hacer que los componentes sean más pequeños y sencillos.
**Topics**
+ [REL03-BP01 Elegir cómo segmentar su carga de trabajo](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Desarrollar servicios centrados en funcionalidades y dominios empresariales específicos](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Facilitar contratos de servicio por cada API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Elegir cómo segmentar su carga de trabajo
La segmentación de la carga de trabajo es importante a la hora de determinar los requisitos de resiliencia de su aplicación. La arquitectura monolítica debe evitarse siempre que sea posible. En su lugar, considere detenidamente qué componentes de la aplicación pueden dividirse en microservicios. Según los requisitos de su aplicación, esto puede terminar siendo una combinación de una arquitectura orientada a servicios (SOA) con microservicios cuando sea posible. Las cargas de trabajo que son capaces de no tener estado son más capaces desplegarse como microservicios.
**Resultado deseado:** Las cargas de trabajo deben ser soportables, escalables y estar tan poco acopladas como sea posible.
A la hora de elegir cómo segmentar la carga de trabajo, hay que sopesar las ventajas frente a las complejidades. Lo que puede ser adecuado para un nuevo producto encaminado a su primer lanzamiento es diferente a lo que necesita una carga de trabajo creada para escalarse desde el principio. Al refactorizar un monolito existente, tendrá que considerar en qué medida soportará la aplicación una descomposición hacia la falta de estado. Dividir los servicios en partes más pequeñas permite que equipos pequeños y bien definidos los desarrollen y administren. No obstante, los servicios más pequeños pueden introducir complejidades que incluyen un aumento de la latencia, una depuración más compleja y un mayor lastre operativo.
**Patrones comunes de uso no recomendados:**
+ El [microservicio *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) es una situación en la que los componentes atómicos son tan interdependientes que el error de uno de ellos provoca un error mucho mayor, haciendo que los componentes sean tan rígidos y frágiles como un monolito.
**Beneficios de establecer esta práctica:**
+ Los segmentos más específicos conducen a una mayor agilidad, flexibilidad organizativa y escalabilidad.
+ Reducción del impacto de las interrupciones del servicio.
+ Los componentes de la aplicación pueden tener diferentes requisitos de disponibilidad, que pueden soportarse mediante una segmentación más atómica.
+ Responsabilidades bien definidas para los equipos que apoyan la carga de trabajo.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
Seleccione el tipo de arquitectura en función de cómo va a segmentar su carga de trabajo. Seleccione una SOA o una arquitectura de microservicios (o, en algunos casos raros, una arquitectura monolítica). Incluso si decide empezar con una arquitectura monolítica, debe asegurarse de que sea modular y de que pueda evolucionar hacia SOA o microservicios de forma definitiva, a medida que su producto escala con la adopción por parte de los usuarios. La SOA y los microservicios ofrecen respectivamente una segmentación más pequeña, lo que resulta preferible como arquitectura moderna escalable y confiable, pero existen compensaciones a tener en cuenta, especialmente al desplegar una arquitectura de microservicios.
Una compensación principal es que se dispone de una arquitectura de informática distribuida que puede dificultar el cumplimiento de los requisitos de latencia del usuario y existe una complejidad adicional en la depuración y el rastreo de las interacciones del usuario. Puede utilizar AWS X-Ray para ayudarle a resolver este problema. Otro efecto que hay que tener en cuenta es el aumento de la complejidad operativa a medida que aumenta el número de aplicaciones que se administran, lo que requiere el despliegue de componentes con varias independencias.
![\[Diagrama que muestra una comparación entre las arquitecturas monolíticas, orientadas al servicio y de microservicios\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Pasos para la aplicación
+ Determine la arquitectura adecuada para refactorizar o desarrollar su aplicación. La SOA y los microservicios ofrecen respectivamente una segmentación más pequeña, lo que resulta preferible como arquitectura moderna escalable y confiable. La SOA puede ofrecer un término intermedio ideal para conseguir una segmentación más pequeña y, a la vez, evitar algunas de las complejidades de los microservicios. Para obtener más información, consulte [Microservice Trade-Offs (Compensaciones de microservicios)](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Si su carga de trabajo lo admite y su organización puede permitírselo, debería usar una arquitectura de microservicios para conseguir la mejor agilidad y fiabilidad. Para obtener más información, consulte [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Tenga en cuenta seguir el patrón de [*Strangler Fig* para](https://martinfowler.com/bliki/StranglerFigApplication.html) refactorizar un monolito en componentes más pequeños. Se trata de sustituir gradualmente componentes específicos de la aplicación por nuevas aplicaciones y servicios. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) actúa como punto de partida para la refactorización incremental. Para obtener más información, consulte [Seamlessly migrate on-premises legacy workloads using a strangler pattern (Migrar sin problemas las cargas de trabajo heredadas localmente utilizando un patrón estrangulador)](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ La implementación de microservicios puede requerir un mecanismo de detección de servicios para permitir que estos servicios distribuidos se comuniquen entre sí. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) se puede usar con arquitecturas orientadas a servicios para ofrecer una detección y un acceso confiable a los servicios. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) también puede utilizarse para la detección dinámica de servicios basada en DNS.
+ Si está migrando de un monolito a SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) puede ayudar a salvar la brecha como un bus de servicio cuando se rediseñan las aplicaciones heredadas en la nube.
+ Para los monolitos existentes con una única base de datos compartida, elija cómo reorganizar los datos en segmentos más pequeños. Puede ser por unidad de negocio, patrón de acceso o estructura de datos. En este punto del proceso de refactorización, debe elegir entre una base de datos de tipo relacional o no relacional (NoSQL). Para obtener más información, consulte [From SQL to NoSQL (De SQL a NoSQL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Nivel de esfuerzo para el plan de implementación:** Alto
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL03-BP02 Desarrollar servicios centrados en funcionalidades y dominios empresariales específicos](rel_service_architecture_business_domains.md)
**Documentos relacionados:**
+ [Amazon API Gateway: Configuración de una API de REST con OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [¿Qué es la arquitectura orientada a servicios?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Contexto limitado (un patrón central en un diseño basado en dominios)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs (Compensaciones de microservicios)](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservicios: definición de este nuevo término de arquitectura](https://www.martinfowler.com/articles/microservices.html)
+ [Microservicios en AWS](https://aws.amazon.com/microservices/)
+ [¿Qué es AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Ejemplos relacionados:**
+ [Taller de modernización de aplicaciones iterativas](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Vídeos relacionados:**
+ [Delivering Excellence with Microservices on AWS (Proporcionar excelencia con microservicios en AWS)](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Desarrollar servicios centrados en funcionalidades y dominios empresariales específicos
La arquitectura orientada a servicios (SOA) desarrolla servicios con funciones bien delineadas definidas por necesidades empresariales. Los microservicios utilizan modelos de dominios y un contexto limitado para aplicar una restricción de modo que cada servicio lleve a cabo solo una cosa. Al centrarse en funciones específicas, puede diferenciar los requisitos de fiabilidad de los distintos servicios y dirigir las inversiones con un mayor nivel de especificidad. Tener un problema empresarial conciso y un equipo pequeño asociado a cada servicio también facilita un escalado organizativo más sencillo.
A la hora de diseñar una arquitectura de microservicios, resulta útil utilizar un diseño basado en dominio (DDD) para modelar el problema empresarial utilizando entidades. Por ejemplo, para el sitio web de Amazon.com, entre las entidades podrían estar el paquete, la entrega, la programación, el precio, el descuento y la divisa. Posteriormente, el modelo se divide aún más en modelos más pequeños con un [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html), en el que se agrupan las entidades que comparten características y atributos similares. Así, si usamos como ejemplo Amazon.com, el paquete, la entrega y la programación formarían parte del contexto de envío, y el precio, el descuento y la divisa formarían parte del contexto de precios. Si el modelo está dividido en contextos, aparecerá una plantilla para limitar los microservicios.
![\[Plantilla modelo para la limitación de microservicios\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/building-services.png)
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Diseñe su carga de trabajo en función de sus dominios empresariales y la funcionalidad correspondiente. Al centrarse en funciones específicas, puede diferenciar los requisitos de fiabilidad de los distintos servicios y dirigir las inversiones con un mayor nivel de especificidad. Tener un problema empresarial conciso y un equipo pequeño asociado a cada servicio también facilita un escalado organizativo más sencillo.
+ Lleve a cabo un análisis del dominio para trazar un diseño basado en dominio (DDD) para su carga de trabajo. Posteriormente, podrá elegir un tipo de arquitectura que se ajuste a las necesidades de su carga de trabajo.
+ [Cómo descomponer un sistema monolítico en microservicios](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Introducción al DDD en un ambiente lleno de sistemas heredados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans «Domain-Driven Design: Tackling Complexity in the Heart of Software» (Diseño basado en dominios: afrontar la complejidad en el corazón del software)](https://www.amazon.com/gp/product/0321125215)
+ [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Descomponga sus servicios en los componentes más pequeños posibles. Con la arquitectura de microservicios, puede separar su carga de trabajo en componentes con la funcionalidad mínima para permitir la escalabilidad y la agilidad organizativas.
+ Defina la API para la carga de trabajo y sus objetivos de diseño, límites y cualquier otra consideración de uso.
+ Defina la API.
+ La definición de la API debería permitir el crecimiento y la incorporación de parámetros adicionales.
+ Defina las disponibilidades diseñadas.
+ Su API puede tener múltiples objetivos de diseño para diferentes funciones.
+ Establezca límites
+ Utilice pruebas para definir los límites de sus capacidades de carga de trabajo.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: Configuración de una API de REST con OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexto limitado (un patrón central en un diseño basado en dominios)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans «Domain-Driven Design: Tackling Complexity in the Heart of Software» (Diseño basado en dominios: afrontar la complejidad en el corazón del software)](https://www.amazon.com/gp/product/0321125215)
+ [Introducción al DDD en un ambiente lleno de sistemas heredados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Cómo descomponer un sistema monolítico en microservicios](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensaciones de los microservicios](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservicios: definición de este nuevo término de arquitectura](https://www.martinfowler.com/articles/microservices.html)
+ [Microservicios en AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Facilitar contratos de servicio por cada API
Los contratos de servicio son acuerdos documentados entre equipos sobre la integración de servicios e incluyen una definición de API legible por máquina, límites de tasa y expectativas de rendimiento. Una estrategia de control de versiones permite a los clientes seguir usando la API existente y migrar sus aplicaciones a la nueva API cuando estén listos. El despliegue puede ocurrir en cualquier momento siempre y cuando no se infrinja el contrato. El proveedor del servicio puede usar la pila tecnológica que prefiera para cumplir el contrato de la API. Del mismo modo, el consumidor del servicio puede usar su propia tecnología.
Los microservicios toman el concepto de arquitectura orientada a servicios (SOA) para crear servicios que tengan un conjunto mínimo de funcionalidades. Cada servicio publica una API y objetivos de diseño, límites y otras consideraciones para el uso del servicio. Esto establece un *contrato* con las aplicaciones de llamada. Con ello, se logran tres beneficios principales:
+ El servicio tiene un problema comercial conciso que atender y un pequeño equipo que tiene el problema comercial. Así, se permite un mejor escalado organizativo.
+ El equipo puede desplegar en cualquier momento siempre que se cumplan los requisitos de la API y del contrato.
+ El equipo puede usar cualquier pila tecnológica siempre que cumpla los requisitos de la API y del contrato.
Amazon API Gateway es un servicio completamente administrado que facilita que los desarrolladores creen, publiquen, mantengan, supervisen y protejan las API a cualquier escala. Gestiona todas las tareas involucradas en la aceptación y el procesamiento de cientos de miles de llamadas simultáneas a la API, lo que incluye la administración del tráfico, la autorización y el control de acceso, la supervisión y la administración de la versión de la API. Por medio de la especificación OpenAPI (OAS), conocida anteriormente como especificación Swagger, puede definir el contrato de API e importarlo a API Gateway. Con API Gateway, puede versionar y desplegar las API.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Bajo
## Guía para la implementación
+ Proporcione contratos de servicio por API. Los contratos de servicio son acuerdos documentados entre equipos sobre la integración de servicios e incluyen una definición de API legible por máquina, límites de tasa y expectativas de rendimiento.
+ [Amazon API Gateway: configuración de una API de REST con OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Una estrategia de control de versiones permite a los clientes seguir usando la API existente y migrar sus aplicaciones a la nueva API cuando estén listos.
+ Amazon API Gateway es un servicio completamente administrado que facilita que los desarrolladores creen API a cualquier escala. Por medio de la especificación OpenAPI (OAS), conocida anteriormente como especificación Swagger, puede definir su contrato de API e importarlo a API Gateway. Con API Gateway, puede versionar y desplegar las API.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: configuración de una API de REST con OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexto limitado (un patrón central en un diseño basado en dominios)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensaciones de los microservicios](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservicios: definición de este nuevo término de arquitectura](https://www.martinfowler.com/articles/microservices.html)
+ [Microservicios en AWS](https://aws.amazon.com/microservices/)
# REL 4 ¿Cómo diseña las interacciones en un sistema distribuido para evitar errores?
Los sistemas distribuidos dependen de las redes de comunicaciones para interconectar componentes, como servidores o servicios. Su carga de trabajo debe funcionar de manera fiable aunque se pierdan datos o haya latencia en estas redes. Los componentes del sistema distribuido deben funcionar de forma que no repercutan negativamente en otros componentes ni en la carga de trabajo. Estas prácticas recomendadas evitan que se produzcan errores y mejoran el tiempo medio entre errores (MTBF).
**Topics**
+ [REL04-BP01 Identificar qué tipo de sistema distribuido se necesita](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implementar dependencias con acoplamiento flexible](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Realizar un trabajo constante](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Hacer que todas las respuestas sean idempotentes](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Identificar qué tipo de sistema distribuido se necesita
Los sistemas distribuidos en tiempo real estrictos requieren que las respuestas se proporcionen de forma sincrónica y rápidamente, mientras que los sistemas en tiempo real laxos cuentan con un plazo de tiempo más generoso, que se mide en minutos o más, para proporcionar una respuesta. Los sistemas sin conexión gestionan las respuestas a través del procesamiento por lotes o asincrónico. Los sistemas distribuidos en tiempo real estrictos tienen los requisitos de fiabilidad más exigentes.
Los desafíos más complicados [relacionados con los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) giran en torno a los sistemas distribuidos en tiempo real, conocidos también como servicios de solicitud/respuesta. Lo que hace que sean tan difíciles es que las solicitudes llegan de forma impredecible y las respuestas deben emitirse rápidamente (por ejemplo, si el cliente está esperando una respuesta de forma activa). Entre algunos ejemplos se incluyen los servidores web de front-end, la canalización de pedidos, las transacciones con tarjetas de crédito, todas las API de AWS y la telefonía.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Identifique qué tipo de sistema distribuido se necesita. Entre los problemas de los sistemas distribuidos se incluyen la latencia, el escalado, conocer las API de red, la serialización y deserialización de los datos, y la complejidad de algoritmos como Paxos. A medida que los sistemas crecen y se hacen más distribuidos, los casos extremos teóricos se convierten en sucesos habituales.
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ Los sistemas distribuidos en tiempo real estrictos requieren que las respuestas se proporcionen de forma sincrónica y rápidamente.
+ Los sistemas en tiempo real laxos cuentan con un plazo más generoso, que se mide en minutos o más, para proporcionar una respuesta.
+ Los sistemas sin conexión gestionan las respuestas a través del procesamiento por lotes o asincrónico.
+ Los sistemas distribuidos en tiempo real estrictos tienen los requisitos de fiabilidad más exigentes.
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [¿Qué es Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Videos relacionados:**
+ [Cumbre de AWS en Nueva York 2019: Introducción a las arquitecturas basadas en eventos y Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Bucles cerrados y mentes abiertas: cómo asumir el control de los sistemas grandes y pequeños ARC337 (incluye acoplamiento flexible, trabajo constante y estabilidad estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 Implementar dependencias con acoplamiento flexible
Las dependencias, como los sistemas de colas, los sistemas de transmisión, los flujos de trabajo y los equilibradores de carga, tienen un acoplamiento flexible. El acoplamiento flexible ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad.
Si un cambio en un componente obliga a otros componentes que dependen de él a aplicar ese cambio, entonces los componentes tienen un *acoplamiento* estricto. *El acoplamiento* flexible elimina esta dependencia, de forma que los componentes dependientes solo necesitan conocer la nueva versión de la interfaz publicada. Al implementar un acoplamiento flexible entre dependencias, se aíslan los fallos que se puedan producir en una, de modo que no afecten a la otra.
El acoplamiento flexible le permite añadir código o funciones adicionales a un componente mientras se reduce al mínimo el riesgo para los componentes que dependen de él. Además, se mejora la escalabilidad, ya que puede escalar horizontalmente o incluso cambiar la implementación subyacente de la dependencia.
Para mejorar aún más la resiliencia mediante el acoplamiento flexible, haga que las interacciones entre componentes sean asíncronas siempre que sea posible. Este modelo es adecuado para cualquier interacción que no necesite una respuesta inmediata y en la que baste con el reconocimiento de que una solicitud se ha registrado. Consta de un componente que genera eventos y de otro que los consume. Ambos componentes no se integran mediante una interacción directa de punto a punto, sino que normalmente emplean una capa de almacenamiento duradera intermedia, como una cola SQS o una plataforma de retransmisión de datos como Amazon Kinesis o AWS Step Functions.
![\[Diagrama que muestra el acoplamiento flexible de dependencias como sistemas de colas y equilibradores de carga\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Las colas de Amazon SQS y los equilibradores de carga elásticos son solo dos formas de añadir una capa intermedia para el acoplamiento flexible. Las arquitecturas basadas en eventos también pueden integrarse en Nube de AWS utilizando Amazon EventBridge, lo que puede abstraer a los clientes (productores de eventos) de los servicios en los que confían (consumidores de eventos). Amazon Simple Notification Service (Amazon SNS) es una solución eficaz cuando se necesita una mensajería de alto rendimiento, basada en push y de varios a varios. Utilizando temas de Amazon SNS, los sistemas de tu publicador pueden repartir mensajes por una gran cantidad de puntos de conexión de suscriptores para su procesamiento paralelo.
Aunque las colas ofrecen varias ventajas, en la mayoría de sistemas inflexibles en tiempo real, las solicitudes que superan un umbral temporal (que suele ser de segundos) se consideran obsoletas (el cliente ha desistido y ya no espera una respuesta), por lo que no se procesan. De esta manera, se pueden procesar las solicitudes más recientes (y probablemente aún válidas) en su lugar.
**Patrones de uso no recomendados comunes:**
+ Implementar un singleton como parte de una carga de trabajo
+ Invocar directamente las API entre capas de la carga de trabajo sin la capacidad de conmutar por error ni procesar asincrónicamente la solicitud
**Beneficios de establecer esta práctica recomendada:** El acoplamiento flexible ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad. Un error en un componente está aislado de los demás componentes.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Implementar dependencias con acoplamiento flexible Las dependencias, como los sistemas de colas, los sistemas de transmisión, los flujos de trabajo y los equilibradores de carga, tienen un acoplamiento flexible. El acoplamiento flexible ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad.
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [¿Qué es Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ Amazon EventBridge le permite crear arquitecturas basadas en eventos, que tienen acoplamiento flexible y son arquitecturas distribuidas.
+ [Cumbre de AWS en Nueva York 2019: Introducción a las arquitecturas basadas en eventos y Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ Si un cambio en un componente obliga a otros componentes que dependen de él a aplicar ese cambio, entonces los componentes tienen un acoplamiento estricto. El acoplamiento flexible elimina esta dependencia, de forma que los componentes dependientes solo necesitan conocer la nueva versión de la interfaz publicada.
+ Haga que las interacciones de los componentes sean asincrónicas siempre que sea posible. Este modelo es adecuado para cualquier interacción que no necesite una respuesta inmediata y en la que baste con el reconocimiento de que una solicitud se ha registrado.
+ [AWS re:Invent 2019: Aplicaciones escalables basadas en eventos sin servidor mediante Amazon SQS y Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
## Recursos
**Documentos relacionados:**
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [¿Qué es Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Vídeos relacionados:**
+ [Cumbre de AWS en Nueva York 2019: Introducción a las arquitecturas basadas en eventos y Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Bucles cerrados y mentes abiertas: cómo asumir el control de los sistemas grandes y pequeños ARC337 (incluye acoplamiento flexible, trabajo constante y estabilidad estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Aplicaciones escalables basadas en eventos sin servidor mediante Amazon SQS y Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 Realizar un trabajo constante
Los sistemas pueden producir error cuando hay cambios rápidos grandes en la carga. Por ejemplo, si la carga de trabajo está realizando una comprobación de estado que supervisa el estado de miles de servidores, debería enviar siempre una carga del mismo tamaño (una instantánea completa del estado actual). Si no hay errores en ningún servidor, o hay errores en todos ellos, el sistema de comprobación de estado estará haciendo un trabajo constante sin rápidos cambios de gran tamaño.
Por ejemplo, si el sistema de comprobación de estado supervisa 100 000 servidores, la carga contenida en él es nominal con un porcentaje de errores del servidor normalmente bajo. Sin embargo, si un evento importante deja a la mitad de esos servidores en mal estado, el sistema de comprobación de estado se sobrecargaría intentando actualizar los sistemas de notificación y comunicar el estado a sus clientes. Por ello, el sistema de comprobación de estado debería enviar cada vez la instantánea completa del estado actual. 100 000 estados de servidor, cada uno representado por un bit, solo constituiría una carga de 12,5 KB. Si no hay errores en ningún servidor, o hay errores en todos ellos, el sistema de comprobación de estado estará haciendo un trabajo constante y los cambios rápidos de gran tamaño no pondrán en peligro la estabilidad del sistema. En realidad, así es como Amazon Route 53 gestiona las comprobaciones de estado de los puntos de conexión (como las direcciones IP) para determinar cómo se enruta a los usuarios finales.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Bajo
## Guía para la implementación
+ Realice un trabajo para que los sistemas no tengan errores cuando hay cambios grandes y rápidos en la carga.
+ Implemente dependencias con acoplamiento flexible. Las dependencias, como los sistemas de colas, los sistemas de transmisión, los flujos de trabajo y los equilibradores de carga, tienen un acoplamiento flexible. El acoplamiento flexible ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad.
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work) (Cerrar los bucles y abrir las mentes: cómo tomar el control de los sistemas, grandes y pequeños ARC337 [incluye trabajo constante])](https://youtu.be/O8xLxNje30M?t=2482)
+ En el ejemplo de una sistema de comprobación de estado que supervisa 100 000 servidores, diseñe las cargas de trabajo de forma que los tamaños de la carga útil sean iguales independientemente del número de éxitos o fracasos.
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (Introducción a las arquitecturas basadas en eventos y Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work) (Cerrar los bucles y abrir las mentes: cómo asumir el control de los sistemas grandes y pequeños ARC337 [incluye trabajo constante])](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes loose coupling, constant work, static stability) (Cerrar los bucles y abrir las mentes: cómo asumir el control de los sistemas grandes y pequeños ARC337 [incluye acoplamiento flexible, trabajo constante y estabilidad estática])](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (Optar por arquitecturas basadas en eventos) (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Hacer que todas las respuestas sean idempotentes
Un servicio idempotente promete que cada solicitud se completará una y solo una vez, de tal forma que realizar varias solicitudes idénticas tiene el mismo efecto que realizar una sola solicitud. Un servicio idempotente permite que un cliente implemente fácilmente los reintentos sin el temor de que una solicitud se procese erróneamente varias veces. Para ello, los clientes pueden usar solicitudes de API con un token de idempotencia: se utiliza el mismo token siempre que se repite la solicitud. Una API de servicio idempotente usa el token para devolver una respuesta idéntica a la que se devolvió por primera vez cuando se completó la solicitud.
En un sistema distribuido, es fácil llevar a cabo una acción una vez como máximo (el cliente realiza solo una solicitud) o al menos una vez (sigue realizando la solicitud hasta que el cliente obtiene una confirmación del éxito). Sin embargo, es difícil garantizar que una acción es idempotente, lo que significa que se lleva a cabo *exactamente* una vez, de modo que realizar varias solicitudes idénticas tiene el mismo efecto que realizar una sola solicitud. Al usar tokens de idempotencia en las API, los servicios pueden recibir una solicitud de migración una o más veces sin crear registros duplicados ni efectos secundarios.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Haga que todas las respuestas sean idempotentes. Un servicio idempotente promete que cada solicitud se completará una y solo una vez, de tal forma que realizar varias solicitudes idénticas tiene el mismo efecto que realizar una sola solicitud.
+ Los clientes pueden usar solicitudes de API con un token de idempotencia: se utiliza el mismo token siempre que se repite la solicitud. Una API de servicio idempotente usa el token para devolver una respuesta idéntica a la que se devolvió por primera vez cuando se completó la solicitud.
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Videos relacionados:**
+ [Cumbre de AWS en Nueva York 2019: Introducción a las arquitecturas basadas en eventos y Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Bucles cerrados y mentes abiertas: cómo asumir el control de los sistemas grandes y pequeños ARC337 (incluye acoplamiento flexible, trabajo constante y estabilidad estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://youtu.be/h46IquqjF3E)
# REL 5 ¿Cómo diseña las interacciones en un sistema distribuido para mitigar o tolerar errores?
Los sistemas distribuidos dependen de las redes de comunicaciones para interconectar componentes, como servidores o servicios. Su carga de trabajo debe funcionar de manera fiable aunque se pierdan datos o haya latencia en estas redes. Los componentes del sistema distribuido deben funcionar de forma que no repercutan negativamente en otros componentes ni en la carga de trabajo. Estas prácticas recomendadas permiten que las cargas de trabajo toleren el estrés o los errores, se recuperen más rápidamente de ellos y mitiguen el impacto de dichos errores. El resultado es un tiempo medio de recuperación (MTTR) mejor.
**Topics**
+ [REL05-BP01 Implementar una degradación estable para transformar las dependencias estrictas en flexibles](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Limitar las solicitudes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Controlar y limitar las llamadas de reintento](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Responder rápido a los errores y limitar las colas](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Definir tiempos de espera del cliente](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Crear servicios sin estado cuando sea posible](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementar recursos de emergencia](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implementar una degradación estable para transformar las dependencias estrictas en flexibles
Cuando las dependencias de un componente no están en buen estado, el propio componente puede seguir funcionando, aunque con la capacidad mermada. Por ejemplo, cuando se produzca un error en una llamada a una dependencia, conmute por error a una respuesta estática predeterminada.
Considere un servicio B que lo llama el servicio A y que a su vez llama al servicio C.
![\[Diagrama que muestra que se produce un error en el servicio C cuando se le llama desde el servicio B. El servicio B devuelve una respuesta degradada al servicio A\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
Cuando el servicio B llama al servicio C, recibe un error o un tiempo de espera agotado. El servicio B, a falta de una respuesta del servicio C (y de los datos que contiene), devuelve lo que puede. Este puede ser el último valor bueno almacenado en caché, o el servicio B puede sustituir una respuesta estática predeterminada por la que habría recibido del servicio C. A continuación, puede devolver una respuesta degradada al autor de la llamada, el servicio A. Sin esta respuesta estática, el error en el servicio C se transmitiría en cascada a través del servicio B al servicio A, lo que provocaría una pérdida de disponibilidad.
Según el factor multiplicativo en la ecuación de disponibilidad para las dependencias estrictas (consulte [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)), cualquier caída en la disponibilidad de C repercute gravemente en la disponibilidad efectiva de B. Al devolver la respuesta estática, el servicio B mitiga el error en C y, aunque degradado, hace que la disponibilidad del servicio C parezca del 100 % (suponiendo que devuelva la respuesta estática de forma fiable en condiciones de error). Tenga en cuenta que la respuesta estática es una simple alternativa a la devolución de un error y no es un intento de volver a calcular la respuesta con otros medios. Estos intentos de utilizar un mecanismo completamente diferente para tratar de conseguir el mismo resultado se denominan comportamientos alternativos y son un patrón de uso no recomendado que debe evitarse.
Otro ejemplo de degradación correcta es el *patrón de disyuntor*. Las estrategias de reintentos deben utilizarse cuando el error es transitorio. Cuando no es así, y es probable que la operación tenga un error, el patrón de disyuntor evita que el cliente realice una solicitud que probablemente falle. Cuando las solicitudes se procesan normalmente, el interruptor se cierra y las solicitudes fluyen. Cuando el sistema remoto comienza a devolver errores o presenta una alta latencia, el disyuntor se abre y se ignora la dependencia o se reemplazan los resultados por respuestas más sencillas pero menos completas (que podrían ser simplemente una caché de respuestas). Periódicamente, el sistema intenta llamar a la dependencia para determinar si se ha recuperado. Cuando eso ocurre, el interruptor se cierra.
![\[Diagrama que muestra el disyuntor en estado abierto y cerrado.\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
Además de los estados cerrado y abierto mostrados en el diagrama, tras un periodo de tiempo configurable en el estado abierto, el disyuntor puede cambiar a semiabierto. En este estado, intenta llamar periódicamente al servicio a un ritmo mucho más bajo de lo normal. Este sondeo se utiliza para comprobar el estado del servicio. Después de una serie de éxitos en el estado semiabierto, el disyuntor pasa al estado cerrado y se reanudan las solicitudes normales.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Implemente una degradación estable para transformar las dependencias estrictas en flexibles. Cuando las dependencias de un componente no están en buen estado, el propio componente puede seguir funcionando, aunque con la capacidad mermada. Por ejemplo, cuando se produzca un error en una llamada a una dependencia, conmute por error a una respuesta estática predeterminada.
+ Al devolver una respuesta estática, la carga de trabajo mitiga los errores que se producen en sus dependencias.
+ [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)
+ Detecte cuándo es probable que la operación de reintento produzca un error e impedir que el cliente realice llamadas infructuosas con el patrón de disyuntor.
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: Limitar las solicitudes de la API para mejorar el rendimiento](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (resumen del patrón de interruptor del libro «Release It\$1»)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Error Retries and Exponential Backoff in AWS (Reintentos en caso de error y retroceso exponencial en AWS)](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard «Release It\$1 Design and Deploy Production-Ready Software»](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [La Amazon Builders' Library: Evitar el retroceso en sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [La Amazon Builders' Library: Evitar trabajos pendientes en colas insalvables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [La Amazon Builders' Library: Desafíos y estrategias del almacenamiento en caché](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [La Amazon Builders' Library: Tiempos de espera, reintentos y retroceso con alteración](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Reintento, retroceso y alteración: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (Presentación de Amazon Builders’ Library) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**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)
# REL05-BP02 Limitar las solicitudes
La limitación de solicitudes es un patrón de mitigación para responder a un aumento imprevisto de la demanda. Algunas solicitudes se aceptan, pero aquellas que sobrepasan un límite definido se rechazan y se devuelve un mensaje en el que se indica que se han restringido. Lo que se espera de los clientes es que abandonen la solicitud o la repitan con una frecuencia menor.
Los servicios se deben diseñar para administrar una capacidad conocida de solicitudes que cada nodo o celda pueda procesar. Esta capacidad se puede establecer mediante pruebas de carga. A continuación, es necesario hacer un seguimiento de la tasa de llegada de las solicitudes y si la tasa de llegada temporal supera este límite, la respuesta adecuada es señalar que se ha limitado la solicitud. Esto permite al usuario realizar un reintento, potencialmente en un nodo o celda que pueda tener capacidad disponible. Amazon API Gateway proporciona métodos para limitar las solicitudes. Amazon SQS y Amazon Kinesis pueden guardar las solicitudes en búfer, suavizar la tasa de solicitudes y aliviar la necesidad de limitar aquellas solicitudes que puedan atenderse de forma asíncrona.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Limite las solicitudes. Este es un patrón de mitigación para responder a un aumento imprevisto de la demanda. Algunas solicitudes se aceptan, pero aquellas que sobrepasan un límite definido se rechazan y se devuelve un mensaje en el que se indica que se han restringido. Lo que se espera de los clientes es que abandonen la solicitud o la repitan con una frecuencia menor.
+ Use Amazon API Gateway
+ [Limitar las solicitudes de API para un mayor rendimiento](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: limitar las solicitudes de API para un mayor rendimiento](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Reintentos en caso de error y retroceso exponencial en AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [La Amazon Builders' Library: Evitar el retroceso en sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [La Amazon Builders' Library: Evitar trabajos pendientes en colas insalvables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [La Amazon Builders' Library: Tiempos de espera, reintentos y retroceso con alteración](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Limitar las solicitudes de API para un mayor rendimiento](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**Vídeos relacionados:**
+ [Reintento, retroceso y fluctuación: AWS re:Invent 2019: presentación de la Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 Controlar y limitar las llamadas de reintento
Use el retroceso exponencial para los reintentos tras intervalos cada vez más largos. Introduzca una fluctuación para asignar un orden aleatorio a estos intervalos de reintento y limite el número máximo de reintentos.
Entre los componentes típicos de un sistema de software distribuido se incluyen servidores, equilibradores de carga, bases de datos y servidores DNS. Durante la operación, y sujetos a fallos, cualquiera de estos componentes pueden generar errores. La técnica predeterminada para corregir estos errores es implementar reintentos en el lado del cliente. Esta técnica aumenta la fiabilidad y disponibilidad de la aplicación. Sin embargo, a escala (y si los clientes intentan reintentar la operación fallida en cuanto se produce un error), la red puede saturarse rápidamente con solicitudes nuevas y reintentadas, ya que todas compiten por el mismo ancho de banda de la red. Esto puede dar como resultado una *tormenta de reintentos,* que reducirá la disponibilidad del servicio. Este patrón podría continuar hasta que se produzca un fallo total del sistema.
Para evitar este tipo de escenarios, deben usarse algoritmos de retroceso, como los de *retroceso exponencial* que se utilizan habitualmente. Los algoritmos de retroceso exponencial reducen gradualmente el ritmo al que se realizan los reintentos, evitando así la congestión de la red.
Muchos SDK y bibliotecas de software, incluidas las de AWS, implementan una versión de estos algoritmos. Sin embargo, **no dé nunca por sentado que ya existe un algoritmo de retroceso: compruébelo siempre y verifique si se da el caso.**
El retroceso por sí solo no es suficiente, ya que en sistemas distribuidos, todos los clientes podrían retroceder simultáneamente, creando clústeres de llamadas de reintento. Marc Brooker, en su publicación de blog [Exponential backoff and jitter (Retroceso exponencial y fluctuación)](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/), explica cómo modificar la función wait() en el retroceso exponencial para evitar clústeres de llamadas de reintento. La solución es añadir *fluctuación* en la función wait(). Para evitar que los reintentos se prolonguen demasiado tiempo, las implementaciones deberían restringir el retroceso a un valor máximo.
Por último, es importante configurar un *número máximo de reintentos* o un máximo de tiempo, transcurrido el cual los reintentos fallarán. Los SDK de AWS implementan esto de forma predeterminada y permiten configurarlo. Para servicios que se encuentren más abajo en la pila, un límite de reintentos máximo de cero o uno puede limitar el riesgo y, aun así, ser eficaz, ya que los reintentos se delegan a servicios que ocupan puestos más altos en la pila.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Controle y limite las llamadas de reintento. Use el retroceso exponencial para los reintentos tras intervalos cada vez más largos. Introduzca una fluctuación para asignar un orden aleatorio a estos intervalos de reintento y limite el número máximo de reintentos.
+ [Reintentos en caso de error y retroceso exponencial en AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Los SDK de Amazon implementan los reintentos y el retroceso exponencial de forma predeterminada. Implemente una lógica similar en su capa de dependencia a la hora de llamar a sus propios servicios dependientes. Decida cuáles son los tiempos de espera y cuándo dejar de reintentar según su caso de uso.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: limitar las solicitudes de API para un mayor rendimiento](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Reintentos en caso de error y retroceso exponencial en AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [La Amazon Builders' Library: Evitar el retroceso en sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [La Amazon Builders' Library: Evitar trabajos pendientes en colas insalvables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [La Amazon Builders' Library: Desafíos y estrategias del almacenamiento en caché](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [La Amazon Builders' Library: Tiempos de espera, reintentos y retroceso con alteración](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Reintento, retroceso y alteración: AWS re:Invent 2019: Presentación de Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 Responder rápido a los errores y limitar las colas
Si la carga de trabajo no puede ofrecer una respuesta correcta a una solicitud, debe producir un error rápidamente. Esto permite que se liberen recursos asociados con solicitudes y que un servicio se recupere cuando se le agotan los recursos. Si la carga de trabajo puede proporcionar una respuesta adecuada, pero la tasa de solicitudes es demasiado alta, use una cola para almacenar las solicitudes en un búfer. Sin embargo, no permita que por el hecho de que existan colas grandes se atiendan solicitudes antiguas que el cliente ya ha abandonado.
Esta práctica recomendada se aplica al servidor, o receptor de la solicitud.
Tenga en cuenta que las colas de espera se pueden crear en varios niveles de un sistema y que pueden obstaculizar gravemente la capacidad de recuperación rápida, ya que las solicitudes antiguas (que ya no necesitan una respuesta) se procesan antes que las nuevas. Tenga en cuenta en qué ubicaciones están las colas. A menudo se encuentran en los flujos de trabajo o en trabajos que se registran en una base de datos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Responda rápido a los errores y limite las colas. Si la carga de trabajo no puede ofrecer una respuesta correcta a una solicitud, debe producir un error rápidamente. Esto permite que se liberen recursos asociados con solicitudes y que un servicio se recupere cuando se le agotan los recursos. Si la carga de trabajo puede proporcionar una respuesta adecuada, pero la tasa de solicitudes es demasiado alta, use una cola para almacenar las solicitudes en un búfer. Sin embargo, no permita que por el hecho de que existan colas grandes se atiendan solicitudes antiguas que el cliente ya ha abandonado.
+ Implemente una respuesta rápida a los errores cuando el servicio está bajo presión.
+ [Respuesta rápida a errores](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ Limite las colas: en un sistema basado en colas, cuando se detiene el procesamiento pero siguen llegando mensajes, los mensajes pendientes pueden seguir acumulándose en un depósito grande de trabajos pendientes, lo que aumenta el tiempo de procesamiento. El trabajo se puede completar demasiado tarde para que los resultados sean útiles, lo que afectaría a la disponibilidad, que es justo lo que se suponía que las colas deberían proteger.
+ [La Amazon Builders' Library: Evitar trabajos pendientes en colas insalvables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## Recursos
**Documentos relacionados:**
+ [Error Retries and Exponential Backoff in AWS (Reintentos en caso de error y retroceso exponencial en AWS)](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Respuesta rápida a errores](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [La Amazon Builders' Library: Evitar el retroceso en sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [La Amazon Builders' Library: Evitar trabajos pendientes en colas insalvables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [La Amazon Builders' Library: Desafíos y estrategias del almacenamiento en caché](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [La Amazon Builders' Library: Tiempos de espera, reintentos y retroceso con alteración](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Reintento, retroceso y alteración: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (Presentación de Amazon Builders’ Library) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 Definir tiempos de espera del cliente
Defina tiempos de espera apropiados, verifíquelos sistemáticamente y no use los valores predeterminados, ya que suelen ser demasiado altos
Esta práctica recomendada se aplica al lado del cliente o emisor de la solicitud.
Defina un tiempo de espera de conexión y un tiempo de espera de solicitud en todas las llamadas remotas y, normalmente, en todas las llamadas de los procesos. Muchos marcos ofrecen funciones de tiempo de espera integradas, pero use estas funciones con precaución ya que muchas tienen valores predeterminados que son infinitos o demasiado altos. Un valor demasiado alto reduce la utilidad del tiempo de espera porque se siguen consumiendo recursos mientras el cliente espera a que transcurra el tiempo de espera. Un valor demasiado bajo puede generar un aumento del tráfico en el backend y un aumento de la latencia debido a demasiados reintentos de las solicitudes. En algunos casos, esto puede producir una interrupción completa si se reintentan todas las solicitudes.
Para obtener más información sobre cómo Amazon usa los tiempos de espera, los reintentos y el retardo con fluctuación, consulte [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Defina un tiempo de espera de conexión y un tiempo de espera de solicitud en todas las llamadas remotas y, normalmente, en todas las llamadas de los procesos. Muchos marcos ofrecen funciones de tiempo de espera integradas, pero use estas funciones con precaución ya que muchas tienen valores predeterminados que son infinitos o demasiado altos. Un valor demasiado alto reduce la utilidad del tiempo de espera porque se siguen consumiendo recursos mientras el cliente espera a que transcurra el tiempo de espera. Un valor demasiado bajo puede generar un aumento del tráfico en el backend y un aumento de la latencia debido a demasiados reintentos de las solicitudes. En algunos casos, esto puede producir una interrupción completa si se reintentan todas las solicitudes.
+ [SDK de AWS: reintentos y tiempos de espera](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## Recursos
**Documentos relacionados:**
+ [SDK de AWS: reintentos y tiempos de espera](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: limitar las solicitudes de API para un mayor rendimiento](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Reintentos en caso de error y retroceso exponencial en AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [La Amazon Builders' Library: Tiempos de espera, reintentos y retroceso con alteración](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Reintento, retroceso y alteración: AWS re:Invent 2019: Presentación de Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 Crear servicios sin estado cuando sea posible
Los servicios deben o bien no requerir estado o bien descargar el estado, de forma que entre solicitudes de clientes distintos no haya dependencia en los datos almacenados localmente en disco y en memoria. Esto permite reemplazar los servidores a voluntad sin que la disponibilidad resulte afectada. Amazon ElastiCache y Amazon DynamoDB son buenos destinos para el estado descargado.
![\[En esta aplicación web sin estado, el estado de la sesión se descarga en Amazon ElastiCache.\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
Cuando los usuarios o los servicios interactúan con una aplicación, suelen realizar una serie de interacciones que constituyen una sesión. Una sesión es un dato único para los usuarios que persiste entre las solicitudes mientras utilizan la aplicación. Una aplicación sin estado es aquella que no necesita conocer las interacciones anteriores y no almacena la información de la sesión.
Una vez se ha diseñado para no tener estado, puede utilizar servicios de computación sin servidor, como AWS Lambda o AWS Fargate.
Además del reemplazo del servidor, otro beneficio de las aplicaciones sin estado es que pueden escalar horizontalmente porque cualquiera de los recursos de computación disponibles (como las instancias EC2 y funciones AWS Lambda) puede dar servicio a cualquier solicitud.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Haga que sus aplicaciones no tengan estado. Las aplicaciones sin estado permiten el escalado horizontal y toleran el error de un nodo individual.
+ Elimine el estado que realmente podría almacenarse en parámetros de solicitud.
+ Tras examinar si el estado es realmente necesario, mueva cualquier seguimiento de estado a una caché o un almacén de datos resilientes de varias zonas como Amazon ElastiCache, Amazon RDS, Amazon DynamoDB o una solución de datos distribuidos de terceros. Almacene el estado que no se pudo mover a almacenes de datos resilientes.
+ Algunos datos (como las cookies) se pueden pasar a encabezados o parámetros de consulta.
+ Refactorice para eliminar el estado que se puede pasar rápidamente a las solicitudes.
+ Algunos datos pueden no resultar realmente necesarios para la solicitud y pueden recuperarse bajo demanda.
+ Elimine los datos que se puedan recuperar asincrónicamente.
+ Elija un almacén de datos que cumpla los requisitos para el estado requerido.
+ Considere la posibilidad de usar una base de datos NoSQL para datos no relacionales.
## Recursos
**Documentos relacionados:**
+ [La Amazon Builders' Library: Evitar el retroceso en sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [La Amazon Builders' Library: Evitar trabajos pendientes en colas insalvables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [La Amazon Builders' Library: Desafíos y estrategias del almacenamiento en caché](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 Implementar recursos de emergencia
Los recursos de emergencia son procesos rápidos que pueden mitigar el impacto en la disponibilidad en su carga de trabajo.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Implemente recursos de emergencia. Se trata de procesos rápidos que pueden mitigar el impacto en la disponibilidad de su carga de trabajo. Se pueden operar en ausencia de una causa raíz. Un recurso de emergencia ideal reduciría la carga cognitiva de las personas encargadas de la resolución a cero al proporcionar criterios de activación y desactivación totalmente deterministas. Estos recursos de emergencia suelen ser manuales, pero también se pueden automatizar.
+ Entre los recursos de emergencia se incluyen:
+ Bloqueo de todo el tráfico robótico
+ Presentación de páginas estáticas en lugar de páginas dinámicas
+ Reducción de la frecuencia de llamadas a una dependencia
+ Limitación de llamadas desde dependencias
+ Consejos para implementar y usar recursos de emergencia
+ Al activar los recursos de emergencia, trabaje MENOS, no más.
+ Cree recursos sencillos y evite el comportamiento bimodal.
+ Pruébelos periódicamente.
+ Estos son ejemplos de acciones que NO son recursos de emergencia.
+ Añadir capacidad
+ Llamar a los propietarios de servicio que dependen del servicio y pedirles que reduzcan las llamadas
+ Realizar un cambio en el código y publicarlo
# Administración de cambios
**Topics**
+ [REL 6 ¿Cómo supervisa los recursos de las cargas de trabajo?](w2aac19b9b9b5.md)
+ [REL 7 ¿Cómo diseña su carga de trabajo para que se adapte a los cambios en la demanda?](w2aac19b9b9b7.md)
+ [REL 8 ¿Cómo implementa los cambios?](w2aac19b9b9b9.md)
# REL 6 ¿Cómo supervisa los recursos de las cargas de trabajo?
Los registros y las métricas son una potente herramienta para obtener información sobre el estado de sus cargas de trabajo. Puede configurar su carga de trabajo de forma que supervise registros y métricas, y envíe notificaciones cuando se crucen ciertos umbrales o se produzcan eventos importantes. La supervisión permite que su carga de trabajo reconozca cuándo se cruzan umbrales de bajo rendimiento o se producen errores, para que pueda recuperarse de los errores rápidamente una vez recibida una respuesta.
**Topics**
+ [REL06-BP01 Supervisar todos los componentes de la carga de trabajo (generación)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 Definir y calcular métricas (agregación)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 Enviar notificaciones (procesamiento y alarmas en tiempo real)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 Automatizar las respuestas (procesamiento y alarmas en tiempo real)](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 Análisis](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 Realizar revisiones con frecuencia](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 Supervisar el seguimiento de las solicitudes de principio a fin en todo el sistema](rel_monitor_aws_resources_end_to_end.md)
# REL06-BP01 Supervisar todos los componentes de la carga de trabajo (generación)
Supervise los componentes de la carga de trabajo con Amazon CloudWatch o herramientas de terceros. Supervise los servicios de AWS con el panel de AWS Health.
Debería supervisar todos los componentes de su carga de trabajo, incluidos los niveles del front-end, la lógica empresarial y el almacenamiento. Defina métricas claves, describa cómo extraerlas de los registros (si fuera necesario) y establezca umbrales para desencadenar los eventos de alarma correspondientes. Asegúrese de que las métricas sean pertinentes para los indicadores clave de rendimiento (KPI) de su carga de trabajo, y utilice métricas y registros para identificar signos de advertencia tempranos de degradación del servicio. Por ejemplo, una métrica relacionada con los resultados empresariales como el número de pedidos procesado satisfactoriamente por minuto, puede indicar problemas con la carga de trabajo más rápido que una métrica técnica, como el uso de la CPU. Utilice el panel de AWS Health para obtener una vista personalizada sobre el rendimiento y la disponibilidad de los servicios de AWS subyacentes a sus recursos de AWS.
La supervisión en la nube ofrece nuevas oportunidades. La mayoría de proveedores en la nube han desarrollado enlaces personalizables y pueden proporcionar conocimientos para ayudarle a supervisar varias capas de su carga de trabajo. Los servicios de AWS como Amazon CloudWatch aplican algoritmos estadísticos y de machine learning para analizar continuamente las métricas de los sistemas y aplicaciones, determinar las bases de referencia normales y hacer aflorar anomalías con una intervención mínima del usuario. Los algoritmos de detección de anomalías tienen en cuenta la estacionalidad y los cambios en las tendencias de las métricas.
AWS pone a disposición una gran cantidad de información de supervisión y registro para el consumo que se puede usar para definir métricas específicas de la carga de trabajo, procesos de cambio en la demanda y adoptar técnicas de machine learning independientemente de los conocimientos sobre ML.
Además, puede supervisar todos sus puntos de conexión externos para asegurarse de que sean independientes de su implementación base. Esta supervisión activa se puede llevar a cabo con transacciones sintéticas (a las que a veces se denomina *«canaries» de usuario*, y que no deben confundirse con los despliegues de valores controlados o «canary»), que ejecutan periódicamente varias tareas comunes que se ajustan a las acciones realizadas por los clientes de la carga de trabajo. Mantenga una duración breve para estas tareas y asegúrese de no sobrecargar sus cargas de trabajo durante las pruebas. Amazon CloudWatch Synthetics le permite: [crear pruebas de transacciones o «canaries» sintéticas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) para supervisar sus puntos de conexión y API. También puede combinar los nodos de cliente de la «canary» sintética con la consola de AWS X-Ray para detectar qué «canaries» sintéticas están teniendo problemas de errores, fallos o limitaciones para el periodo de tiempo seleccionado.
**Resultado deseado:**
Recopilar y usar métricas esenciales de todos los componentes de la carga de trabajo para garantizar la fiabilidad de la carga de trabajo y una experiencia de usuario óptima. Detectar que una carga de trabajo no consigue los resultados empresariales le permite declarar rápidamente una situación de desastre y recuperarse de un incidente.
**Patrones de uso no recomendados comunes:**
+ Supervisar solamente las interfaces externas con su carga de trabajo
+ No generar métricas específicas de una carga de trabajo y basarse solamente en las métricas que proporcionan los servicios de AWS que usa su carga de trabajo.
+ Usar exclusivamente métricas técnicas en su carga de trabajo y no supervisar las métricas relacionadas con KPI no técnicos a los que contribuye la carga de trabajo.
+ Basarse en el tráfico de producción y las comprobaciones de estado sencillas para supervisar y evaluar el estado de las cargas de trabajo.
**Beneficios de establecer esta práctica recomendada:** La supervisión de todos los niveles de la carga de trabajo le permite prever y resolver los problemas rápidamente en los componentes de la carga de trabajo.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
1. **Habilite el registro cuando esté disponible.** La supervisión de los datos debe obtenerse a partir de todos los componentes de las cargas de trabajo. Active métodos de registro adicionales, como los registros de acceso de S3, y permita que su carga de trabajo registre datos específicos de la carga de trabajo. Recopile métricas para los promedios de CPU, E/S de red y E/S de disco de servicios como Amazon ECS, Amazon EKS, Amazon EC2, Elastic Load Balancing, AWS Auto Scaling y Amazon EMR. Consulte [Servicios de AWS que publican métricas de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) para consultar una lista de servicios de AWS que publican métricas en CloudWatch.
1. **Revise todas las métricas predeterminadas y explore las carencias en cuanto a recopilación de datos.** Todos los servicios generan métricas predeterminadas. La recopilación de métricas predeterminadas le permite comprender mejor las dependencias entre los componentes de la carga de trabajo, y cómo la fiabilidad y el rendimiento de los componentes afectan a la carga de trabajo. También puede crear y [publicar sus propias métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) en CloudWatch utilizando la AWS CLI o una API. Esto
1. **Evalúe todas las métricas para decidir sobre cuáles alertar en cada servicio de AWS en su carga de trabajo.** Puede decidir seleccionar un subconjunto de métricas que tenga un impacto importante en la fiabilidad de la carga de trabajo. Al centrarse en las métricas y umbrales críticos, podrá refinar el número de alertas [de emergencia](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) y contribuir a reducir al mínimo los falsos positivos.
1. **Defina las alertas y los procesos de recuperación para su carga de trabajo una vez que se active la alerta.** La definición de alertas le permite notificar, escalar y seguir los pasos necesarios rápidamente para recuperarse de un incidente y cumplir el objetivo de tiempo de recuperación (RTO) prescrito. Puede usar [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) para invocar flujos de trabajo automatizados e iniciar procedimientos de recuperación basados en los umbrales definidos.
1. **Explore el uso de transacciones sintéticas para recopilar datos relevantes sobre el estado de las cargas de trabajo.** La supervisión sintética sigue las mismas rutas y lleva a cabo las mismas acciones que un cliente, lo que le permite verificar continuamente su experiencia de usuario incluso si no tiene tráfico de cliente en sus cargas de trabajo. Al usar [transacciones sintéticas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html), puede detectar los problemas antes de que lo hagan los clientes.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL11-BP03 Automatizar la reparación en todas las capas](rel_withstand_component_failures_auto_healing_system.md)
**Documentos relacionados:**
+ [Introducción al panel de AWS Health: estado de su cuenta](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)
+ [Servicios de AWS que publican métricas de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Registros de acceso para su Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html)
+ [Registros de acceso para su Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [Acceso a Amazon CloudWatch Logs para AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)
+ [Registro de acceso al servidor de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
+ [Habilitar los registros de acceso para su Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html)
+ [Exportación de datos de registro a Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Instalar el agente de CloudWatch en una instancia Amazon EC2](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)
+ [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Uso de paneles de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Uso de métricas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Uso de «canaries» (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [¿Qué son Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**Guías del usuario:**
+ [Cree un registro de seguimiento](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)
+ [Supervisión de memoria y métricas del disco para las instancias Linux de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
+ [Uso de CloudWatch Logs con instancias de contenedor](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Registros de flujo de VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
+ [¿Qué es Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [¿Qué es AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**Blogs relacionados:**
+ [Depuración con Amazon CloudWatch Synthetics y AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
**Ejemplos relacionados y talleres:**
+ [Laboratorios de AWS Well-Architected: excelencia operativa - supervisión de dependencias](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/)
+ [La Amazon Builders' Library: Instrumentación de los sistemas distribuidos para la visibilidad de las operaciones](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Taller sobre observabilidad](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 Definir y calcular métricas (agregación)
Almacene los datos de registro y aplique filtros cuando sea necesario para calcular métricas, como las veces que se produce un evento de registro específico o la latencia calculada a partir de las marcas temporales del evento de registro.
Amazon CloudWatch y Amazon S3 sirven como las capas principales de agregación y almacenamiento. En algunos servicios, como AWS Auto Scaling y Elastic Load Balancing, las métricas predeterminadas se proporcionan listas para usar para la carga de CPU o la latencia promedio de solicitudes en un clúster o instancia. En servicios de streaming, como VPC Flow Logs o AWS CloudTrail, los datos del evento se envían a CloudWatch Logs y debe definir y aplicar filtros para extraer las métricas de los datos del evento. Esto le presenta datos sobre las series temporales, que pueden servir como entradas para las alarmas de CloudWatch que defina para activar las alertas.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Defina y calcule métricas (agregación). Almacene los datos de registro y aplique filtros cuando sea necesario para calcular métricas, como las veces que se produce un evento de registro específico o la latencia calculada de las marcas temporales del evento de registro.
+ Los filtros de métricas definen los términos y patrones que analizar en los datos de registro a medida que se envían a CloudWatch Logs. CloudWatch Logs usa estos filtros para convertir los datos de registro en métricas numéricas de CloudWatch que puede representar en gráficas o a partir de las cuales puede establecer alarmas.
+ [Buscar y filtrar datos de registro](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ Use un tercero de confianza para agregar registros.
+ Siga las instrucciones de la solución externa. La mayoría de los productos de terceros se integran con CloudWatch y Amazon S3.
+ Algunos servicios de AWS pueden publicar registros directamente en Amazon S3. Si su requisito principal para los registros es almacenarlos en Amazon S3, puede hacer que el servidor que crea los registros los envíe directamente a Amazon S3 sin instalar infraestructura adicional.
+ [Enviar registros directamente a Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
## Recursos
**Documentos relacionados:**
+ [Consultas de ejemplo de Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Depuración con Amazon CloudWatch Synthetics y AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Taller sobre observabilidad](https://observability.workshop.aws/)
+ [Buscar y filtrar datos de registro](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Enviar registros directamente a Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
+ [La Amazon Builders' Library: Instrumentación de los sistemas distribuidos para la visibilidad de las operaciones](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP03 Enviar notificaciones (procesamiento y alarmas en tiempo real)
Las organizaciones que deben estar informadas reciben notificaciones cuando ocurren eventos importantes.
Se pueden enviar alertas a los temas de Amazon Simple Notification Service (Amazon SNS) y luego enviárselas a cualquier número de suscriptores. Por ejemplo, Amazon SNS puede reenviar alertas a un alias de correo electrónico para que el personal técnico pueda responder.
**Patrones de uso no recomendados comunes:**
+ Configurar alarmas con un umbral demasiado bajo, lo que causa que se envíen demasiadas notificaciones.
+ No archivar las alarmas para su investigación futura.
**Beneficios de establecer esta práctica recomendada:** las notificaciones de los eventos (incluso aquellas que se pueden responder y resolver automáticamente) le permiten tener un registro de eventos y, potencialmente, abordarlos de distinta manera en un futuro.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Realice el procesamiento y envío de alarmas en tiempo real. Las organizaciones que deben estar informadas reciben notificaciones cuando ocurren eventos importantes.
+ Los paneles de Amazon CloudWatch son páginas de inicio personalizables de la consola de CloudWatch que puede usar para supervisar los recursos en una sola vista, incluso aquellos que están repartidos por diferentes regiones.
+ [Uso de paneles de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ Cree una alarma cuando la métrica supera un límite.
+ [Uso de alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Recursos
**Documentos relacionados:**
+ [Taller sobre observabilidad](https://observability.workshop.aws/)
+ [La Amazon Builders' Library: Instrumentación de los sistemas distribuidos para la visibilidad de las operaciones](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Uso de alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Uso de paneles de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Uso de métricas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# REL06-BP04 Automatizar las respuestas (procesamiento y alarmas en tiempo real)
Use la automatización para actuar cuando se detecte un evento, por ejemplo, para sustituir componentes defectuosos.
Las alertas pueden desencadenar eventos de AWS Auto Scaling, por lo que los clústeres reaccionan a los cambios en la demanda. Las alertas se pueden enviar a Amazon Simple Queue Service (Amazon SQS), lo que puede servir como punto de integración para sistemas de tickets de terceros. AWS Lambda también puede suscribirse a alertas, lo que facilita a los usuarios un modelo sin servidor y asíncrono que reacciona a los cambios dinámicamente. AWS Config supervisa y registra continuamente sus configuraciones de recursos de AWS y puede activar [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) para corregir problemas.
Amazon DevOps Guru puede supervisar automáticamente los recursos de la aplicación en busca de un comportamiento anómalo y ofrecer recomendaciones específicas para reducir el tiempo de identificación y resolución de problemas.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Use Amazon DevOps Guru para llevar a cabo acciones automatizadas. Amazon DevOps Guru puede supervisar automáticamente los recursos de la aplicación en busca de un comportamiento anómalo y ofrecer recomendaciones específicas para reducir el tiempo de identificación y resolución de problemas.
+ [¿Qué es Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ Utilice AWS Systems Manager para llevar a cabo acciones automatizadas. AWS Config supervisa y registra continuamente sus configuraciones de recursos de AWS, y puede activar la automatización de AWS Systems Manager para corregir problemas.
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Cree y use documentos de Systems Manager Automation. Estos documentos definen las acciones que Systems Manager realiza en sus instancias administradas y otros recursos de AWS cuando se ejecuta una automatización.
+ [Trabajar con documentos de automatización (guías de estrategias)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ Amazon CloudWatch envía eventos de cambio de estados de alarma a Amazon EventBridge. Cree reglas de EventBridge para automatizar las respuestas.
+ [Creación de una regla de EventBridge que se active cuando se produzca un evento desde un recurso de AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ Cree y ejecute un plan para automatizar las respuestas.
+ Registre en un inventario todos los procedimientos de respuesta a alertas. Debe planificar las respuestas a las alertas antes de clasificar las tareas.
+ Registre en un inventario todas las tareas con acciones específicas que se deben realizar. La mayoría de estas acciones se documentan en runbooks. También debe tener guías de estrategias para alertas de eventos imprevistos.
+ Examinar los runbooks y las guías de estrategias para todas las acciones automatizables. En general, si una acción se puede definir, lo más probable es que se pueda automatizar.
+ Clasifique primero las actividades propensas a errores o que requieran mucho tiempo. Es más conveniente eliminar las fuentes de error y reducir el tiempo de resolución.
+ Establezca un plan para completar la automatización. Mantenga un plan activo para automatizar y actualizar la automatización.
+ Examine los requisitos manuales para identificar oportunidades de automatización. Revise el proceso manual en busca de oportunidades de automatización.
## Recursos
**Documentos relacionados:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Creación de una regla de EventBridge que se active cuando se produzca un evento desde un recurso de AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ [Taller sobre observabilidad](https://observability.workshop.aws/)
+ [La Amazon Builders' Library: Instrumentación de los sistemas distribuidos para la visibilidad de las operaciones](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [¿Qué es Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [Trabajar con documentos de automatización (guías de estrategias)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
# REL06-BP05 Análisis
Recopile archivos de registros e historiales de métricas y analícelos para identificar tendencias e información sobre las cargas de trabajo.
Amazon CloudWatch Logs Insights es compatible con un [lenguaje de consultas sencillo pero potente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) que puede usar para analizar datos de registro. Amazon CloudWatch Logs también admite suscripciones que permiten a los datos dirigirse de forma fluida hacia Amazon S3, donde podrá usar Amazon Athena para consultar los datos. También es compatible con consultas en una gran variedad de formatos. Consulte [Formatos de SerDes y datos compatibles](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) en la Guía del usuario de Amazon Athena para obtener más información. Para los análisis de conjuntos de archivos de registro enormes, puede ejecutar un clúster de Amazon EMR para ejecutar análisis en la escala de los petabytes.
Hay una serie de herramientas proporcionadas por socios de AWS y terceros que permiten la agregación, procesamiento, almacenamiento y análisis. Entre estas herramientas se incluyen New Relic, Splunk, Loggly, Logstash, CloudHealth y Nagios. Sin embargo, la generación fuera de los registros del sistema y las aplicaciones es exclusiva de cada proveedor de la nube y, a menudo, exclusiva de cada servicio.
Una parte del proceso de monitoreo que a menudo se pasa por alto es la gestión de datos. Necesita determinar los requisitos de retención para supervisar los datos y, luego, aplicar las políticas del ciclo de vida correspondientemente. Amazon S3 permite la administración del ciclo de vida en el nivel del bucket de S3. Esta gestión del ciclo de vida se puede aplicar de manera diferente a diferentes rutas en el bucket. Hacia el final del ciclo de vida, puede realizar la transición de datos a Amazon Glacier para el almacenamiento a largo plazo y vencimiento, una vez alcanzado el final del periodo de retención. La clase de almacenamiento de S3 Intelligent-Tiering está diseñado para optimizar los costos trasladando automáticamente los datos al nivel de acceso más eficiente, sin que se vea afectado el rendimiento ni los gastos generales operativos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ CloudWatch Logs Insights le permite buscar y analizar de forma interactiva sus datos de registro en Amazon CloudWatch Logs.
+ [Análisis de los datos de registro con CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Consultas de ejemplo de Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ Use Amazon CloudWatch Logs para enviar registros a Amazon S3, donde puede usar Amazon Athena para consultar los datos.
+ [¿Cómo analizo mis registros de acceso al servidor de Amazon S3 mediante Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ Cree una política de ciclo de vida de S3 para su bucket de registros de acceso al servidor. Configure la política de ciclo de vida para que se eliminen periódicamente los archivos de registros. De esta forma, reducirá la cantidad de datos que analiza Athena en cada consulta.
+ [¿Cómo creo una política de ciclo de vida para un bucket de S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
## Recursos
**Documentos relacionados:**
+ [Consultas de ejemplo de Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Análisis de los datos de registro con CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Depuración con Amazon CloudWatch Synthetics y AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [¿Cómo creo una política de ciclo de vida para un bucket de S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
+ [¿Cómo analizo mis registros de acceso al servidor de Amazon S3 mediante Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ [Taller sobre observabilidad](https://observability.workshop.aws/)
+ [La Amazon Builders' Library: Instrumentación de los sistemas distribuidos para la visibilidad de las operaciones](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 Realizar revisiones con frecuencia
Revise frecuentemente cómo está implementada la supervisión de cargas de trabajo y actualícela en función de eventos y cambios importantes.
La supervisión efectiva se basa en métricas empresariales claves. Asegúrese de que estas métricas tengan cabida en su carga de trabajo a medida que cambien las prioridades empresariales.
La auditoría de su supervisión le permite asegurarse de que sabrá cuándo cumple una aplicación con sus objetivos de disponibilidad. El análisis de las causas raíces requiere la capacidad de descubrir qué ha ocurrido cuando se produce un error. AWS facilita servicios que le permiten realizar un seguimiento del estado de sus servicios durante un incidente:
+ **Amazon CloudWatch Logs:** puede almacenar sus registros en este servicio e inspeccionar sus contenidos.
+ **Amazon CloudWatch Logs Insights**: es un servicio totalmente administrado que le permite analizar registros inmensos en segundos. Le ofrece consultas y visualizaciones rápidas e interactivas.
+ **AWS Config:** puede ver qué infraestructura de AWS se ha estado utilizando en diferentes momentos.
+ **AWS CloudTrail:** puede ver qué API de AWS se invocaron en qué momento y desde qué entidad principal.
En AWS, realizamos una reunión semanal para [revisar el rendimiento operativo](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) y compartir lo que hemos aprendido entre los equipos. Como hay tantos equipos en AWS, creamos [La rueda](https://aws.amazon.com/blogs/opensource/the-wheel/) para elegir al azar una carga de trabajo que revisar. El establecimiento de una cadencia regular para las revisiones de rendimiento operativo y el intercambio de conocimientos mejorará su capacidad para lograr un mayor rendimiento de sus equipos operativos.
**Patrones de uso no recomendados comunes:**
+ Recopilar solo métricas predeterminadas
+ Establecer una estrategia de supervisión y no revisarla nunca
+ No considerar la supervisión cuando se implementan cambios importantes
**Beneficios de establecer esta práctica recomendada:** la revisión periódica de la supervisión le permite anticiparse a los posibles problemas en lugar de reaccionar a las notificaciones cuando se produzca un problema previsto.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Cree varios paneles para la carga de trabajo. Debe tener un panel general que contenga las principales métricas del negocio, así como las métricas técnicas que ha identificado como más relevantes para el estado previsto de la carga de trabajo conforme cambie su uso. También debe tener paneles para los distintos niveles y dependencias de la aplicación que puedan inspeccionarse.
+ [Uso de paneles de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ Programe y realice revisiones periódicas de los paneles de cargas de trabajo. Realice una inspección periódica de los paneles. Puede tener diferentes cadencias para el alcance de la inspección.
+ Inspeccione las tendencias en las métricas. Compare los valores de las métricas con los valores históricos para saber si hay tendencias que puedan indicar que algo necesita ser investigado. Algunos ejemplos son un aumento de la latencia, una reducción de la función empresarial principal y un aumento de las respuestas a los errores.
+ Inspeccione valores atípicos o anomalías en las métricas. Los promedios o las medianas pueden ocultar valores atípicos y anomalías. Examine los valores más altos y más bajos durante el período de tiempo e investigue las causas de los valores extremos. Mientras elimina estas causas, la relajación de la definición de «extremo» le permitirá seguir mejorando la sistematicidad del rendimiento de sus cargas de trabajo.
+ Busque cambios bruscos en el comportamiento. Un cambio inmediato en la cantidad o en la dirección de una métrica podría indicar que se ha producido un cambio en la aplicación o factores externos que podrían necesitar la inclusión de métricas adicionales para su seguimiento.
## Recursos
**Documentos relacionados:**
+ [Consultas de ejemplo de Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Depuración con Amazon CloudWatch Synthetics y AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Taller sobre observabilidad](https://observability.workshop.aws/)
+ [La Amazon Builders' Library: Instrumentación de los sistemas distribuidos para la visibilidad de las operaciones](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Uso de paneles de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
# REL06-BP07 Supervisar el seguimiento de las solicitudes de principio a fin en todo el sistema
Use AWS X-Ray o herramientas de terceros para que los desarrolladores puedan analizar y depurar fácilmente los sistemas distribuidos para conocer el rendimiento de sus aplicaciones y servicios subyacentes.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Supervise el seguimiento de las solicitudes de principio a fin en todo el sistema. AWS X-Ray es un servicio que recopila datos sobre las solicitudes que sirve su aplicación y proporciona herramientas que puede usar para ver, filtrar y obtener información de esos datos con el fin de identificar problemas y oportunidades de optimización. Puede ver información detallada no solo de cualquier solicitud seguida que se envíe a su aplicación y su respuesta, sino también de las llamadas que realiza la aplicación a recursos, microservicios, bases de datos y API web de AWS que se encuentren en un punto posterior del proceso.
+ [¿Qué es AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Depuración con Amazon CloudWatch Synthetics y AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
## Recursos
**Documentos relacionados:**
+ [Depuración con Amazon CloudWatch Synthetics y AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Taller sobre observabilidad](https://observability.workshop.aws/)
+ [La Amazon Builders' Library: Instrumentación de los sistemas distribuidos para la visibilidad de las operaciones](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Uso de valores controlados (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [¿Qué es AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
# REL 7 ¿Cómo diseña su carga de trabajo para que se adapte a los cambios en la demanda?
Una carga de trabajo escalable proporciona elasticidad para agregar y eliminar recursos automáticamente a fin de que coincidan estrechamente con la demanda actual en cualquier momento dado.
**Topics**
+ [REL07-BP01 Usar la automatización al obtener o escalar recursos](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 Obtener recursos tras detectar un impedimento en una carga de trabajo](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 Obtener recursos tras detectar que se necesitan más recursos para una carga de trabajo](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 Realizar pruebas de la carga de trabajo](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 Usar la automatización al obtener o escalar recursos
Cuando reemplace recursos deteriorados o escale su carga de trabajo, automatice el proceso mediante el uso de servicios de AWS administrados, como Amazon S3 y AWS Auto Scaling. También puede utilizar herramientas de terceros y los SDK de AWS para automatizar el escalado.
Los servicios de AWS administrados incluyen Amazon S3, Amazon CloudFront, AWS Auto Scaling, AWS Lambda, Amazon DynamoDB, AWS Fargate y Amazon Route 53.
AWS Auto Scaling le permite detectar y reemplazar las instancias deterioradas. También le permite crear planes de escalado para los recursos, como instancias [Amazon EC2](https://aws.amazon.com/ec2/) y flotas de spot, tareas de [Amazon ECS](https://aws.amazon.com/ecs/) , tablas e índices de [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) y réplicas de [Amazon Aurora](https://aws.amazon.com/aurora/) .
Al escalar las instancias EC2, asegúrese de que utiliza varias zonas de disponibilidad (preferiblemente tres como mínimo) y agregue o elimine capacidad para mantener el equilibrio entre estas zonas de disponibilidad. Las tareas de ECS o los pods de Kubernetes (cuando se utiliza Amazon Elastic Kubernetes Service) también se deben distribuir en varias zonas de disponibilidad.
Al utilizar AWS Lambda, las instancias se escalan automáticamente. Cada vez que se recibe una notificación de evento para su función, AWS Lambda localiza rápidamente la capacidad libre en su flota de computación y ejecuta su código hasta la simultaneidad asignada. Debe asegurarse de que la simultaneidad necesaria está configurada en Lambda específico y en su Service Quotas.
Amazon S3 se escala automáticamente para gestionar las altas tasas de solicitudes. Por ejemplo, su aplicación puede alcanzar al menos 3500 solicitudes PUT/COPY/POST/DELETE o 5500 solicitudes GET/HEAD por segundo y prefijo en un bucket. No hay límites en el número de prefijos de un bucket. Puede aumentar su rendimiento de lectura o escritura si ejecuta en paralelo las lecturas. Por ejemplo, si crea diez prefijos en un bucket de Amazon S3 para ejecutar en paralelo las lecturas, podría escalar su rendimiento de lectura a 55 000 solicitudes de lectura por segundo.
Configure y use Amazon CloudFront o una red de entrega de contenido (CDN) de confianza. Una CDN puede proporcionar tiempos de respuesta más rápidos al usuario final y puede servir solicitudes de contenido desde la caché, lo que reduce la necesidad de escalar su carga de trabajo.
**Patrones de uso no recomendados comunes:**
+ Implementar grupos de escalado automático para la reparación automatizada, pero no implementar la elasticidad.
+ Utilizar el escalado automático para responder a los grandes aumentos de tráfico.
+ Desplegar aplicaciones con un alto nivel de estado, lo que elimina la opción de la elasticidad.
**Beneficios de establecer esta práctica recomendada:** la automatización elimina la posibilidad de cometer errores manuales al desplegar y retirar los recursos. La automatización elimina el riesgo de sobrecostes y de denegación de servicio debido a la lentitud de respuesta en las necesidades de despliegue o retirada.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Configure y use AWS Auto Scaling. Esto supervisa sus aplicaciones y ajusta automáticamente la capacidad para mantener un rendimiento constante y predecible al menor coste posible. Con AWS Auto Scaling, puede configurar el escalado de aplicaciones para múltiples recursos en varios servicios.
+ [¿Qué es AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ Configure el escalado automático en sus instancias y flotas de spot de Amazon EC2, tareas de Amazon ECS, tablas e índices de Amazon DynamoDB, réplicas de Amazon Aurora y dispositivos de AWS Marketplace según corresponda.
+ [Administración automática de la capacidad de rendimiento con el escalado automático de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ Use las operaciones de la API de servicio para especificar las alarmas, las políticas de escalado, los tiempos de calentamiento y los tiempos de enfriamiento.
+ Use Elastic Load Balancing. Los equilibradores de carga pueden distribuir la carga por ruta o por conectividad de red.
+ [¿Qué es Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ Application Load Balancers puede distribuir la carga por ruta.
+ [¿Qué es un Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ Configure un Application Load Balancer para distribuir el tráfico entre diferentes cargas de trabajo en función de la ruta que corresponde al nombre de dominio.
+ Los Application Load Balancers se pueden utilizar para distribuir las cargas de manera que se integren con AWS Auto Scaling para administrar la demanda.
+ [Usar un equilibrador de carga con un grupo de escalado automático](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ Los equilibradores de carga de red pueden distribuir la carga por conexión.
+ [¿Qué es un equilibrador de carga de red?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ Configure un equilibrador de carga de red para distribuir el tráfico entre diferentes cargas de trabajo mediante TCP o para tener un conjunto constante de direcciones IP para la carga de trabajo.
+ Los equilibradores de carga de red se pueden utilizar para distribuir la carga de manera que se integre con AWS Auto Scaling para administrar la demanda.
+ Use un proveedor de DNS de alta disponibilidad. Los nombres DNS permiten a sus usuarios acceder a sus cargas de trabajo con nombres en lugar de direcciones IP. Esta información se distribuye en un ámbito definido, normalmente de forma global para los usuarios de la carga de trabajo.
+ Utilice Amazon Route 53 o un proveedor de DNS de confianza.
+ [¿Qué es Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ Use Route 53 para administrar las distribuciones de CloudFront y los equilibradores de carga.
+ Determine los dominios y subdominios que va a administrar.
+ Cree conjuntos de registros apropiados mediante registros ALIAS o CNAME.
+ [Trabajar con los registros](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
+ Utilice la red global de AWS para optimizar la ruta desde sus usuarios a sus aplicaciones. AWS Global Accelerator supervisa continuamente el estado de los puntos de conexión de sus aplicaciones y redirige el tráfico a los puntos en estado correcto en menos de 30 segundos.
+ AWS Global Accelerator es un servicio que mejora la disponibilidad y el rendimiento de sus aplicaciones con usuarios locales o globales. Proporciona direcciones IP estáticas que actúan como punto de entrada fijo a los puntos de conexión de aplicaciones en una o varias Regiones de AWS, como sus Application Load Balancers, equilibradores de carga de red o instancias Amazon EC2.
+ [¿Qué es AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ Configure y use Amazon CloudFront o una red de entrega de contenido (CDN) de confianza. Una red de entrega de contenido puede ofrecer tiempos de respuesta más rápidos a los usuarios finales y atender solicitudes de contenido que pueden provocar un escalado innecesario de las cargas de trabajo.
+ [¿Qué es Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ Configure distribuciones de Amazon CloudFront para sus cargas de trabajo o utilice una CDN de terceros.
+ Puede limitar el acceso a sus cargas de trabajo para que solo sean accesibles desde CloudFront mediante los intervalos de IP para CloudFront en sus grupos de seguridad de puntos de conexión o políticas de acceso.
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudarle a crear soluciones informáticas automatizadas](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling: cómo funcionan los planes de escalado](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: productos que pueden usarse con escalo automático](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Administración automática de la capacidad de rendimiento con el escalado automático de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Usar un equilibrador de carga con un grupo de escalado automático](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [¿Qué es AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [¿Qué es Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [¿Qué es AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [¿Qué es Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [¿Qué es Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [¿Qué es Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [¿Qué es un equilibrador de carga de red?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [¿Qué es un Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Trabajar con los registros](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
# REL07-BP02 Obtener recursos tras detectar un impedimento en una carga de trabajo
Escale recursos de forma retroactiva cuando sea necesario si la disponibilidad se ve afectada para restaurar la disponibilidad de la carga de trabajo.
Primero debe configurar las comprobaciones de estado y los criterios de dichas comprobaciones para indicar cuándo se ve afectada la disponibilidad por falta de recursos. A continuación, notifique al personal pertinente para que escale manualmente el recurso o active la automatización, a fin de que el escalado se realice de forma automática.
La escala puede ajustarse manualmente para su carga de trabajo; por ejemplo, se puede cambiar el número de instancias EC2 en un grupo de escalado automático o se puede modificar el rendimiento de una tabla de DynamoDB mediante la Consola de administración de AWS o la AWS CLI. Sin embargo, la automatización se debería usar siempre que sea posible (consulte **Usar la automatización al obtener o escalar recursos**).
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Obtenga recursos tras detectar un impedimento en una carga de trabajo. Escale recursos de forma retroactiva cuando sea necesario si la disponibilidad se ve afectada para restaurar la disponibilidad de la carga de trabajo.
+ Use planes de escalado, que son el componente principal de AWS Auto Scaling, para configurar un conjunto de instrucciones para escalar sus recursos. Si trabaja con AWS CloudFormation o agrega etiquetas a recursos de AWS, puede configurar planes de escalado para diferentes conjuntos de recursos y por aplicación. AWS Auto Scaling proporciona recomendaciones para estrategias de escalado personalizadas para cada recurso. Tras crear su plan de ajuste de escala, AWS Auto Scaling combina el ajuste dinámico y los métodos predictivos de escalado para ayudarle en su estrategia.
+ [AWS Auto Scaling: cómo funcionan los planes de escalado](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Amazon EC2 Auto Scaling le ayuda a garantizar que tenga el número correcto de instancias Amazon EC2 disponibles para gestionar la carga de tu aplicación. Puede crear colecciones de instancias EC2 denominadas grupos de escalado automático. Puede especificar el número mínimo de instancias en cada grupo de escalado automático, y Amazon EC2 Auto Scaling asegura que su grupo nunca tenga un tamaño por debajo de este. Puede especificar el número máximo de instancias en cada grupo de escalado automático, y Amazon EC2 Auto Scaling asegura que su grupo nunca tenga un tamaño por encima de este.
+ [¿Qué es Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ El escalado automático de Amazon DynamoDB usa el servicio de Auto Scaling de aplicaciones de AWS para ajustar dinámicamente la capacidad de rendimiento aprovisionada en su nombre como respuesta a los patrones de tráfico reales. Esto permite que una tabla o un índice secundario global aumente su capacidad de lectoescritura aprovisionada para afrontar los picos repentinos de tráfico sin limitación.
+ [Administrar automáticamente la capacidad de rendimiento con Auto Scaling de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudarle a crear soluciones informáticas automatizadas](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling: cómo funcionan los planes de escalado](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: productos que pueden usarse con Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Administrar automáticamente la capacidad de rendimiento con Auto Scaling de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [¿Qué es Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 Obtener recursos tras detectar que se necesitan más recursos para una carga de trabajo
Escale recursos de forma proactiva para satisfacer la demanda y evitar que la disponibilidad se vea impactada.
Muchos servicios de AWS se escalan automáticamente para satisfacer la demanda. Si usa instancias de Amazon EC2 o clústeres de Amazon ECS, puede configurar su escalado automático para que se lleve a cabo en función de métricas de uso que se correspondan con la demanda para su carga de trabajo. Para Amazon EC2, el uso medio de la CPU, el recuento de solicitudes al equilibrador de carga o el ancho de banda de la red se pueden usar para escalar (o desescalar) horizontalmente instancias de EC2. Para Amazon ECS, el uso medio de la CPU, el recuento de solicitudes al equilibrador de carga o el uso de memoria se pueden usar para escalar (o desescalar) horizontalmente tareas de ECS. Al utilizar el escalado automático por objetivos en AWS, el escalador automático actúa como un termostato doméstico y agrega o retira recursos para mantener el valor objetivo (por ejemplo, un uso de la CPU del 70 %) que haya especificado.
AWS Auto Scaling también puede llevar a cabo [escalado automático predictivo](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/), que utiliza machine learning para analizar la carga de trabajo histórica de cada recurso y predice regularmente la carga futura para los próximos dos días.
La ley de Little ayuda a calcular cuántas instancias de computación (instancias de EC2, funciones Lambda simultáneas, etc.) necesitará.
*R* = *λW*
L = número de instancias (o simultaneidad media en el sistema)
λ = promedio de la tasa de llegada de solicitudes (solicitudes/s)
W = promedio del tiempo que pasa cada solicitud en el sistema (s)
Por ejemplo, a 100 sps, si cada solicitud tarda 0,5 segundos en procesarse, necesitará 50 instancias para satisfacer la demanda.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Obtenga recursos tras detectar que se necesitan más recursos para una carga de trabajo. Escale recursos de forma proactiva para satisfacer la demanda y evitar que la disponibilidad se vea impactada.
+ Calcule cuántos recursos de computación necesitará (simultaneidad de computación) para afrontar una tasa de solicitudes dada.
+ [Presentación de historias sobre la ley de Little](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ Cuando tenga un patrón de uso histórico, configure el escalado programado para el escalado automático de Amazon EC2.
+ [Escalado programado para Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ Use el escalado predictivo de AWS.
+ [Predictive Scaling for EC2, Powered by Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
## Recursos
**Documentos relacionados:**
+ [AWS Auto Scaling: cómo funcionan los planes de escalado](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: productos que pueden usarse con Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Administrar automáticamente la capacidad de rendimiento con Auto Scaling de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Predictive Scaling for EC2, Powered by Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Escalado programado para Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [Presentación de historias sobre la ley de Little](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ [¿Qué es Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP04 Realizar pruebas de la carga de trabajo
Adopte una metodología de prueba de carga para medir si la actividad de escalado satisface los requisitos de la carga de trabajo.
Es importante realizar pruebas de carga sostenidas. Las pruebas de carga deben descubrir el punto de ruptura y probar el rendimiento de su carga de trabajo. AWS facilita la creación de entornos de prueba temporales que modelan la escala de su carga de trabajo de producción. En la nube, puede crear un entorno de prueba a escala de producción, completar sus pruebas y desmantelar los recursos. Debido a que solo paga por el entorno de prueba cuando se ejecuta, puede simular su entorno en directo por una fracción del coste de las pruebas en las instalaciones.
Las pruebas de carga en producción también deben considerarse como parte de los días de juego en los que se estresa el sistema de producción, durante las horas de menor uso por parte de los clientes, con todo el personal a mano para interpretar los resultados y abordar cualquier problema que surja.
**Patrones de uso no recomendados comunes:**
+ Realizar pruebas de carga en despliegues que no tienen la misma configuración que su producción.
+ Realizar pruebas de carga solo en elementos individuales de su carga de trabajo y no en toda ella.
+ Realizar pruebas de carga con un subconjunto de solicitudes y no con un conjunto representativo de solicitudes reales.
+ Realizar pruebas de carga con un pequeño factor de seguridad por encima de la carga prevista.
**Beneficios de establecer esta práctica recomendada:** sabrá qué componentes de su arquitectura presentan errores bajo carga y podrá identificar qué métricas se deben vigilar para indicar que se está acercando a esa carga a tiempo para solucionar el problema, con lo que se evitará el impacto de ese error.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Realice pruebas de carga para identificar qué aspecto de su carga de trabajo indica que debe agregar o eliminar capacidad. Las pruebas de carga deben tener un tráfico representativo similar al que se recibe en producción. Aumente la carga mientras vigila las métricas que ha instrumentado para determinar qué métrica indica cuándo debe agregar o eliminar recursos.
+ [Pruebas de carga distribuida en AWS: simular miles de usuarios conectados](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ Identifique la combinación de solicitudes. Es posible que tenga una combinación variada de solicitudes, por lo que deberá tener en cuenta diversos periodos de tiempo a la hora de identificar la combinación de tráfico.
+ Implemente un controlador de carga. Puede utilizar software de código abierto o comercial para implementar un controlador de carga.
+ Realice la prueba de carga inicialmente con una capacidad pequeña. Se ven algunos efectos inmediatos al pasar la carga a una capacidad menor, posiblemente tan pequeña como una instancia o un contenedor.
+ Realice una prueba de carga con una capacidad mayor. Los efectos serán diferentes en una carga distribuida, por lo que debe realizar las pruebas en un entorno lo más parecido posible al del producto.
## Recursos
**Documentos relacionados:**
+ [Pruebas de carga distribuida en AWS: simular miles de usuarios conectados](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
# REL 8 ¿Cómo implementa los cambios?
Los cambios controlados son necesarios para implementar nueva funcionalidad y garantizar que las cargas de trabajo y el entorno operativo ejecuten software conocido y puedan recibir parches o reemplazos de manera predecible. Si estos cambios no se controlan, puede ser difícil prever su efecto o abordar los problemas que surjan a raíz de ellos.
**Topics**
+ [REL08-BP01 Usar runbooks para actividades estándares como la implementación](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 Integrar las pruebas funcionales como parte de su despliegue](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 Integrar las pruebas de resiliencia como parte de su despliegue](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 Desplegar mediante infraestructura inmutable](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 Desplegar cambios con automatización](rel_tracking_change_management_automated_changemgmt.md)
# REL08-BP01 Usar runbooks para actividades estándares como la implementación
Los runbooks son procedimientos predefinidos para obtener resultados concretos. Use runbooks para realizar actividades estándar manuales o automáticas. Algunos ejemplos incluyen implementar una carga de trabajo, aplicarle un parche a dicha carga de trabajo o realizar modificaciones de DNS.
Por ejemplo, se pueden implementar procesos para [garantizar la seguridad de la restauración durante los despliegues](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments). Tener la garantía de poder dar marcha atrás en un despliegue sin disrupciones para sus clientes es esencial a la hora de hacer que un servicio sea fiable.
Para los procedimientos de runbooks, empiece por un proceso manual efectivo válido, impleméntelo en el código y desencadene la ejecución automatizada cuando sea oportuno.
Incluso en el caso de cargas de trabajo sofisticadas con un alto nivel de automatización los runbooks siguen siendo útiles para [ejecutar días de juego](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) o ajustarse a los exhaustivos requisitos de presentación de informes y auditorí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.
**Patrones de uso no recomendados comunes:**
+ Realizar cambios imprevistos en la configuración en producción
+ Omitir pasos del plan para realizar una implementación más rápida, lo que da lugar a una implementación errónea.
+ Realizar cambios sin probar la revocación del cambio
**Beneficios de establecer esta práctica recomendada:** La planificación eficaz de los cambios aumenta su capacidad de realizar correctamente el cambio, ya que sabrá qué sistemas resultarán afectados. Validar el cambio en los entornos de prueba aumenta la confianza.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Puede obtener respuestas sistemáticas e inmediatas a eventos conocidos si documenta los procedimientos en runbooks.
+ [Conceptos del AWS Well-Architected Framework: runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ Use el principio de la infraestructura como código para definir la infraestructura. Si usa AWS CloudFormation (o un tercero de confianza) para definir su infraestructura, puede utilizar software de control de versiones para crear versiones y hacer seguimiento de los cambios.
+ Use AWS CloudFormation (o un proveedor tercero de confianza) para definir su infraestructura.
+ [¿Qué es AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ Cree plantillas singulares y desacopladas, usando buenos principios de diseño de software.
+ Determine los permisos, las plantillas y las partes responsables de su implementación.
+ [ Control de acceso con AWS Identity and Access Management](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
+ Use herramientas de control de código, como AWS CodeCommit o las de terceros de confianza, para llevar un control de las versiones.
+ [¿Qué es AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudarle a crear soluciones de implementación automatizadas](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: productos que pueden usarse para automatizar sus implementaciones](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Conceptos del AWS Well-Architected Framework: runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ [¿Qué es AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [¿Qué es AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/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/)
# REL08-BP02 Integrar las pruebas funcionales como parte de su despliegue
Las pruebas funcionales se ejecutan como parte de la implementación automatizada. Si no se satisfacen los criterios de éxito, la canalización se detiene o se revierte.
Estas pruebas se llevan a cabo en un entorno de preproducción, que se lleva a cabo antes de la producción en la canalización. Idealmente, esto se realiza como parte de una canalización de despliegue.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Integre las pruebas funcionales como parte de su despliegue. Las pruebas funcionales se ejecutan como parte de la implementación automatizada. Si no se satisfacen los criterios de éxito, la canalización se detiene o se revierte.
+ Invoque AWS CodeBuild durante la «acción de prueba» de sus canalizaciones de lanzamiento de software modeladas en AWS CodePipeline. Esta función le permite ejecutar fácilmente una gran variedad de pruebas en el código, como pruebas unitarias, análisis de código estático y pruebas de integración.
+ [En AWS CodePipeline ahora se pueden hacer 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/)
+ Use soluciones de AWS Marketplace para ejecutar pruebas automatizadas como parte de su canalización de entrega de software.
+ [Automatización de pruebas de software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Recursos
**Documentos relacionados:**
+ [En AWS CodePipeline ahora se pueden hacer 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/)
+ [Automatización de pruebas de software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [¿Qué es AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# REL08-BP03 Integrar las pruebas de resiliencia como parte de su despliegue
Las pruebas de resiliencia (mediante los [principios de la ingeniería del caos](https://principlesofchaos.org/)) se ejecutan como parte de la canalización de despliegue automatizada en un entorno previo a producción.
Estas pruebas se realizan por fases y se ejecutan en la canalización en un entorno previo a la producción. También deben ejecutarse en producción como parte de los [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays).
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Integre las pruebas de resiliencia como parte de su despliegue. Use la ingeniería del caos, la disciplina de poner a prueba una carga de trabajo para generar confianza en su capacidad de resistir condiciones adversas en producción.
+ Las pruebas de resiliencia introducen errores o degradación de los recursos para saber si la carga de trabajo responde con la resiliencia diseñada.
+ [Laboratorio de Well-Architected: Nivel 300: pruebas de resiliencia de EC2 RDS y S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
+ Estas pruebas se pueden ejecutar periódicamente en entornos previos a producción en canalizaciones de implementaciones automatizadas.
+ También deben ejecutarse en producción como parte de los días de juego programados.
+ Usando los principios de ingeniería del caos, proponga hipótesis sobre cómo funcionará la carga de trabajo con distintos errores y después pruebe sus hipótesis mediante pruebas de resiliencia.
+ [Principios de la ingeniería del caos](https://principlesofchaos.org/)
## Recursos
**Documentos relacionados:**
+ [Principios de la ingeniería del caos](https://principlesofchaos.org/)
+ [¿Qué es AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Ejemplos relacionados:**
+ [Laboratorio de Well-Architected: Nivel 300: pruebas de resiliencia de EC2 RDS y S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
# REL08-BP04 Desplegar mediante infraestructura inmutable
La infraestructura inmutable es un modelo que exige que no haya actualizaciones, parches de seguridad ni cambios de configuración en las cargas de trabajo de producción. Cuando es necesario realizar un cambio, la arquitectura se integra en una nueva infraestructura y se implementa en producción.
La implementación más habitual del paradigma de infraestructura inmutable es el ***servidor inmutable***. Esto significa que si un servidor necesita una actualización o una reparación, se despliegan nuevos servidores en lugar de actualizar los que ya están en uso. Por tanto, en lugar de iniciar sesión en un servidor mediante SSH y de actualizar la versión de software, cada cambio en la aplicación se inicia con un push de software en el repositorio de código, por ejemplo, un git push. Dado que los cambios no se permiten en una infraestructura inmutable, puede estar seguro sobre el estado del sistema desplegado. Las infraestructuras inmutables son inherentemente más coherentes, fiables y predecibles, y simplifican muchos de los aspectos del desarrollo de software y las operaciones.
Use un despliegue de valores controlados o azul-verde al desplegar aplicaciones en infraestructuras inmutables.
[https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) es la práctica de dirigir a una pequeña cantidad de sus clientes a la nueva versión, que normalmente se ejecuta en una instancia de servicio único (la de valor controlado). A continuación, puede analizar en profundidad los errores o los cambios en el comportamiento que puedan generarse. Puede eliminar el tráfico del valor controlado si encuentra problemas críticos y enviar a los usuarios de vuelta a la versión anterior. Si el despliegue se completa correctamente, puede seguir desplegando a la velocidad que desee, mientras supervisa los cambios en busca de errores, hasta completar el despliegue. AWS CodeDeploy puede configurarse con unos ajustes de despliegue que permitan un despliegue de valores controlados.
[https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) es similar al despliegue de valores controlados, excepto que una flota completa de la aplicación se despliega en paralelo. Alterne sus implementaciones en las dos pilas (azul y verde). Una vez más, puede enviar tráfico a la nueva versión y volver a la versión anterior si observa problemas con el despliegue. Normalmente, todo el tráfico se conmuta de una vez. Sin embargo, también puede usar fracciones de tráfico para cada versión para acelerar la adopción de la nueva versión utilizando las capacidades de enrutamiento ponderado por DNS de Amazon Route 53. AWS CodeDeploy y AWS Elastic Beanstalk se pueden configurar con unos ajustes de despliegue que permitan un despliegue verde-azul.
![\[Diagrama que muestra un despliegue azul-verde con AWS Elastic Beanstalk y Amazon Route 53\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png)
Beneficios de la infraestructura inmutable:
+ **Reducción de las alteraciones de configuración:** al sustituir con frecuencia los servidores desde una configuración básica conocida y con control de versiones, la infraestructura se **restablece** a un estado conocido, evitando así las alteraciones de configuración.
+ **Despliegues simplificados**: los despliegues se simplifican porque no tienen que ser compatibles con las mejoras. Las mejoras son simplemente nuevos despliegues.
+ **Despliegues atómicos fiables:** o los despliegues son completamente correctos o no se cambia nada. Esto aporta un mayor grado de confianza en el proceso de despliegue.
+ **Despliegues más seguros con procesos de recuperación y restauración rápidos:** Los despliegues son más seguros porque la versión activa anterior no se cambia. Puede restaurarla si se detecta algún error.
+ **Entornos de prueba y depuración coherentes:** dado que todos los servidores utilizan la misma imagen, no se presentan diferencias entre entornos. Una compilación se implementa en varios entornos. También evita la inconsistencia entre entornos y simplifica las pruebas y la depuración.
+ **Mayor escalabilidad:** dado que los servidores emplean una imagen de base y son coherentes y repetibles, el escalado automático resulta trivial.
+ **Cadena de herramientas simplificada**: la cadena de herramientas se simplifica, ya que puede librarse de las herramientas de administración de la configuración mediante la gestión de mejoras en el software de producción. No se instalan herramientas ni agentes adicionales en los servidores. Los cambios se llevan a cabo en la imagen de base, se prueban y se despliegan.
+ **Mayor seguridad:** al denegar todos los cambios en los servidores, puede desactivar el SSH en las instancias y eliminar las claves. Esto reduce el vector de ataque y mejora la postura de seguridad de su organización.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Haga despliegues mediante infraestructura inmutable. La infraestructura inmutable es un modelo en el que no se producen actualizaciones, no se aplican parches de seguridad ni se llevan a cabo cambios de configuración *in situ* en los sistemas de producción. Si es necesario realizar algún cambio, se crea una nueva versión de la arquitectura y se implementa en producción.
+ [Información general sobre una implementación azul/verde](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Implementar aplicaciones sin servidor gradualmente](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [Infraestructura inmutable: fiabilidad, coherencia y confianza gracias a la inmutabilidad](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
## Recursos
**Documentos relacionados:**
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
+ [Implementar aplicaciones sin servidor gradualmente](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [Infraestructura inmutable: fiabilidad, coherencia y confianza gracias a la inmutabilidad](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [Información general sobre una implementación azul/verde](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [La Amazon Builders' Library: Garantizar la seguridad de las reversiones durante las implementaciones](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
# REL08-BP05 Desplegar cambios con automatización
Las implementaciones y la aplicación de parches se automatizan para eliminar su impacto negativo.
Los cambios en los sistemas de producción son una de las mayores áreas de riesgo para muchas organizaciones. Consideramos que los despliegues son un problema de primera clase que se debe resolver junto con los problemas comerciales que nuestro software aborda. Hoy en día, significa el uso de la automatización siempre que sea práctico en las operaciones, incluidas las pruebas y el despliegue de cambios, la adición o eliminación de capacidad y la migración de datos. AWS CodePipeline le permite administrar los pasos necesarios para lanzar su carga de trabajo. Esto incluye un estado de despliegue utilizando AWS CodeDeploy para automatizar el despliegue del código de la aplicación en instancias de Amazon EC2, instancias locales, funciones de Lambda sin servidor o servicios de Amazon ECS.
**Recomendación**
Aunque la sabiduría convencional sugiere que mantenga a los humanos informados sobre los procedimientos operativos más difíciles, le sugerimos que automatice los procedimientos más difíciles por esa misma razón.
**Patrones de uso no recomendados comunes:**
+ Realizar los cambios manualmente
+ Omitir los pasos de la automatización a través de flujos de trabajo de emergencia
+ No seguir los planes
**Beneficios de establecer esta práctica recomendada:** El uso de la automatización para implementar todos los cambios elimina la posibilidad de que se introduzcan errores humanos y proporciona la capacidad de probar los cambios antes de modificarlos en producción para garantizar que se cumplan los planes.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Automatice su proceso de despliegue. Las canalizaciones de implementación le permiten invocar pruebas automatizadas, detectar anomalías y detener la canalización en un paso determinado antes de la implementación en producción o revertir automáticamente un cambio.
+ [La Amazon Builders' Library: Garantizar la seguridad de las reversiones durante las implementaciones](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [La Amazon Builders' Library: Agilizar el proceso con la entrega continua](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ Use AWS CodePipeline o un producto de terceros de confianza para definir y ejecutar los procesos.
+ Configure la canalización para que se inicie cuando se confirme un cambio en su repositorio de código.
+ [¿Qué es AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ Use Amazon Simple Notification Service (Amazon SNS) y Amazon Simple Email Service (Amazon SES) para enviar notificaciones sobre problemas en la canalización o integrar una herramienta de chat de equipo como Amazon Chime.
+ [¿Qué es Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [¿Qué es Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [¿Qué es Amazon Chime?](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html)
+ [Automatice los mensajes de chat con webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
## Recursos
**Documentos relacionados:**
+ [Socio de APN: socios que pueden ayudarle a crear soluciones de implementación automatizadas](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: productos que pueden usarse para automatizar sus despliegues](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Automatice los mensajes de chat con webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
+ [La Amazon Builders' Library: Garantizar la seguridad de las reversiones durante las implementaciones](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [La Amazon Builders' Library: Agilizar el proceso con la entrega continua](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ [¿Qué es AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ [¿Qué es CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [¿Qué es Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [¿Qué es Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
**Vídeos relacionados:**
+ [AWS Summit 2019: entrega e integración continuas en AWS](https://youtu.be/tQcF6SqWCoY)
# 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)