Databases: RDS, Aurora, DynamoDB e Redshift
- ⬜💾 Storage: S3, EBS, EFS e Glacier(AWS Cloud Practitioner)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
A AWS oferece um banco para cada modelo de dados: relacional, key-value, documento, grafo, time-series, in-memory, ledger, data warehouse. Escolher errado gera problemas de performance ou custo proibitivo. O CLF-C02 cobra os fundamentos de cada família — não exige dominar queries, mas sim saber quando usar cada um.
Onde isso entra no exame
Databases formam cerca de 20% do domínio 3. As questões são de cenário: "qual banco para esta workload?". A chave é reconhecer o padrão de acesso descrito (transacional? analítico? key-value? grafo?) e mapear ao serviço correto.
O catálogo AWS de bancos (purpose-built)
| Modelo | Serviço AWS | Uso típico |
|---|---|---|
| Relacional | RDS, Aurora | ERPs, CRMs, apps transacionais clássicas |
| Key-value / Document | DynamoDB | Carrinhos, sessões, leaderboards, IoT |
| Document (MongoDB) | DocumentDB | Apps que já usam MongoDB API |
| In-memory | ElastiCache (Redis/Memcached) | Cache, session store, real-time leaderboards |
| Graph | Neptune | Redes sociais, fraud detection, knowledge graphs |
| Time-series | Timestream | IoT, métricas, dados temporais |
| Ledger (imutável) | QLDB | Compliance, auditoria, supply chain |
| Wide-column | Keyspaces | Apps que usam Apache Cassandra |
| Data warehouse | Redshift | BI, analytics em petabytes |
| Search | OpenSearch | Busca full-text, logs |
- → transação
- → sessão, catálogo
- → consulta repetida
- → quem conhece quem
- → mesma API, mais desempenho
- → ETL para análise
- Banco de dados
- Analytics
- Compute
A AWS chama isso de purpose-built: em vez de forçar tudo num banco relacional, escolhe-se pela forma do dado e pelo padrão de acesso. A questão do CLF descreve o padrão — o banco segue disso.
- Relacional quando há junção e transação. Esquema fixo, ACID, SQL. RDS gerencia o motor que você já usa; Aurora é a versão da AWS, compatível com MySQL e PostgreSQL, com desempenho maior e seis cópias do dado em três AZs.
- DynamoDB quando a escala é horizontal. Sem servidor, latência de milissegundo em qualquer volume, e cobrança por uso. O preço é abandonar junção e consulta livre: o acesso tem que ser pela chave. "Milhões de requisições, esquema simples" é DynamoDB.
- Cache não é banco. ElastiCache guarda o que é caro de recalcular ou buscar. Ele não é a fonte da verdade — se o cache cai, o dado continua no banco. Confundir os dois é erro de arquitetura, não de configuração.
- Neptune quando a pergunta é sobre relação. "Quem são os amigos dos amigos", "qual caminho liga A a B", detecção de fraude por rede. Em SQL isso vira junção recursiva caríssima; em banco de grafo é a operação natural.
- Redshift é para analisar, não para operar. Colunar e otimizado para varrer milhões de linhas e agregar. Não substitui o banco transacional: o padrão é o operacional alimentar o Redshift, e o BI consultar lá.
Amazon RDS (Relational Database Service)
Bancos relacionais gerenciados. A AWS cuida do SO, patches, backups, réplicas. Engines suportados:
- • MySQL, PostgreSQL, MariaDB — open source
- • Oracle, SQL Server — proprietários (BYOL ou license-included)
- • Aurora (MySQL/PostgreSQL-compatible) — proprietário AWS
- • Db2 — desde 2023
Features essenciais:
- • — standby síncrono em outra AZ (failover <2 min)
- • — até 5 réplicas assíncronas para escalar leitura
- • — retenção 1-35 dias (point-in-time recovery)
- • — mantidos indefinidamente
- • — via KMS
Amazon Aurora — o diferencial
Proprietário AWS, compatível com PostgreSQL e MySQL. Arquitetura de storage distribuído em 6 cópias em 3 AZs. Auto-scale de storage até 128 TB. Failover <30s.
Benefícios vs RDS vanilla:
- • Até 5x throughput de MySQL, 3x de PostgreSQL
- • Até 15 réplicas de leitura (vs 5 no RDS)
- • Backup contínuo incremental para S3
- • — escala automaticamente em ACUs
- • — replicação cross-region <1s
Amazon DynamoDB
NoSQL key-value e document, serverless, escala horizontal ilimitada, latência single-digit ms. Pagamento por capacidade provisionada (leituras/segundo) ou On-Demand (paga por requisição).
Features únicas:
- • — replicação multi-master multi-region
- • — dispara Lambda em mudanças
- • — apaga itens automaticamente após timestamp
- • — cache in-memory com latência em microssegundos
- • — point-in-time recovery últimos 35 dias
Padrão do exame: "Escala horizontal massiva, baixa latência, sem schema rígido" → DynamoDB. "Transações ACID complexas com JOINs" → RDS/Aurora.
Redshift — data warehouse
Data warehouse colunar, MPP (Massively Parallel Processing), até petabytes. Baseado em PostgreSQL modificado. Features:
- • — query SQL em dados no S3 sem carregar
- • — sem gerenciar cluster
- • — escala transparente em picos de BI
- • Integra com QuickSight, Tableau, Power BI
ElastiCache — cache in-memory
| Engine | Uso | Recurso principal |
|---|---|---|
| Redis | Cache + estrutura de dados rica + pub/sub | Persistência, replicação, clustering |
| Memcached | Cache simples, ultra-leve | Multi-threaded, particionamento simples |
ElastiCache é usado como camada de cache na frente de RDS/DynamoDB para reduzir latência e custo.
Um catálogo de produtos precisa de latência de milissegundo com milhões de leituras por minuto, acesso sempre pela chave do produto. Qual banco?
Bancos especializados
| Serviço | Modelo | Quando usar |
|---|---|---|
| Neptune | Graph (Gremlin, SPARQL) | Redes sociais, fraude, recomendação |
| Timestream | Time-series | IoT, métricas, DevOps observability |
| QLDB | Ledger imutável (append-only) | Histórico de transações auditável |
| DocumentDB | MongoDB-compatible | Apps que já usam MongoDB |
| Keyspaces | Cassandra-compatible | Apps Cassandra sem gerenciar cluster |
Database Migration Service (DMS)
Serviço para migrar bancos on-prem ou entre engines. Suporta homogêneo (Oracle → Oracle) e heterogêneo (Oracle → PostgreSQL). Integra com AWS Schema Conversion Tool (SCT) para converter stored procedures.
Cenários de decisão
📋 E-commerce com carrinho de compras, 100k usuários simultâneos
Carrinho é key-value (userId → items). DynamoDB escala horizontal automático, latência ms, sem schema. Para pedidos finais (ACID), considere Aurora ou RDS.
Alt: RDS MySQL — Pode virar gargalo em picos sem arquitetura de cache/read replicas
📋 Sistema bancário transacional (débitos/créditos ACID)
ACID, transações complexas, JOINs, consistência forte. Aurora tem melhor HA (Multi-AZ built-in + storage distribuído).
📋 Dashboard de BI consultando 500 TB de eventos de vendas históricos
Consultas analíticas em volumes petabyte exigem storage colunar + MPP. RDS/Aurora são transacionais, lentos para analytics.
📋 Feed de rede social (amigos de amigos, recomendações)
Grafos naturalmente expressam relacionamentos. Queries 'shortest path', 'common neighbors' são lentas em SQL e rápidas em graph DB.
📋 Cache de resultado de API externa, TTL 5 minutos
Latência <1ms, TTL nativo, estruturas ricas (lists, sets, sorted sets). Ficar à frente de RDS ou DynamoDB.
Exemplos de CLI
# RDS — criar instância PostgreSQL Multi-AZ
aws rds create-db-instance \
--db-instance-identifier meu-pg \
--db-instance-class db.t3.medium \
--engine postgres \
--master-username admin \
--master-user-password <senha> \
--allocated-storage 100 \
--multi-az
# DynamoDB — criar tabela on-demand
aws dynamodb create-table \
--table-name Pedidos \
--attribute-definitions AttributeName=id,AttributeType=S \
--key-schema AttributeName=id,KeyType=HASH \
--billing-mode PAY_PER_REQUEST
# DynamoDB — inserir item
aws dynamodb put-item \
--table-name Pedidos \
--item '{"id":{"S":"001"},"valor":{"N":"199.90"}}'Pegadinha: "RDS é serverless?" — Não por padrão. sim. RDS Multi-AZ é alta disponibilidade, não serverless. Serverless implica: sem provisionar, escala a zero, cobra pelo uso.
Perguntas típicas (Q&A)
❓ Qual a diferença entre Multi-AZ e Read Replica no RDS?
❓ Quando escolher DocumentDB em vez de DynamoDB?
❓ Qual banco para IoT com milhões de medições por segundo ordenadas no tempo?
❓ Qual feature garante recuperação de RDS a qualquer segundo dos últimos 35 dias?
Perguntas frequentes
❓ Relacional, NoSQL ou analítico: como escolher?
❓ Aurora ou RDS: qual escolher para o meu banco?
❓ Para que serve cache em memória se o banco já é rápido?
Fixando
Qual é a principal diferença entre Amazon RDS e Amazon Aurora?
Para que serve o Amazon ElastiCache?
Take-aways: RDS/Aurora = relacional. DynamoDB = NoSQL serverless. Redshift = data warehouse. ElastiCache = cache in-memory. Neptune/Timestream/QLDB = especializados. Aurora tem 6 cópias em 3 AZs. Multi-AZ = HA; Read Replicas = escala de leitura. Aurora Serverless v2 = único RDS-like totalmente serverless. Purpose-built: escolha o banco certo para o padrão de acesso, não o que você conhece.
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…