Alta disponibilidade

Pontos-chave

• Todas as camadas: load balancer, grupo do Auto Scaling e banco precisam cobrir várias AZs. Um único componente em uma AZ deixa a pilha inteira dependente dela.
• Exigência do ALB: um Application Load Balancer precisa de pelo menos 2 Availability Zones habilitadas.
• Estabilidade estática: provisione capacidade suficiente nas AZs restantes para aguentar a carga sem depender de escalar durante a falha.
• Zonal shift: o Amazon Application Recovery Controller (ARC) tira o tráfego do load balancer de uma AZ com problema em uma única ação.
• Multi-AZ vs multi-Região: Multi-AZ cobre a perda de um data center ou de uma AZ. Perder uma Região inteira é recuperação de desastres e exige uma segunda Região.

Pontos-chave

• Health checks: configurados por target group. Destinos com problema deixam de receber tráfego e voltam a receber quando ficam saudáveis.
• Cross-zone: sempre ativo no nível do load balancer no ALB (pode ser desligado por target group), desligado por padrão no NLB e no GWLB.
• Integração com Auto Scaling: instâncias criadas pelo grupo entram no target group e saem ao serem encerradas. Ative os health checks do ELB no grupo para que ele troque as instâncias que o load balancer marca como não saudáveis.
• Interno vs voltado à internet: um load balancer público para a camada web e um interno para a camada de aplicação formam um design em camadas.

Pontos-chave

• Target tracking: a política recomendada. Mantém uma métrica como CPU média ou requisições por destino em um valor alvo, como um termostato.
• Step e simple: o step ajusta em quantidades diferentes conforme o tamanho da violação do alarme. O simple aplica um único ajuste e espera um cooldown.
• Agendado e preditivo: o agendado muda a capacidade em horários conhecidos. O preditivo analisa até 14 dias de histórico (no mínimo 24 horas) para prever as próximas 48 horas e escala antes dos picos cíclicos.
• Warm pools: instâncias pré-inicializadas mantidas Stopped, Hibernated ou Running para reduzir a latência de scale-out de aplicações que demoram a subir.
• Lifecycle hooks: seguram a instância em estado de espera (1 hora por padrão) para prepará-la antes de entrar em serviço ou copiar logs antes de encerrar.
• Instance refresh: troca as instâncias de forma gradual depois de um novo launch template ou AMI.

Pontos-chave

• Multi-AZ DB instance: um standby síncrono em outra AZ que não atende leituras. O failover aponta o endpoint DNS para o standby, normalmente em 60 a 120 segundos.
• Multi-AZ DB cluster: um writer e 2 standbys legíveis em 3 AZs com replicação semissíncrona, para RDS for MySQL e PostgreSQL. O failover costuma levar menos de 35 segundos.
• Réplicas de leitura: assíncronas, até 15 por origem, na mesma Região ou em outra. Servem para escalar leituras, relatórios e DR entre Regiões por promoção. O RDS não as escala automaticamente.
• Reconexão: a aplicação precisa reconectar depois do failover e não deve guardar DNS em cache por mais de 60 segundos.

Pontos-chave

• Storage: cada escrita é replicada de forma síncrona para 6 nós de armazenamento entre AZs, seja qual for o número de instâncias. O volume cresce sozinho.
• Aurora Replicas: até 15 leitoras com atraso normalmente bem abaixo de 100 milissegundos. O reader endpoint distribui as conexões de leitura.
• Failover: uma réplica é promovida, normalmente em menos de 60 segundos e muitas vezes em menos de 30. Sem réplicas o writer é recriado, normalmente em menos de 10 minutos.
• Promotion tiers: a prioridade de 0 (maior) a 15 decide qual réplica vira writer. No empate vence a maior réplica.
• Cluster endpoint: sempre aponta para o writer atual, então a string de conexão sobrevive ao failover.

Pontos-chave

• Pool de conexões: reaproveita conexões com o banco, então milhares de invocações Lambda ou threads não esgotam o banco. O excesso entra em fila ou sofre throttling em vez de falhar.
• Failover: mantém as conexões dos clientes abertas e roteia para a nova instância, ignorando caches de DNS e reduzindo o tempo de failover em até 66% no Aurora Multi-AZ.
• Segurança: pode exigir autenticação IAM dos clientes e lê as credenciais do banco no AWS Secrets Manager.
• Sem mudar código: a maioria das aplicações só troca o endpoint. O proxy fica na mesma VPC do banco e nunca é acessível publicamente.

Pontos-chave

• Tipos de health check: um endpoint (IP ou nome de domínio), outros health checks (calculado) ou um alarme do CloudWatch.
• Ativo-passivo: a política failover responde com o registro primário enquanto ele está saudável e com o secundário quando não está, por exemplo um site estático no S3 como página de manutenção.
• Ativo-ativo: qualquer outra política (weighted, latency, geolocation) com health checks devolve só registros saudáveis.
• Registros alias: para destinos da AWS como um ALB, ative Evaluate Target Health em vez de criar um health check separado.
• Recursos privados: as verificações de endpoint partem da internet, então monitore recursos privados com um health check sobre um alarme do CloudWatch.

Pontos-chave

• Service quotas: muitas cotas são por conta por Região e ajustáveis no Service Quotas. Aumente antes que um lançamento ou um failover precise da capacidade.
• Throttling: repita com exponential backoff e jitter, limite o número de tentativas e repita só operações idempotentes.
• Infraestrutura imutável: nunca altere produção no lugar. Suba novos recursos (nova AMI, novo launch template) e mude o tráfego com canary ou blue/green, mantendo a versão anterior para rollback.
• AWS X-Ray: rastreia requisições entre serviços e desenha um trace map que mostra gargalos, picos de latência e erros.
• Aplicações legadas que não podem mudar: coloque-as atrás de um ALB com um grupo do Auto Scaling entre AZs, leve o banco para RDS Multi-AZ com RDS Proxy e proteja back ends frágeis com SQS.