Amazon CLF-C02: Serviços de Banco de Dados Principais — Guia de estudos

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

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

Bancos de dados relacionais gerenciados: Amazon RDS e Amazon Aurora

O Amazon RDS fornece mecanismos relacionais totalmente gerenciados (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle) com backups automatizados, Multi‑AZ para alta disponibilidade, réplicas de leitura (read replicas) para escalabilidade e restauração baseada em snapshots. O Aurora é um mecanismo criado especificamente para a nuvem, compatível com MySQL e PostgreSQL, que separa a computação de uma camada de armazenamento distribuída e tolerante a falhas para oferecer maior throughput, recuperação rápida de falhas e recursos como backtrack e Global Database para replicação entre regiões. Os modelos de preços incluem instâncias On-Demand para capacidade flexível, Reserved Instances ou Savings Plans para economias previsíveis, e modelos de capacidade serverless ou com autoescalabilidade para o Aurora Serverless para alinhar o custo com cargas de trabalho variáveis. As principais decisões de arquitetura dependem do perfil de leitura/escrita, dos requisitos de latência e da tolerância operacional: escolha o RDS quando as necessidades de compatibilidade e licenciamento são predominantes, e o Aurora quando você precisa de maior desempenho, autoescalabilidade de armazenamento ou leituras globais. Armadilhas comuns para profissionais são subprovisionar IOPS para cargas de trabalho com alta intensidade de escrita, esquecer de habilitar o Multi-AZ para produção, manter as credenciais mestre padrão e não testar a recuperação para um ponto no tempo (point-in-time recovery). Para conformidade (compliance), habilite a criptografia em repouso (at rest) usando o AWS KMS, force o uso de TLS para criptografia em trânsito (in-transit) e valide que os backups automatizados e snapshots atendem aos objetivos de retenção e de recuperação de desastres (DR) entre regiões.

Bancos de dados NoSQL, de cache e de grafo: DynamoDB, ElastiCache e Amazon Neptune

Para cargas de trabalho de chave-valor e de documentos em grande escala, o Amazon DynamoDB oferece latência de milissegundos de um dígito, particionamento automático e dois modos de capacidade: provisionado (com autoescalabilidade) e sob demanda (on-demand) para tráfego imprevisível. Recursos como DynamoDB Streams, global tables e point-in-time recovery (PITR) suportam replicação, captura de dados de alteração (change data capture) e backups. Uma armadilha comum é um design ruim da chave de partição, que cria partições quentes (hot partitions) e throttling (limitação de requisições); modele primeiro os padrões de acesso aos dados. Para cargas de trabalho em memória de baixa latência, use o ElastiCache: o Redis oferece persistência, clusterização e pub/sub, enquanto o Memcached é um cache simples e multithreaded. Use o DAX para cargas de trabalho do DynamoDB com uso intensivo de leitura que exigem cache de microssegundos. Para consultas de grafo centradas em relacionamentos, o Amazon Neptune é um banco de dados de grafo totalmente gerenciado que suporta Gremlin e SPARQL. Decisões de preço: o modo on-demand do DynamoDB é fácil, mas mais caro com tráfego alto e constante; o modo provisionado com autoescalabilidade e Capacidade Reservada (Reserved Capacity) pode ser muito mais barato. O dimensionamento do cache, as políticas de remoção (eviction) e as escolhas de persistência no ElastiCache afetam o custo e a recuperação. Avalie a durabilidade, os modelos de consistência e a complexidade operacional ao escolher entre bancos de dados NoSQL gerenciados, caches em memória e bancos de dados de grafo.

DynamoDB vs RDS/Aurora: DynamoDB para grande escala, design flexível de esquema e de tabela única; RDS/Aurora para consultas SQL complexas, transações e integridade relacional.
ElastiCache (Redis) vs DAX: Redis para cargas de trabalho em memória de propósito geral e com persistência; DAX é um cache de leitura específico para o DynamoDB com integração no lado do cliente.
Neptune: Use quando travessias (traversals) e análises de grafos são centrais para a aplicação.

Padrões de analytics e data lake: Amazon Redshift, Athena e opções de armazenamento do S3

