Amazon SAA-C03: Bancos de Dados e Caching — Guia de estudos

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Faz parte do AWS SAA-C03 — Guia de estudos completo. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Amazon Aurora: Arquitetura e Endpoints

O Aurora reimplementa a camada de armazenamento sob o MySQL e o PostgreSQL como um volume distribuído, estruturado em log e replicado de seis formas (six-way) que abrange três AZs. Os nós de computação são stateless em relação ao armazenamento, então uma Aurora Replica lê do mesmo volume subjacente que o nó de escrita (writer), em vez de reproduzir um log. O lag de replicação é tipicamente de 10 a 20 ms, em comparação com segundos para réplicas RDS padrão, e um cluster suporta até 15 réplicas que podem ser promovidas para nó de escrita em cerca de 30 segundos.

O Aurora expõe quatro tipos de endpoint:

Endpoints personalizados são importantes quando as réplicas são heterogêneas. Se três de seis réplicas são db.r6g.8xlarge para relatórios analíticos enquanto as outras atendem a leituras OLTP, o endpoint de leitura geral ocasionalmente direcionará os relatórios para nós menores, prejudicando a previsibilidade. Um endpoint personalizado com escopo apenas para as réplicas grandes oferece isolamento de carga de trabalho determinístico:

aws rds create-db-cluster-endpoint \
  --db-cluster-identifier prod-aurora \
  --db-cluster-endpoint-identifier reporting \
  --endpoint-type READER \
  --static-members reporting-node-1 reporting-node-2 reporting-node-3

Note que o TTL do DNS dos endpoints do Aurora é de 5 segundos; manter as strings de conexão em cache por mais tempo anula o comportamento de failover.

O Aurora Auto Scaling adiciona e remove réplicas de leitura (readers) com base em métricas de CPU ou de conexões alvo, que é a solução canônica para cargas de trabalho imprevisíveis, com uso intensivo de leitura e que devem permanecer altamente disponíveis:

TargetTrackingScalingPolicyConfiguration:
  PredefinedMetricSpecification:
    PredefinedMetricType: RDSReaderAverageCPUUtilization
  TargetValue: 60.0
  ScaleInCooldown: 300
  ScaleOutCooldown: 60

Quando as read replicas do RDS MySQL não conseguem manter o lag de replicação abaixo de um segundo nos picos de uso, a solução de baixo código é migrar para o Aurora MySQL — as strings de conexão quase não mudam, e a replicação no nível de armazenamento elimina o lag.

Aurora Serverless v2 e Clonagem

O Aurora Serverless v2 escala a computação verticalmente de forma granular em Aurora Capacity Units (ACUs, 2 GiB de memória cada) em cerca de meio segundo, sem desconectar as sessões. É adequado para cargas de trabalho variáveis com um consumo de memória base conhecido — por exemplo, uma migração de um MySQL on-premises que sempre consome pelo menos 2 GiB. Defina o mínimo em 1 ACU, o máximo em 32 ACUs, e o cluster se ajusta sem administração. O Aurora Provisioned continua sendo preferível quando a carga é estável e previsível, já que o Serverless v2 tem um custo adicional por ACU.

A clonagem do Aurora cria um novo cluster compartilhando as páginas de armazenamento da origem via copy-on-write. Os clones são criados em segundos e não têm custo até que os dados divirjam, tornando-os ideais para ambientes de homologação (staging), migrações arriscadas ou para permitir que analistas sobrecarreguem uma cópia de produção. Uma restauração de snapshot reidrata fisicamente os dados e pode levar horas; a clonagem é a melhor opção quando a velocidade é importante.

Aurora Global Database

O Aurora Global Database estende um cluster para até cinco Regiões secundárias usando uma infraestrutura de replicação dedicada na camada de armazenamento — não o envio de binlogs. O lag de replicação típico é inferior a um segundo, o RPO é inferior a um segundo, e o failover gerenciado promove uma secundária em menos de um minuto.

Duas semânticas críticas: as regiões secundárias são somente leitura (read-only) durante a operação normal, e o Global Database é projetado para DR de baixo RPO e leituras remotas de baixa latência, não para multi-master ativo-ativo. Assumir que um Global Database “lida automaticamente com escritas na região secundária” está errado — as escritas lá exigem um failover gerenciado explícito ou um processo de desanexar e promover (detach-and-promote). Para um requisito declarado de RPO de 5 minutos / RTO de 20 minutos entre regiões com sobrecarga operacional mínima, o Global Database é a solução canônica.

