Escenarios de arquitecturas resilientes y de alta disponibilidad

Escenario: Una empresa ejecuta una aplicación web de dos niveles (ALB → EC2 → RDS) y desea eliminar cualquier punto único de fallo dentro de la Región de AWS. Solución: Implemente instancias EC2 en un Auto Scaling Group que abarque al menos 2 zonas de disponibilidad detrás de un ALB (que es inherentemente multi-AZ). Habilite RDS Multi-AZ para la replicación síncrona en espera. Configure comprobaciones de estado en el ALB para redirigir automáticamente el tráfico y evitar las instancias en mal estado. Con esta arquitectura, la pérdida de cualquier AZ provoca una conmutación por error automática en todos los niveles.

Escenario: La instancia de RDS de una aplicación de comercio electrónico alcanza los límites de CPU durante las horas punta debido a consultas de análisis con gran intensidad de lectura del equipo de inteligencia empresarial. Solución: Cree RDS Read Replicas y dirija las consultas de BI al endpoint de la réplica. Read Replicas utiliza replicación asíncrona, por lo que una ligera latencia es aceptable para los análisis. Esto descarga el tráfico de lectura de la instancia principal de RDS, que queda reservada para las operaciones de escritura y las lecturas de la aplicación. Para cargas de trabajo con una intensidad de lectura extrema, añada una capa de ElastiCache delante de RDS para los datos a los que se accede con frecuencia.

Escenario: Una API sin estado se ejecuta en EC2 detrás de un ALB. El uso de CPU alcanza el 90 % durante el horario laboral y desciende casi a cero por la noche. La empresa desea que la flota se escale automáticamente. Solución: Configure un Auto Scaling Group con una política de escalado Target Tracking cuyo objetivo sea una utilización media de CPU del 60 %. ASG añadirá instancias automáticamente cuando la CPU supere el 60 % y las eliminará cuando descienda por debajo del objetivo. Añada una acción de escalado programada para precalentar la capacidad mínima antes de que comience el horario laboral y evitar retrasos durante el aumento de tráfico matutino.

Escenario: Una empresa ejecuta una aplicación web principal en us-east-1 y desea conmutar por error a una página de mantenimiento estática alojada en S3 en us-west-2 si la principal deja de estar saludable. Solución: Cree una comprobación de estado de Route 53 que supervise el endpoint del ALB principal. Cree dos registros de Route 53 con una política de enrutamiento de conmutación por error: un registro principal que apunte al ALB (asociado a la comprobación de estado) y un registro secundario que apunte al sitio estático de S3. Si la comprobación de estado falla, Route 53 proporciona automáticamente la respuesta DNS del registro secundario.

Escenario: Un backend de procesamiento de pedidos escribe en una base de datos, pero esta deja de estar disponible ocasionalmente durante las ventanas de mantenimiento, lo que provoca la pérdida de pedidos. Solución: Coloque una cola de SQS entre el frontend (que acepta los pedidos) y el backend (que los procesa). Los pedidos se colocan inmediatamente en la cola, lo que proporciona al cliente una confirmación instantánea. Los procesos de trabajo en segundo plano extraen los pedidos de la cola y los procesan cuando la base de datos está disponible. Durante el mantenimiento, los pedidos se acumulan en la cola en lugar de descartarse, lo que proporciona resiliencia mediante el desacoplamiento asíncrono.

Escenario: Una empresa necesita una solución de recuperación ante desastres con un RPO de 1 hora y un RTO de 4 horas, con un presupuesto moderado. Solución: Implemente una estrategia de DR Pilot Light. Mantenga la base de datos principal replicada en la Región de DR mediante RDS Cross-Region Read Replica. Los servidores de aplicaciones no se ejecutan en la Región de DR durante el funcionamiento normal; solo se mantiene activo el mínimo «núcleo» (la base de datos). En caso de desastre, convierta la Read Replica en independiente y lance los servidores de aplicaciones a partir de AMI previamente creadas mediante CloudFormation. El RTO es de horas, no de minutos, porque es necesario lanzar los servidores.

