Amazon DVA-C02: Bancos de Dados e Cache (RDS, Aurora, ElastiCache, Timestream, Proxy) — Guia de estudos
Faz parte do AWS Developer Associate DVA-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.
RDS e Aurora: design, escalabilidade e criptografia
O design de bancos de dados relacionais no RDS ou Aurora começa com a análise dos trade-offs da carga de trabalho entre o RDS provisionado de nó único e o armazenamento distribuído do Aurora. Escolha o Aurora quando precisar de alta escalabilidade de leitura e failover rápido: as réplicas do Aurora compartilham o volume do cluster, então a promoção é rápida, enquanto as réplicas de leitura (read replicas) do RDS MySQL/Postgres usam replicação assíncrona baseada em binlog e podem apresentar atraso (lag). Para escalar leituras, adicione réplicas de leitura e direcione o tráfego de leitura da aplicação para elas; use os endpoints de leitor (reader endpoints) no Aurora para balancear a carga automaticamente entre as réplicas. Para escritas, a escala vertical (classe de instância) e um design cuidadoso de esquema/índices são importantes. Sempre habilite a criptografia em repouso (at rest) com uma CMK do KMS no momento da criação — habilitar a criptografia posteriormente exige um processo de snapshot/restauração para uma nova instância criptografada; essa é uma armadilha comum. Para proteção em trânsito, imponha conexões TLS/SSL (o RDS fornece pacotes de CA). Para credenciais, prefira o AWS Secrets Manager com rotação automática usando o template Lambda de rotação integrado do RDS; busque os segredos programaticamente com SecretsManager.getSecretValue() nos SDKs. Considere a autenticação de banco de dados do IAM para remover senhas estáticas: gere um token via RDS.Signer (SDK) ou rds.generate-db-auth-token e, em seguida, conecte-se com um token de curta duração. Instrumente usando o Performance Insights, Enhanced Monitoring e CloudWatch; use logs de consultas lentas (slow query logs) e EXPLAIN para identificar gargalos (hotspots).
Pooling de conexões, RDS Proxy e padrões serverless
Funções serverless e aplicações com uso intensivo de conexões comumente esgotam os limites de conexão do banco de dados. O padrão mais direto em Node.js é colocar um pool do mysql2/promise no escopo global do Lambda e reutilizá-lo entre as invocações, mas isso não resolve a escalabilidade para concorrência massiva. O RDS Proxy é a resposta gerenciada: crie o proxy com create_db_proxy, associe-o a segredos do Secrets Manager e às instâncias RDS/Aurora de destino, e use o endpoint do proxy a partir da sua aplicação. O RDS Proxy gerencia a multiplexação de conexões, a integração com a autenticação IAM e o failover. Para o Aurora Serverless ou quando você prefere chamadas no estilo HTTP, use a RDS Data API: rdsdataservice.executeStatement({resourceArn, secretArn, sql, database}) permite que Lambdas executem SQL sem conexões TCP persistentes. Um ponto de atenção comum é misturar a Data API com clusters provisionados — a Data API é destinada a clusters serverless e possui semânticas de latência e transação diferentes. Esteja ciente também de que o RDS Proxy introduz um timeout do pool de conexões e max_connections; ajuste o timeout de cliente ocioso (idle client timeout) e o empréstimo de conexões (connection borrowing) para picos de execução do Lambda. Use SecretsManager.getSecretValue() para credenciais e rotacione-as com rotateSecret ou habilite a rotação automática no console/SDK.
Estratégias de caching: ElastiCache, DAX e design de cache
As escolhas de caching dependem do data store e dos padrões de acesso. Para o DynamoDB, o DAX oferece latência de leitura de microssegundos e integração transparente com o SDK através do AmazonDaxClient, que encapsula o DynamoDB.DocumentClient; é ideal para cargas de trabalho com uso intensivo de leitura e consistência eventual. Para caching relacional ou de chave-valor arbitrário, use o ElastiCache for Redis para estruturas de dados avançadas, persistência (snapshots AOF/RDB), replicação e sharding no modo cluster, ou o Memcached para caching simples e horizontalmente escalável. Implemente o padrão cache-aside para leituras e write-through/write-behind somente quando for aceitável em termos de consistência e complexidade. O design das chaves é crítico: prefixe as chaves por aplicação e versão, use TTLs sensatos e evite cardinalidade ilimitada. Lide com cache stampedes usando padrões de lock-and-refresh (SETNX ou Redlock) ou atualização probabilística antecipada do TTL. Configure o Redis com multi-AZ e failover automático; crie grupos de replicação com failover automático e snapshots via CreateReplicationGroup. Armadilhas comuns incluem caches desatualizados após escritas, não invalidar o cache em mudanças de esquema e esperar consistência absoluta. Monitore a taxa de acertos do cache (cache hit ratio) e as métricas de remoção (eviction) no CloudWatch e escale os tipos de nó ou os shards do cluster quando a memória ou a CPU se tornarem um gargalo.
Séries temporais com Timestream e padrões de réplica de leitura
O Amazon Timestream foi projetado especificamente para séries temporais: faça a ingestão usando a API WriteRecords do SDK com chamadas em lote WriteRecords e consulte com
undefined
. Projete seu esquema de registro com dimensões de baixa cardinalidade e use registros de múltiplas medições para reduzir a amplificação de escrita. Configure regras de retenção em memória e magnética por tabela para manter dados recentes “quentes” (hot) e armazenar dados mais antigos a baixo custo; ajustar a retenção é crucial porque o tamanho da retenção na camada de memória afeta o custo e o desempenho das consultas. Para análises, use consultas específicas para séries temporais (time_bin ou bin) e aplique filtros (push down) nas dimensões para minimizar os dados escaneados. Ao integrar séries temporais com armazenamentos relacionais, descarregue dados históricos imutáveis para o Timestream e sirva metadados “quentes” (hot) a partir do RDS/Aurora com ElastiCache. Para escalabilidade de leitura relacional, adicione réplicas de leitura e roteie o tráfego somente de leitura; para o Aurora, use endpoints de leitor e examine o atraso da réplica (CloudWatch ReplicaLag) antes de rotear leituras críticas. Uma pegadinha comum para desenvolvedores é a alta cardinalidade no Timestream ou chaves de cache produzidas por requisição, o que infla o
← Armazenamento · Todos os domínios · Mensageria →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →