Bancos: Multi-AZ, Read Replicas e DynamoDB
- ⬜🎓 SAA-C03: Da Teoria à Arquitetura Real(AWS Solutions Architect Associate)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Bancos são o tópico mais denso e o segundo mais cobrado no SAA-C03 (depois de networking). O exame cobra a distinção clara entre disponibilidade (Multi-AZ), escalabilidade de leitura (Read Replicas), performance extrema (Aurora, DAX), DR cross-region (Global Database, Global Tables) e modelagem NoSQL (LSI vs GSI). Cada um resolve um problema diferente.
RDS — bancos relacionais gerenciados
RDS suporta MySQL, PostgreSQL, MariaDB, Oracle, SQL Server. AWS gerencia patching, backup, failover; você controla schema e queries. Não confunda RDS com Aurora — Aurora é um engine proprietário da AWS compatível com MySQL e Postgres, com storage layer separada e reescrita.
- → INSERT / UPDATE
- → SELECT
- → replicação SÍNCRONA
- → replicação assíncrona
- → replicação assíncrona
- Compute
- Banco de dados
- Rede e entrega
Uma frase que resolve a maioria: SÍNCRONO e sem servir tráfego é disponibilidade; ASSÍNCRONO e servindo leitura é desempenho. Multi-AZ é o primeiro, read replica é o segundo.
- Multi-AZ é disponibilidade, não desempenho. O standby é síncrono e NÃO serve tráfego nenhum — nem leitura. Ele existe para o failover automático, que a AWS executa trocando o registro DNS do endpoint de escrita. Quem responde "Multi-AZ para escalar leitura" erra a questão.
- Read replica é desempenho, não disponibilidade. Assíncrona, serve leitura, e pode ter lag. Não há failover automático para réplica: promover é ação manual (ou automatizada por você). É o inverso exato do Multi-AZ, e o exame testa esse par mais que qualquer outra coisa em RDS.
- Réplica em outra região resolve dois problemas. Latência para usuário regional e DR. Como a replicação é assíncrona e cruza região, o RPO não é zero — a questão que exige "zero perda de dado" não aceita esta resposta.
- A aplicação precisa usar dois endpoints. Escrita no endpoint da instância primária, leitura no endpoint de leitura. Aplicação que manda tudo para o endpoint de escrita não ganha nada com réplica — o erro está no código, não na infraestrutura.
- E se a questão pedir os dois?. Multi-AZ E read replica convivem: alta disponibilidade com failover automático mais escala de leitura. Quando o enunciado pede "resiliente a falha de AZ e aguentar picos de leitura", a resposta é a combinação, não a escolha.
| Feature | Multi-AZ | Read Replica |
|---|---|---|
| Objetivo | Alta disponibilidade | Escalar leituras |
| Sincronização | Síncrona | Assíncrona (lag em ms–s) |
| Standby aceita reads? | Não (exceto Multi-AZ cluster, 2 readers) | Sim, é endpoint separado |
| Failover | Automático, <60s típico | Manual: promover a standalone |
| Cross-region? | Não (intra-region) | Sim (MySQL/Postgres/MariaDB) |
| Custo | 2× (standby cobrado) | 1× por réplica |
| Até | 1 standby | Até 15 réplicas por primário |
Multi-AZ Cluster (lançado 2022): variante para MySQL e Postgres com 2 readers secundários que aceitam tráfego de leitura via cluster endpoint. Cobre HA e um pouco de escalabilidade de leitura ao mesmo tempo. Mas ainda assim, para 10 réplicas, use Read Replicas.
Aurora — o banco AWS reinventado
Aurora separa compute (nodes MySQL/Postgres compatíveis) de storage (cluster volume replicado 6× em 3 AZs, storage auto-expanding até 128TB). Até 15 read replicas, failover < 30s, writer endpoint + reader endpoint. 3× a performance de MySQL, 5× de Postgres (segundo AWS).
📋 SaaS multi-tenant global, usuários em 4 continentes, precisa consistência <1s em reads globais
Storage-layer replication cross-region com RPO <1s. Leitores regionais servem read traffic localmente. Promoção em <1min se primário cair.
Alt: DynamoDB Global Tables — se o modelo permite NoSQL; multi-active write.
DynamoDB — NoSQL serverless key-value e document
DynamoDB é o NoSQL da AWS: schema-less, partitioned by hash, SLA de latência single-digit-ms em qualquer escala, multi-AZ sempre, sem admin de instâncias. Paga por consumo (RCU/WCU) ou on-demand.
| Modo de capacity | Cobrança | Caso |
|---|---|---|
| On-Demand | Por request ($/milhão) | Tráfego imprevisível, novos apps, spikes |
| Provisioned | RCU/WCU provisionadas | Carga previsível, custo menor em escala |
| Auto Scaling | Provisioned com ajuste automático | Intermediário entre os dois |
| Índice | LSI | GSI |
|---|---|---|
| Partition Key | Mesma da tabela base | Qualquer atributo |
| Sort Key | Diferente | Qualquer atributo (opcional) |
| Criação | Só na criação da tabela | A qualquer momento |
| Capacity | Compartilhada com tabela base | Própria (RCU/WCU separadas) |
| Consistência | Forte suportada | Apenas eventual (nunca strongly consistent) |
| Limite | 5 LSIs por tabela | 20 GSIs por tabela (padrão) |
Pegadinha clássica do exame: “preciso consultar por outro atributo que não é a PK da tabela” → GSI. “preciso consultar com mesma PK mas outra sort key” → LSI. Se o enunciado diz “strongly consistent reads” em índice, LSI é a única opção.
# Criar tabela on-demand com PK composta
aws dynamodb create-table \
--table-name Orders \
--attribute-definitions \
AttributeName=UserId,AttributeType=S \
AttributeName=OrderId,AttributeType=S \
--key-schema \
AttributeName=UserId,KeyType=HASH \
AttributeName=OrderId,KeyType=RANGE \
--billing-mode PAY_PER_REQUEST
# Query por PK com condição na SK
aws dynamodb query --table-name Orders \
--key-condition-expression "UserId = :u AND begins_with(OrderId, :p)" \
--expression-attribute-values '{":u":{"S":"u123"},":p":{"S":"2026"}}'Cálculo de RCU/WCU (nível SAA)
Exemplo: aplicação faz 300 reads eventualmente consistentes de 8KB/s + 100 writes de 2KB/s. Reads: 300 × 2KB (arredondar 8KB = 2×4KB) × 0,5 (eventual) = 300 RCU. Writes: 100 × 2 (2KB arredonda para 2×1KB) = 200 WCU.
A aplicação tem picos de leitura que saturam o banco, e o time também precisa que o banco sobreviva à queda de uma AZ. Qual configuração atende às DUAS exigências?
Estratégias de DR para bancos
| Estratégia | RPO | RTO | Custo |
|---|---|---|---|
| Backup & Restore (snapshot cross-region) | minutos–horas | horas | $ |
| Pilot Light (standby mínimo replicando) | segundos–minutos | 10–30 min | $$ |
| Warm Standby (stack reduzida ativa) | segundos | minutos | $$$ |
| Multi-Site Active-Active | ~0 | segundos | $$$$ |
📋 E-commerce grande: checkout não pode cair, tolera 5s de stale reads em catálogo
Checkout precisa de consistência e failover rápido → Aurora Global. Catálogo tolera eventual consistency e pode escalar multi-master → DynamoDB Global.
Alt: Tudo em Aurora Global — simpler mas perde multi-active write para catálogo.
Q&A de exame
❓ RDS Read Replica promovida — o que acontece com o primário original?
❓ Por que escolher Aurora Serverless v2 em vez de instances provisioned?
❓ DynamoDB retornou ProvisionedThroughputExceededException — causa e fix?
❓ Qual a diferença entre DAX e ElastiCache na frente do DynamoDB?
Perguntas frequentes
❓ Multi-zona ou réplica de leitura?
❓ Quando o DynamoDB é a escolha certa?
❓ O que é partição quente e como evitar?
Fixando
Um relatório noturno lê da read replica e às vezes mostra pedidos que não existem mais. Qual é a explicação?
Uma tabela DynamoDB tem tráfego imprevisível: fica quase parada e ocasionalmente recebe rajadas de dez vezes o volume normal. Qual modo de capacidade?
Armadilhas recorrentes: (1) Multi-AZ standby NÃO serve reads; (2) LSI exige criação no create-table — não dá para adicionar depois; (3) Aurora Global RPO “near-zero”, não “zero”; (4) DAX é para DynamoDB apenas, não Aurora; (5) PITR em DynamoDB não é backup — pode ser deletado com a tabela se não houver backup separado.
Take-aways: Multi-AZ = HA, Read Replicas = escalar leituras, Aurora = performance + cluster volume, Aurora Global = DR cross-region relacional, DynamoDB = NoSQL serverless com GSI/LSI/DAX/Global Tables. Escolha pelo workload: OLTP relacional transacional → RDS/Aurora; key-value altíssima escala → DynamoDB.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…