Confiabilidade e continuidade de negócios
Mantenha as cargas de trabalho no ar quando a demanda dispara ou um componente falha: balanceamento de carga e health checks, Auto Scaling, cache, escalabilidade de bancos de dados, tolerância a falhas Multi-AZ, backups automatizados e as quatro estratégias de recuperação de desastres, do backup e restore ao ativo/ativo.
Uma instância morre às 02:00, ou um lançamento triplica seu tráfego em dez minutos. Se alguém fora do time de operações vai perceber isso depende de decisões tomadas muito antes do incidente: em quantas Availability Zones a carga de trabalho está distribuída, se um health check tira o target com problema da rotação, se a capacidade cresce sem intervenção humana e em quanto tempo você restaura os dados depois que alguém apagou a tabela errada.
Este domínio vale 22% do SOA-C03 e se apoia direto no primeiro. Uma política de escalabilidade é um alarme do CloudWatch com uma ação anexada, e uma decisão de failover é um health check lendo uma métrica. Aqui você transforma essa telemetria em cargas de trabalho que absorvem picos e sobrevivem a falhas.
O que este domínio cobre
- Elastic Load Balancing com ALB, NLB e Gateway Load Balancer, health checks de target groups e diagnóstico de targets presos em unhealthy
- Health checks do Route 53, failover de DNS e zonal shift com o Application Recovery Controller
- Grupos de EC2 Auto Scaling, os tipos de política (target tracking, step, agendada e preditiva), lifecycle hooks e instance refresh
- Escalabilidade de contêineres e serverless: auto scaling de serviços ECS, EKS e concorrência do Lambda
- Cache com CloudFront e ElastiCache, e escalabilidade relacional com read replicas e Aurora Serverless v2
- Modos de capacidade do DynamoDB, auto scaling de tabelas e DAX
- Tolerância a falhas Multi-AZ, AWS Backup e snapshots, restauração point-in-time, e versionamento e replicação no S3
- As quatro estratégias de recuperação de desastres e as metas de RTO e RPO que decidem entre elas
Por que isso importa
As questões deste domínio quase nunca pedem a definição de Multi-AZ. Elas entregam uma restrição (um RPO de 5 minutos, um orçamento que não comporta uma segunda frota ligada, uma aplicação presa à sessão que quebra quando instâncias são encerradas) e perguntam qual mecanismo atende. Responder exige saber quanto cada opção custa em dinheiro, em tempo de recuperação e em trabalho operacional, não só o que ela faz.
Esse mesmo raciocínio aparece em todo plantão. Se você distingue um health check que falhou de uma política de escala que falhou, e uma restauração que cumpre o RPO de outra que perde uma hora de escritas sem avisar, você gasta o incidente resolvendo o problema em vez de descobrindo o desenho da arquitetura.