O Amazon Redshift é um data warehouse colunar em escala de petabytes, otimizado para consultas analíticas complexas e alta concorrência. O Redshift moderno (nós RA3) desacopla a computação do armazenamento gerenciado, permitindo que você escale a computação de forma independente e reduza o custo ao aproveitar o S3 como armazenamento gerenciado; o Redshift Spectrum consulta dados no S3 diretamente para integração com data lake. Para consultas SQL ad-hoc sobre arquivos, o Amazon Athena fornece análise serverless, paga por consulta (cobrada por TB verificado) e é ideal para arquivos CSV/Parquet/JSON no S3; otimizar formatos e compressão reduz drasticamente o custo. O S3 oferece várias classes de armazenamento: para padrões de acesso desconhecidos, o S3 Intelligent‑Tiering move objetos automaticamente entre as camadas de acesso para minimizar o custo sem taxas de recuperação; para arquivamento de longo prazo, considere o S3 Glacier ou o Glacier Deep Archive, onde se aplicam latência e taxas de recuperação. As compensações de custo (trade-offs) incluem armazenamento versus computação: comprima, particione e use formatos colunares para reduzir os volumes de verificação (scan); considere o Concurrency Scaling e o Workload Management do Redshift para um desempenho previsível. Para cargas de trabalho de machine learning vinculadas à análise de dados, o treinamento pesado pode exigir famílias de instâncias EC2 com GPU (séries P ou G), mas a maioria das cargas de trabalho de banco de dados analítico depende de CPU otimizada e execução colunar, em vez de GPUs.

Melhores práticas de migração, backup, segurança e operações

A migração e a proteção de bancos de dados exigem a combinação certa de serviços e políticas. O AWS Database Migration Service (DMS) lida com migrações homogêneas e heterogêneas com tempo de inatividade mínimo; o Schema Conversion Tool ajuda a converter esquemas de banco de dados ao mover entre tipos de engine. Para backups e proteção baseada em políticas, use os recursos nativos do engine (backups e snapshots automatizados do RDS, DynamoDB PITR) em conjunto com o AWS Backup para políticas de backup centralizadas e entre serviços, e cópias entre contas ou entre regiões. A segurança deve incluir políticas IAM de privilégio mínimo, criptografia em trânsito (TLS) e em repouso (KMS), e controles de rede: os security groups são firewalls stateful no nível do host que você anexa às instâncias, enquanto as network ACLs são filtros stateless no nível da sub-rede — ambos são complementares, mas diferentes em comportamento. Sob a responsabilidade compartilhada, a AWS gerencia a infraestrutura da nuvem, enquanto os clientes gerenciam os dados, o IAM, os patches no nível do sistema operacional em instâncias autogerenciadas e a rotação de chaves para segredos e credenciais de acesso. A automação operacional usando CloudFormation, a AWS CLI ou SDKs permite o provisionamento de ambientes repetíveis; armadilhas comuns são depender da conta raiz, manter políticas IAM amplas, negligenciar a rotação de chaves e falhar no monitoramento usando CloudWatch, VPC Flow Logs ou AWS Config. Para grandes transferências de dados, considere o AWS Snowball ou o DataSync para mover terabytes/petabytes de forma segura com criptografia em trânsito e validação de integridade.

Problema Prático: Cenário de Caso de Uso

Cenário: A AcmeRetail opera uma plataforma de e-commerce sazonal com um banco de dados OLTP MySQL on-premises e grandes arquivos CSV históricos de vendas em um compartilhamento NFS local. A conta AWS deles possui uma VPC com sub-redes privadas e um Transit Gateway para o data center. Eles precisam migrar o banco de dados transacional com tempo de inatividade mínimo e tornar os dados históricos consultáveis para BI.

Desafio: Mover o banco de dados de produção com tempo de inatividade quase zero, habilitar análises escaláveis nos CSVs históricos e garantir backups, criptografia e acesso de privilégio mínimo.

Abordagem Recomendada:

Use o AWS Database Migration Service (DMS) com o Schema Conversion Tool, se necessário, para migrar o MySQL para o Amazon Aurora (compatível com MySQL), configurando a replicação contínua para minimizar o tempo de inatividade.
Transfira os CSVs históricos para o Amazon S3 usando o AWS DataSync ou o Snowball (para volumes muito grandes), armazene-os no S3 usando o Intelligent‑Tiering e converta-os para Parquet com o AWS Glue ETL para eficiência nas consultas.
Provisione o Amazon Redshift (RA3) ou use o Amazon Athena sobre os dados do S3 (Parquet) para consultas de BI; use o Redshift Spectrum se for combinar consultas de warehouse e lake.
Implemente backups automatizados (backups e snapshots automatizados do RDS), habilite a criptografia com chaves KMS, restrinja o acesso com roles IAM e security groups de privilégio mínimo e centralize as políticas de backup com o AWS Backup.

Justificativa: A replicação contínua do DMS permite uma migração com tempo de inatividade quase zero para sistemas transacionais; S3 + Parquet + Athena/Redshift minimiza o custo analítico e o tamanho das varreduras (scans); KMS, backups e IAM de privilégio mínimo estão alinhados com a responsabilidade compartilhada e as melhores práticas operacionais para disponibilidade, segurança e controle de custos.

← Serviços de Armazenamento Principais · Todos os domínios · Redes e Entrega de Conteúdo →

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