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 Standard (1 primário + 1 standby)
AZ-a AZ-b
┌─────┐ sync ┌─────┐
│ P1 │◀────────▶│ S1 │ S1 NÃO aceita reads
└──┬──┘ └─────┘
│ endpoint
App (1 reader possível só na primary)
Multi-AZ Cluster (1 writer + 2 readers)
AZ-a AZ-b AZ-c
┌─────┐ ┌─────┐ ┌─────┐
│ W │──│ R1 │──│ R2 │ R1 e R2 aceitam reads
└─────┘ └─────┘ └─────┘
│ │ │
└──writer-endpoint──┐
reader-endpointAurora — 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) |
# 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)
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 — 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?
Quiz rápido
3 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito