Cenários de arquiteturas resilientes e altamente disponíveis

Cenário: Uma empresa executa uma aplicação web de duas camadas (ALB → EC2 → RDS) e deseja eliminar qualquer ponto único de falha dentro da AWS Region. Solução: Implante instâncias EC2 em um grupo de Auto Scaling abrangendo pelo menos 2 Availability Zones atrás de um ALB (que é inerentemente Multi-AZ). Habilite o RDS Multi-AZ para replicação síncrona em espera. Configure verificações de integridade no ALB para direcionar automaticamente o tráfego para longe das instâncias não íntegras. Com essa arquitetura, a perda de qualquer AZ provoca failover automático em todas as camadas.

Cenário: A instância RDS de uma aplicação de comércio eletrônico está atingindo os limites de CPU durante os horários de pico devido a consultas analíticas com uso intenso de leitura da equipe de inteligência de negócios. Solução: Crie RDS Read Replicas e direcione as consultas de BI para o endpoint da réplica. Read Replicas usam replicação assíncrona — um pequeno atraso é aceitável para análises. Isso descarrega o tráfego de leitura da instância RDS primária, que fica reservada para operações de gravação e leituras da aplicação. Para cargas de trabalho extremamente intensas em leitura, adicione uma camada de ElastiCache na frente do RDS para dados acessados com frequência.

Cenário: Uma API sem estado é executada no EC2 atrás de um ALB. O uso de CPU sobe para 90% durante o horário comercial e cai para quase zero à noite. A empresa deseja que a frota seja escalada automaticamente. Solução: Configure um grupo de Auto Scaling com uma política de escalabilidade Target Tracking direcionada a uma utilização média de CPU de 60%. O ASG adicionará instâncias automaticamente quando a CPU exceder 60% e removerá instâncias quando cair abaixo do objetivo. Adicione uma ação de escalabilidade agendada para pré-aquecer a capacidade mínima antes do início do horário comercial, evitando atrasos no pico de tráfego da manhã.

Cenário: Uma empresa executa uma aplicação web primária em us-east-1 e deseja fazer failover para uma página estática de manutenção hospedada no S3 em us-west-2 caso a primária fique não íntegra. Solução: Crie uma verificação de integridade do Route 53 monitorando o endpoint do ALB primário. Crie dois registros do Route 53 com uma política de roteamento de failover: o registro primário apontando para o ALB (associado à verificação de integridade) e o registro secundário apontando para o site estático no S3. Se a verificação de integridade falhar, o Route 53 fornecerá automaticamente a resposta DNS do registro secundário.

Cenário: Um backend de processamento de pedidos grava dados em um banco de dados, mas o banco às vezes fica indisponível durante janelas de manutenção, fazendo com que pedidos sejam perdidos. Solução: Coloque uma fila SQS entre o frontend (que aceita os pedidos) e o backend (que os processa). Os pedidos são colocados imediatamente na fila, fornecendo uma confirmação instantânea ao cliente. Os processos em segundo plano retiram pedidos da fila e os processam quando o banco de dados está disponível. Durante a manutenção, os pedidos se acumulam na fila em vez de serem descartados — proporcionando resiliência por meio de desacoplamento assíncrono.

Cenário: Uma empresa precisa de uma solução de recuperação de desastres com RPO de 1 hora e RTO de 4 horas, dentro de um orçamento moderado. Solução: Implemente uma estratégia de DR Pilot Light. Mantenha o banco de dados principal replicado na Region de DR usando uma RDS Cross-Region Read Replica. Os servidores da aplicação não são executados na Region de DR durante a operação normal — apenas o mínimo necessário, o “núcleo” (o banco de dados), é mantido ativo. Em caso de desastre, promova a Read Replica para uma instância independente e inicie os servidores da aplicação a partir de AMIs pré-criadas usando CloudFormation. O RTO é de horas, e não minutos, porque os servidores precisam ser iniciados.

Cenário: Mensagens em uma fila SQS falham repetidamente ao serem processadas devido a um erro na função Lambda consumidora. As mensagens continuam reaparecendo e bloqueando a fila. Solução: Configure uma Dead-Letter Queue (DLQ) na fila principal. Depois que uma mensagem falhar ao ser processada por um número configurável de vezes (maxReceiveCount), o SQS a moverá automaticamente para a DLQ em vez de redistribuí-la indefinidamente. Isso desbloqueia a fila principal para mensagens válidas. Configure um alarme do CloudWatch na métrica ApproximateNumberOfMessagesVisible da DLQ para alertar a equipe de engenharia quando houver acúmulo de mensagens na DLQ.

Cenário: Uma empresa opera nos US e na Europa. Os usuários na Europa enfrentam alta latência de leitura do banco de dados porque o RDS está em us-east-1. Solução: Use o Amazon Aurora Global Database. O cluster primário fica em us-east-1; um cluster secundário somente para leitura é adicionado em eu-west-1. O Aurora replica os dados para a Region secundária com latência típica inferior a 1 segundo, usando replicação no nível do armazenamento. Os usuários europeus leem do cluster secundário em eu-west-1. Em caso de desastre regional, o secundário pode ser promovido a primário em menos de 1 minuto (o melhor RTO entre todas as opções de banco de dados multi-região da AWS).

Cenário: Um serviço de API conteinerizado executado no ECS Fargate precisa ser escalado com base na utilização de CPU e sobreviver a falhas de AZ. Solução: Registre o serviço ECS em um grupo de destino do Application Load Balancer para que o tráfego seja distribuído entre as tarefas em execução. Distribua as tarefas por várias AZs especificando várias sub-redes na configuração do serviço. Configure o ECS Service Auto Scaling com uma política de acompanhamento de objetivo baseada na utilização de CPU do serviço ECS, para aumentar e reduzir automaticamente a quantidade de tarefas. Se uma AZ falhar, o ECS reiniciará as tarefas com falha em AZs íntegras.

Cenário: Uma empresa executa duas instâncias EC2 em AZs diferentes, servindo o mesmo domínio. Ela deseja que o Route 53 pare automaticamente de enviar tráfego para uma instância não íntegra. Solução: Use o Route 53 Weighted Routing com pesos iguais (50/50) e associe uma verificação de integridade do endpoint a cada registro. Quando o Route 53 detectar um endpoint não íntegro, ele removerá esse registro das respostas DNS e enviará 100% do tráfego para o endpoint íntegro. Quando a instância se recuperar e as verificações de integridade voltarem a ser aprovadas, o Route 53 rebalanceará o tráfego automaticamente — sem necessidade de alterações manuais no DNS.

Cenário: Uma aplicação de jogos para dispositivos móveis precisa que os dados dos jogadores possam ser lidos e gravados com baixa latência tanto em us-east-1 quanto em ap-southeast-1. Uma tabela do DynamoDB em uma única região causa alta latência para usuários asiáticos. Solução: Habilite as DynamoDB Global Tables. As Global Tables replicam automaticamente os dados entre as Regions especificadas usando replicação multi-master — qualquer Region pode aceitar gravações. Os usuários asiáticos gravam e leem na réplica em ap-southeast-1 com latência local (aproximadamente 5 ms). As Global Tables tratam a resolução de conflitos usando uma estratégia de “último gravador vence”, baseada em registros de data e hora. O RTO para uma falha regional completa é próximo de zero — o tráfego simplesmente é direcionado para a região sobrevivente.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) desta lição.

Nesta lição, você trabalhou com cenários que abordaram: ASG e RDS Multi-AZ para HA dentro da Region, roteamento de failover do Route 53 para DR entre Regions, SQS DLQ para isolar mensagens com falha sem bloquear filas e Aurora Global Database para escalabilidade de leitura entre Regions e failover com RTO inferior a um minuto. A seguir, abordaremos cenários de arquiteturas de alto desempenho e custo otimizado.