RDS Proxy e Gerenciamento de Conexões

Cargas de trabalho serverless e altamente concorrentes agravam um problema clássico: as tempestades de conexão (connection storms). Uma função Lambda que escala para 3.000 execuções simultâneas abre 3.000 soquetes, estourando o max_connections e causando falhas em cascata — exatamente quando o sistema está sob carga. Pools de conexão dentro da função não ajudam, pois cada ambiente de execução simultânea é isolado.

O RDS Proxy fica entre os clientes e o banco de dados, mantendo um pool aquecido de conexões e multiplexando as sessões dos clientes nelas. Ele resolve dois problemas:

1. Tempestades de conexão. Milhares de sessões de clientes são multiplexadas em um pequeno pool de backend.
2. Tempo de failover. O proxy mantém as conexões do cliente abertas enquanto restabelece o link com o backend, reduzindo o tempo de failover percebido em até 66% e eliminando o restabelecimento de TCP/TLS e a resolução de DNS do lado do cliente.

Ele se integra com o IAM e o Secrets Manager para o gerenciamento de credenciais, removendo segredos codificados no código da aplicação.

DBProxy:
  Type: AWS::RDS::DBProxy
  Properties:
    EngineFamily: POSTGRESQL
    RequireTLS: true
    IdleClientTimeout: 1800
    Auth:
      - AuthScheme: SECRETS
        SecretArn: !Ref DBSecret
        IAMAuth: REQUIRED

As aplicações se conectam ao endpoint do proxy, não ao endpoint do cluster. Qualquer arquitetura Lambda-para-RDS ou com alto fan-out deve usar o RDS Proxy, a menos que haja uma razão específica para não o fazer. Executar seu próprio pooler (PgBouncer, ProxySQL) em uma EC2 é possível, mas adiciona a sobrecarga operacional que o proxy foi criado para eliminar.

DynamoDB: Modos de Capacidade

O DynamoDB é um banco de dados de chave-valor/documento gerenciado com latência de milissegundos de um dígito em qualquer escala, particionado horizontalmente pela chave de hash. Ele oferece dois modos de capacidade:

O modo on-demand é drasticamente mais simples, mas custa aproximadamente 6 a 7 vezes mais por requisição do que a capacidade provisionada bem utilizada. Para um lote noturno de 4 horas a 500 WCU, o modo on-demand tem um custo significativamente maior — a capacidade provisionada com escalonamento agendado (scheduled scaling) ou capacidade reservada é muito mais barata. Por outro lado, usar o modo provisionado para uma carga de trabalho imprevisível de um lançamento público leva a throttling. Para cargas de trabalho constantes com variação moderada, o modo provisionado com auto-scaling do tipo target-tracking em torno de 70% de utilização é significativamente mais barato que o on-demand — frequentemente de 50% a 70%:

TargetTrackingScalingPolicyConfiguration:
  TargetValue: 70.0
  PredefinedMetricSpecification:
    PredefinedMetricType: DynamoDBReadCapacityUtilization
  ScaleInCooldown: 60
  ScaleOutCooldown: 60

Você pode alternar entre os modos uma vez a cada 24 horas. Assumir que o modo on-demand é universalmente mais barato é um erro que custa caro; assim como assumir que o modo provisionado é sempre o correto para tráfego com picos.

DynamoDB: Consistência, Streams e Global Tables

As leituras são, por padrão, eventualmente consistentes (eventually consistent), podendo retornar dados desatualizados em até ~1 segundo, custando 0.5 RCU. Definir ConsistentRead=true retorna o último valor confirmado (committed) pelo dobro do custo. Leituras fortemente consistentes (strongly consistent reads) não são suportadas através de global secondary indexes ou do DAX — esses caminhos sempre retornam dados eventualmente consistentes.

DynamoDB Streams captura alterações no nível do item como um log ordenado, retido por 24 horas, acionando o Lambda para processamento posterior (downstream), como indexação para busca, notificações e desnormalização entre tabelas, sem a necessidade de polling.

Global Tables utilizam os Streams para fornecer replicação multi-região e multi-ativa com resolução de conflitos do tipo “o último a escrever vence” (last-writer-wins). Elas são a solução correta quando leituras e escritas precisam ser locais em múltiplas Regiões. Mas elas praticamente dobram os custos de armazenamento e escrita — cada escrita consome uma WCU em cada Região de réplica — e enfraquecem a consistência entre as Regiões. A armadilha é habilitar Global Tables quando uma única Região já satisfaz os requisitos de disponibilidade: o DynamoDB em uma única Região já é replicado em três AZs com 99.99% de disponibilidade. Uma alta disponibilidade (HA) de baixo custo em uma única Região consiste em uma tabela de Região única com o PITR habilitado e, se desejado, capacidade provisionada com auto-scaling.

Point-in-Time Recovery (PITR) fornece backups contínuos com granularidade de restauração de segundos para os últimos 35 dias com uma sobrecarga (overhead) insignificante. Habilite-o em qualquer tabela de produção — ele atende a requisitos de RPO típicos de minutos, em vez de horas. Para retenção mais longa (exigências regulatórias), integre o AWS Backup para backups agendados, gerenciados por ciclo de vida e que podem ser copiados entre regiões.

TTL permite que você especifique um atributo contendo um timestamp de expiração no formato Unix epoch; o DynamoDB exclui itens expirados de forma assíncrona e sem custo, o que é ideal para armazenamento de sessões, tokens efêmeros ou caches de eventos. As exclusões por TTL passam pelos Streams para arquivamento posterior (downstream):

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

Para análise de dados (analytics), a função export to S3 produz um snapshot point-in-time que pode ser lido pelo Athena, Redshift Spectrum ou EMR sem consumir a capacidade da tabela — um padrão muito melhor do que fazer um scan na tabela.

DAX: DynamoDB Accelerator

DAX é um cache em memória, totalmente gerenciado e do tipo write-through, projetado especificamente para o DynamoDB, oferecendo latência de leitura de microssegundos em comparação com a linha de base de milissegundos de um dígito do DynamoDB. Sua característica distintiva é a compatibilidade de API: o cliente DAX é um substituto direto (drop-in replacement) para o cliente do SDK do DynamoDB, de modo que as aplicações o adotam apenas alterando a configuração do endpoint, em vez de reescrever a lógica de consulta:

import amazondax
dax = amazondax.AmazonDaxClient(
    endpoint_url='dax://cluster.abc.dax-clusters.us-east-1.amazonaws.com')
table = dax.Table('Products')
resp = table.get_item(Key={'sku': '1234'})  # microsecond hit path

O DAX mantém dois caches: um cache de itens (item cache) para resultados de GetItem/BatchGetItem e um cache de consultas (query cache) para resultados de Query/Scan. As escritas são do tipo write-through — o DAX atua como um proxy para o DynamoDB e atualiza seu cache de itens em caso de sucesso — mas o cache de consultas depende de um TTL, então os resultados das consultas podem ficar desatualizados mesmo para itens recém-escritos.

Duas restrições são importantes. Primeiro, o DAX acelera apenas leituras eventualmente consistentes; leituras fortemente consistentes ignoram (bypass) o cache. Segundo, outros processos de escrita que não passam pelo DAX causam dados desatualizados (staleness). Para uma página de detalhes de produto acessada milhões de vezes por dia, o DAX é o acelerador com a menor sobrecarga operacional — sem código de invalidação de cache, sem gerenciamento de cluster separado. O ElastiCache na frente do DynamoDB funcionaria, mas exige uma lógica de cache-aside que o DAX torna desnecessária.

ElastiCache: Redis e Memcached

O ElastiCache oferece acesso a dados em memória com latência de submilissegundos como um serviço gerenciado que executa Redis ou Memcached. A escolha do motor é orientada por funcionalidades:

• Memcached — cache de chave/valor puramente multithreaded com sharding horizontal, sem persistência, sem replicação, sem pub/sub. Use apenas para cache efêmero, onde a perda de todo o cache é aceitável.
• Redis — suporta replicação, Multi-AZ com failover automático, modo cluster para sharding, persistência, pub/sub, sorted sets, transações e criptografia em trânsito e em repouso. Necessário para qualquer caso de uso que exija durabilidade ou tipos de dados complexos.

Dois padrões canônicos predominam.

Armazenamento de sessão centralizado. Quando um ALB distribui o tráfego entre instâncias EC2 ou ECS stateless, o armazenamento de sessão local força o uso de sticky sessions, o que desequilibra a carga e causa falhas durante scale-in, deployments e falhas de AZ. Externalizar as sessões para o Redis permite que qualquer instância atenda a qualquer requisição, e as sessões sobrevivem a falhas de host:

import redis, json
r = redis.Redis(host='sessions.abc123.ng.0001.use1.cache.amazonaws.com',
                port=6379, ssl=True)

def save_session(sid, data, ttl=1800):
    r.setex(f"sess:{sid}", ttl, json.dumps(data))

Offload de leitura para consultas caras — leaderboards (sorted sets do Redis via ZADD/ZREVRANGE), buscas em catálogos, agregações. As estratégias de cache devem corresponder às necessidades de consistência:

• Lazy loading (cache-aside): a aplicação lê o cache; em caso de cache miss, lê o banco de dados e popula o cache com um TTL. É simples, mas os cold misses (erros de cache frio) prejudicam o desempenho e os dados podem ficar obsoletos.
• Write-through: a aplicação escreve no cache e no banco de dados na mesma operação. O cache permanece atualizado, mas as escritas são mais lentas e dados não utilizados continuam ocupando memória.
• Write-back (write-behind): as escritas vão primeiro para o cache e são descarregadas (flushed) de forma assíncrona para o banco de dados. São as escritas mais rápidas, mas uma falha no cache causa perda de dados.

data = r.get(f"product:{sku}")
if data is None:
    data = db.query("SELECT * FROM products WHERE sku=%s", sku)
    r.setex(f"product:{sku}", 300, serialize(data))

Depender de qualquer camada de cache sem uma estratégia de invalidação — TTL, DEL explícito na atualização ou write-through — produz leituras de dados obsoletos (stale reads). O modo de falha é silencioso: a aplicação parece correta até que os usuários notem a divergência. O cache também é frequentemente a maneira mais barata de escalar leituras além do que as read replicas suportam confortavelmente e protege o banco de dados primário durante picos de tráfego.

Diferente do DAX, o ElastiCache é agnóstico em relação ao motor — você é responsável pela lógica de invalidação — e é por isso que o DAX ganha em simplicidade operacional quando o armazenamento de backend é o DynamoDB.

Migração: DMS e SCT

O AWS Database Migration Service (DMS) replica dados entre motores homogêneos (Oracle→Oracle, MySQL→Aurora MySQL) ou heterogêneos (Oracle→Aurora PostgreSQL, SQL Server→RDS MySQL, on-prem→DynamoDB). Uma tarefa do DMS tem três fases:

1. Full load (Carga completa) — cópia em massa das linhas existentes.
2. CDC (change data capture) — acompanha o log de transações da origem e aplica as alterações contínuas.
3. Full load + CDC — o padrão comum para tempo de inatividade mínimo: a origem permanece online, o DMS mantém o destino sincronizado, e a transição (cutover) é uma rápida troca de DNS.

aws dms create-replication-task \
  --replication-task-identifier ora-to-aurora \
  --source-endpoint-arn $SRC --target-endpoint-arn $TGT \
  --migration-type full-load-and-cdc \
  --table-mappings file://mappings.json \
  --replication-instance-arn $RI

O DMS Serverless elimina a necessidade de dimensionar e gerenciar instâncias de replicação — a capacidade é provisionada automaticamente de acordo com a carga de trabalho, adequando-se a CDC variável ou de longa duração. Os motores de origem devem ter o supplemental logging (Oracle) ou o binary logging no formato ROW (MySQL) habilitado. Para cargas iniciais (seeds) muito grandes, o DMS se integra com o Snowball Edge para cargas offline.

O DMS move dados, não o schema. Para migrações heterogêneas, você o combina com a AWS Schema Conversion Tool (SCT), que converte stored procedures, views, triggers, sequences e tipos específicos de dialetos — por exemplo, Oracle PL/SQL para PostgreSQL PL/pgSQL, ou T-SQL para Aurora MySQL. A SCT produz um relatório de avaliação que sinaliza objetos que exigem retrabalho manual (normalmente de 5 a 20% para bases de código complexas). Executar o DMS sozinho para uma migração entre motores diferentes é um erro comum: embora o DMS possa criar tabelas de destino rudimentares, ele não traduz procedures ou tipos proprietários corretamente. Para migrações homogêneas, a SCT é desnecessária — ferramentas nativas (mysqldump, pg_dump, RMAN) mais o CDC do DMS são suficientes.

O padrão completo para migração entre motores:

1. SCT: convert schema, apply to target RDS/Aurora
2. DMS full-load task: bulk copy existing data
3. DMS CDC task: capture ongoing changes from source
4. Cutover: stop writes at source, wait for CDC lag = 0, redirect app