Escenario: El procesamiento de los mensajes de una cola de SQS falla repetidamente debido a un error en la Lambda consumidora. Los mensajes reaparecen continuamente y bloquean la cola. Solución: Configure una Dead-Letter Queue (DLQ) en la cola principal. Después de que un mensaje falle un número configurable de veces (maxReceiveCount), SQS lo mueve automáticamente a la DLQ en lugar de volver a entregarlo indefinidamente. Esto desbloquea la cola principal para los mensajes que funcionan correctamente. Configure una alarma de CloudWatch sobre la métrica ApproximateNumberOfMessagesVisible de la DLQ para avisar al equipo de ingeniería cuando se acumulen mensajes en ella.

Escenario: Una empresa opera en Estados Unidos y Europa. Los usuarios de Europa experimentan una latencia de lectura de la base de datos elevada porque RDS se encuentra en us-east-1. Solución: Utilice Amazon Aurora Global Database. El clúster principal se encuentra en us-east-1 y se añade un clúster secundario de solo lectura en eu-west-1. Aurora replica los datos en la Región secundaria con una latencia habitual inferior a 1 segundo mediante replicación a nivel de almacenamiento. Los usuarios europeos leen del clúster secundario de eu-west-1. En caso de desastre regional, el secundario puede promoverse a principal en menos de 1 minuto (el mejor RTO entre las opciones de bases de datos multi-región de AWS).

Escenario: Un servicio de API contenedorizado que se ejecuta en ECS Fargate necesita escalar en función de la utilización de CPU y sobrevivir a fallos de AZ. Solución: Registre el servicio de ECS en un grupo de destino de Application Load Balancer para distribuir el tráfico entre las tareas en ejecución. Distribuya las tareas entre varias AZ especificando varias subredes en la configuración del servicio. Configure ECS Service Auto Scaling con una política de seguimiento de objetivos sobre la utilización de CPU del servicio de ECS para aumentar y reducir automáticamente el número de tareas. Si falla una AZ, ECS reinicia las tareas fallidas en AZ saludables.

Escenario: Una empresa ejecuta dos instancias EC2 en AZ diferentes que sirven el mismo dominio. Desea que Route 53 deje de enviar tráfico automáticamente a una instancia en mal estado. Solución: Utilice Weighted Routing de Route 53 con pesos iguales (50/50) y asocie una comprobación de estado del endpoint a cada registro. Cuando Route 53 detecta que un endpoint está en mal estado, elimina ese registro de las respuestas DNS y envía el 100 % del tráfico al endpoint saludable. Cuando la instancia se recupera y las comprobaciones de estado vuelven a superarse, Route 53 reequilibra automáticamente el tráfico, sin necesidad de cambios manuales en DNS.

Escenario: Una aplicación de juegos para móviles necesita que los datos de los jugadores se puedan leer y escribir con baja latencia tanto desde us-east-1 como desde ap-southeast-1. Una tabla de DynamoDB en una sola Región provoca una latencia elevada para los usuarios asiáticos. Solución: Habilite DynamoDB Global Tables. Global Tables replica automáticamente los datos entre las Regiones especificadas mediante replicación multi-master; cualquier Región puede aceptar escrituras. Los usuarios asiáticos escriben y leen en la réplica de ap-southeast-1 con latencia local (~5 ms). Global Tables gestiona la resolución de conflictos mediante una estrategia de «last-writer-wins» basada en marcas de tiempo. El RTO ante un fallo regional completo es prácticamente cero: el tráfico se dirige simplemente a la Región que sigue operativa.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha trabajado con escenarios que abarcan: ASG Multi-AZ y RDS para HA dentro de una Región, enrutamiento de conmutación por error de Route 53 para DR entre Regiones, SQS DLQ para aislar mensajes fallidos sin bloquear las colas y Aurora Global Database para escalar las lecturas entre Regiones y realizar una conmutación por error con un RTO inferior a un minuto. A continuación, abordaremos escenarios de arquitecturas de alto rendimiento y optimizadas en costes.