Bancos: Multi-AZ, Read Replicas e DynamoDB
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.
| 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 —
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.
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 —
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?
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.
Discussão
Carregando…