Backups e Point-in-Time Recovery (PITR)

Os backups automatizados do RDS combinam snapshots diários com backups de logs de transação a cada 5 minutos, permitindo PITR para qualquer segundo dentro da janela de retenção (1–35 dias, padrão de 7). A restauração cria uma nova instância — não é possível restaurar na mesma instância (in-place) — então os endpoints da aplicação ou CNAMEs devem ser atualizados. Snapshots manuais persistem além do período de retenção e sobrevivem à exclusão da instância (sujeito à configuração de snapshot final), podem ser copiados entre Regiões para DR e podem ser compartilhados entre contas.

O Fast Snapshot Restore (FSR) para snapshots baseados em EBS elimina a penalidade de lazy-load, dando aos volumes restaurados desempenho total imediatamente — útil ao criar múltiplos ambientes a partir de um único snapshot sob pressão de tempo. A clonagem do Aurora ignora completamente os snapshots para cópias na mesma região. O PITR do DynamoDB é um recurso paralelo que deve ser habilitado por tabela e produz uma nova tabela na restauração.

Bancos de Dados Especializados (Purpose-Built)

Selecionar um motor especializado (purpose-built) quando os padrões de acesso o exigem evita reestruturações caras. O Amazon Neptune é um banco de dados de grafos gerenciado que suporta Gremlin, openCypher e SPARQL — apropriado quando as consultas percorrem relacionamentos (redes de fraude, grafos sociais, grafos de conhecimento) onde joins recursivos em um motor relacional seriam proibitivamente caros. O Amazon QLDB é um ledger imutável e criptograficamente verificável com um diário somente de acréscimo (append-only), adequado para sistemas de registro que exigem auditoria à prova de adulteração — procedência da cadeia de suprimentos, transações financeiras, registros do Detran. O DynamoDB é o padrão para acesso de chave-valor ou documento com latência de milissegundos de um dígito em qualquer escala, usando padrões como design de tabela única (single-table design), chaves de classificação compostas para acesso hierárquico e GSIs para caminhos de acesso alternativos. Forçar essas cargas de trabalho no RDS cria contenção de bloqueio (escritas de ledger), complexidade de consulta (travessia de grafos) ou limites de escalabilidade (chave-valor de alta vazão) — cada um muito mais caro de remediar posteriormente do que escolher corretamente no momento do design.

Resumo das Armadilhas

• Read replicas como HA. São assíncronas, sem promoção automática, o endpoint muda na promoção e transações em andamento são perdidas. Multi-AZ é a resposta para HA.
• Multi-AZ para escalabilidade de leitura. A instância de standby não pode ser lida no Multi-AZ padrão do RDS. Use read replicas ou réplicas do Aurora.
• Produção em Single-AZ. Sem um alvo de failover; perde disponibilidade em qualquer evento de AZ ou reinicialização da instância. Multi-AZ custa aproximadamente o dobro para um salto qualitativo em disponibilidade.
• Réplica dimensionada igual à primária por padrão. As réplicas geralmente precisam de muito menos; dimensione de acordo com a carga de trabalho medida, a menos que a réplica seja um alvo de promoção.
• DynamoDB On-demand sempre mais barato. O custo por requisição é cerca de 6 a 7 vezes maior; provisionado + auto-scaling é a melhor opção para cargas de trabalho estáveis.
• Global Tables para necessidades de uma única região. Dobra o custo e enfraquece a consistência sem nenhum benefício, a menos que a proximidade do usuário em múltiplas regiões ou DR seja um requisito.
• Secundárias do Aurora Global Database atendem a escritas. Elas são somente leitura até que um failover gerenciado as promova.
• Lambda → RDS sem o RDS Proxy. Uma tempestade de conexões esgota o max_connections; pools dentro da função não ajudam entre ambientes de execução concorrentes.
• DMS sozinho para migração heterogênea. Move os dados, não o schema. Use em conjunto com o SCT.
• Armazenamento fixo no RDS sem autoscaling ou alarmes de FreeStorageSpace. Interrupção latente — o estado storage-full rejeita escritas.
• Cache sem estratégia de invalidação. Dados obsoletos silenciosamente. TTLs, write-through ou invalidação explícita são inegociáveis.
• Leituras fortemente consistentes através do DAX ou de GSIs. Ambos os caminhos servem apenas dados eventualmente consistentes.

← Entrega de Conteúdo · Todos os domínios · Analytics →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →