Amazon DOP-C02: Armazenamento, Bancos de Dados e Gerenciamento de Dados — Guia de estudos

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Visão Geral

O armazenamento, os bancos de dados e a movimentação de dados na AWS devem ser projetados para durabilidade, disponibilidade, eficiência de custos e automação. Dominar as classes de armazenamento e a replicação do S3, a capacidade e a distribuição global do DynamoDB, os controles de configuração e os padrões de backup do RDS/Aurora, o cache em memória, os sistemas de arquivos compartilhados e os serviços de migração de dados permite criar sistemas confiáveis e de baixa latência com comportamento de recuperação previsível e gastos controlados.

Amazon S3: classes de armazenamento, ciclo de vida, intelligent tiering e replicação

As classes de armazenamento do S3 alinham o custo aos padrões de acesso:

Standard: multi-AZ, baixa latência, sem taxas de recuperação. Padrão para dados acessados com frequência (hot data).
Intelligent-Tiering (S3 INT): multi-AZ com divisão automática em camadas (tiering) entre as camadas de Acesso Frequente e Acesso Infrequente, e camadas de arquivamento opcionais. Há uma cobrança por objeto para monitoramento e automação; objetos menores que 128 KB não são movidos automaticamente entre as camadas. As camadas Archive Access e Deep Archive Access são opcionais (opt-in) com limites baseados no último acesso; taxas de recuperação se aplicam a partir das camadas de acesso não frequente.
Standard-IA e One Zone-IA: custo de armazenamento mais baixo com taxas de recuperação; cobrança mínima de armazenamento de 30 dias. O One Zone-IA é single-AZ para dados que podem ser recriados.
Glacier Instant Retrieval: acesso em milissegundos com economia de arquivamento; mínimo de 90 dias.
Glacier Flexible Retrieval: recuperação de minutos a horas, com opções bulk/standard/expedited; mínimo de 90 dias.
Glacier Deep Archive: recuperação de horas a 12 horas; mínimo de 180 dias. Escolha a camada mais fria viável, considerando as cobranças de duração mínima de armazenamento, as taxas de recuperação e os tempos de acesso necessários.

As políticas de ciclo de vida (Lifecycle policies) automatizam transições e expirações usando filtros (prefixo, tags) para um controle refinado. As ações principais incluem a transição para as camadas IA/Glacier após limites de inatividade, a transição/expiração de versões não atuais em buckets versionados, a expiração de marcadores de exclusão (delete markers) e o cancelamento de uploads de várias partes incompletos (incomplete multipart uploads). O ciclo de vida e o tagueamento de objetos são cruciais para impor a retenção de dados e a exclusão defensável, juntamente com o S3 Object Lock (modos governance/compliance) quando a imutabilidade é necessária.

O Intelligent-Tiering é ideal quando os padrões de acesso são desconhecidos ou variáveis. Ele preserva o desempenho (sem atraso na recuperação das camadas de acesso frequente/IA), elimina a necessidade de rearquitetura quando os padrões mudam e pode, opcionalmente, arquivar automaticamente em camadas profundas com base no último acesso, fornecendo a melhor combinação de agilidade e controle de custos para conjuntos de dados de longa duração com acesso esporádico.

A replicação do S3 fornece uma cópia durável e assíncrona de objetos:

Requisitos: versionamento habilitado na origem e no destino. A configuração de replicação define o bucket/conta/Região de destino, filtro por prefixo/tags, replicação de metadados (ACLs, tags, S3 Object Lock), classe de armazenamento e se deve replicar marcadores de exclusão e objetos existentes.
Same-Region Replication (SRR): conformidade/soberania de dados, agregação de logs, processamento atômico entre contas.
Cross-Region Replication (CRR): DR, redução de latência, distribuição global, conformidade.
Objetos criptografados com KMS: a role de replicação deve ter permissão para descriptografar com a chave KMS de origem e criptografar com a chave KMS de destino. Especifique a chave KMS da réplica na regra de replicação em EncryptionConfiguration. Para replicação entre contas, atualize a política do bucket de destino para permitir que a role de replicação grave dados.
Objetos existentes: use o S3 Batch Replication para preencher os dados retroativamente (backfill).
Replication Time Control (RTC): adiciona um SLA de 15 minutos para a conclusão da replicação, com métricas e notificações de replicação para monitorar os SLAs. Útil para conformidade e RPOs rigorosos.
Propriedade e acesso: ao replicar entre contas, habilite a opção bucket owner preferred ou Object Ownership bucket owner enforced para evitar a complexidade das ACLs e garantir que a conta de destino seja proprietária das réplicas.

Bancos de dados na AWS: DynamoDB, RDS e Aurora

Modos de capacidade e escalonamento do DynamoDB:

On-demand: sem planejamento de capacidade; preço por requisição; ideal para cargas de trabalho imprevisíveis ou com picos e para novas tabelas sem tráfego conhecido.
Provisionado: defina RCUs/WCUs com o DynamoDB Application Auto Scaling com base na utilização alvo; apropriado para tráfego estável ou previsível e para controle de custos.
Capacidade adaptativa: redistribui automaticamente o throughput da partição para chaves quentes (hot keys), mas partições extremamente quentes ainda precisam de balanceamento de carga (ex: write sharding). Os GSIs têm capacidade separada; modele com cuidado para evitar throttling.
O tamanho do item afeta a capacidade: 1 WCU por escrita de 1 KB; 1 RCU por leitura fortemente consistente de 4 KB ou por leitura eventualmente consistente de 8 KB.

DynamoDB Streams e DAX:

Os Streams capturam mutações no nível do item com retenção de 24 horas. Escolha os tipos de visualização para incluir imagens NEW/OLD. Padrões comuns: gatilhos do Lambda para escritas orientadas a eventos/CQRS, sincronização entre tabelas e trilhas de auditoria. A ordenação é por chave de partição e a entrega é do tipo “pelo menos uma vez” (at-least-once).
O DAX é um cache em memória gerenciado e compatível com a API do DynamoDB que reduz drasticamente a latência de leitura. Ele suporta leituras eventualmente consistentes; leituras fortemente consistentes devem contornar o DAX. Ele oferece write-through para mutações de itens e invalidação baseada em TTL. Use clusters Multi-AZ para alta disponibilidade e posicione as sub-redes do DAX próximas aos clientes.

Tabelas globais do DynamoDB:

Replicação multi-região e multi-master usando Streams com resolução de conflitos do tipo last-writer-wins (o último a escrever vence) baseada em um timestamp do sistema. Projete para evitar atualizações concorrentes nos mesmos atributos entre regiões ou implemente uma reconciliação no lado da aplicação.
O atributo TTL é replicado como dados normais do item; exclusões acionadas por TTL são processadas por região e não são replicadas como exclusões explícitas.
Backups e PITR têm escopo de região; restaure para novas tabelas por região e (opcionalmente) recrie-as como uma nova tabela global.

Configuração e backups do Amazon RDS:

Os parameter groups definem os parâmetros do motor (engine). Parâmetros estáticos exigem reinicialização; parâmetros dinâmicos são aplicados imediatamente onde suportado. Use DB parameter groups para motores no nível da instância e cluster parameter groups para o Aurora.
Os option groups habilitam recursos nativos do motor (ex: Oracle TDE/OEM, backup/restauração nativa do SQL Server, plugins do MySQL/MariaDB). As opções podem exigir reinicializações do motor; gerencie as janelas de mudança com cuidado.
Backups automatizados habilitam o PITR (Point-In-Time Recovery) dentro de uma janela de retenção (até 35 dias). Eles capturam snapshots diários e logs de transação para o S3; as restaurações produzem novas instâncias.
Snapshots manuais são retidos até serem excluídos, são copiáveis entre regiões e compartilháveis entre contas (respeitando as permissões da chave KMS para snapshots criptografados). Use a cópia de snapshots entre regiões como base para DR (Disaster Recovery).

Especificidades do Amazon Aurora:

Endpoints: o endpoint do cluster (writer) sempre aponta para a instância primária para escritas. O endpoint de leitura (reader) balanceia a carga entre as réplicas. Endpoints personalizados podem selecionar um subconjunto de réplicas de leitura para pools de leitura em camadas ou cargas de trabalho especializadas. Sempre aponte as escritas para o endpoint de escrita e as leituras para o endpoint de leitura/endpoint personalizado apropriado para interrupções mínimas durante failovers.
Serverless v2: escalonamento instantâneo e granular de ACUs sem reinicialização. Ele é executado dentro de um cluster Aurora, suporta instâncias mistas (serverless e provisionadas) e é adequado para cargas de trabalho com picos, dev/test ou aplicações multi-tenant com demanda irregular. Ele preserva a consistência da conexão melhor que a v1 devido ao escalonamento contínuo.
Clonagem: clones rápidos do tipo copy-on-write dentro de uma região para dev/test, ciência de dados ou validação de mudanças blue/green. Os clones são eficientes em termos de espaço e divergem apenas nas páginas alteradas. Você pode encadear clones; exclua-os quando terminar para recuperar o armazenamento.

Caching e sistemas de arquivos compartilhados: ElastiCache e EFS

ElastiCache for Redis vs. Memcached:

Redis: estruturas de dados avançadas, replicação, Pub/Sub, Lua, streams, dados geoespaciais, conjuntos ordenados (sorted sets) e persistência via snapshots; suporta failover automático Multi-AZ e Redis Global Datastore para réplicas de leitura entre regiões. Escolha o Redis quando precisar de tipos de dados ricos, durabilidade (restauração de snapshot) ou alta disponibilidade com failover.
Memcached: simples, multithreaded, sem replicação ou persistência; scale-out via sharding no lado do cliente; é stateless e fácil de escalar horizontalmente. Escolha o Memcached para caching puro e efêmero com altíssimo throughput e quando você quiser controlar o sharding no cliente. Modo cluster e grupos de replicação do Redis:
Modo cluster desabilitado: um único shard com uma instância primária e réplicas; escalonamento vertical ou escalonamento horizontal limitado via réplicas de leitura.
Modo cluster habilitado: sharding por hash-slot entre múltiplos shards primários, cada um com suas réplicas, permitindo um scale-out quase linear. Os grupos de replicação definem a topologia primário/réplica e o failover Multi-AZ. Os backups são por grupo de replicação; teste o failover para validar o RTO.

Amazon EFS para arquivos POSIX compartilhados:

Mount targets: crie um em cada AZ da VPC para garantir caminhos de acesso dentro da AZ e disponibilidade. Security groups nos mount targets controlam o tráfego NFS; use o EFS mount helper para TLS em trânsito e autorização do IAM, se necessário.
Access points: impõem um diretório raiz e uma identidade POSIX (UID/GID) para as aplicações, permitindo isolamento multi-tenant e montagem simples com privilégio mínimo pelo ECS/EKS/EC2 sem precisar coordenar o gerenciamento de usuários do sistema operacional.
Gerenciamento do ciclo de vida e classes de armazenamento: EFS Standard e Standard-IA (Regional, multi-AZ) e One Zone/One Zone-IA (single-AZ). O Intelligent Tiering move arquivos automaticamente entre as classes Standard e IA com base no último horário de acesso; você também pode definir políticas de transição explícitas. Escolha as variantes One Zone para dados recriáveis ou não críticos para economizar custos.
Combine com o AWS Backup para políticas centralizadas e backups entre contas/regiões.

Migração de dados: DMS, Snowball e DataSync

AWS Database Migration Service (DMS): migração online com tempo de inatividade mínimo usando carga completa mais captura de dados de alteração (CDC). Suporta migrações homogêneas e heterogêneas por meio de conversão de esquema integrada (com o AWS Schema Conversion Tool para conversões complexas). Use para lift-and-shift para RDS/Aurora, para o DynamoDB (via mapeamento JSON) ou para replicação contínua para descarregamento de leitura (read offloading) ou transições em fases (phased cutovers). Dimensione as instâncias de replicação para picos de taxas de alteração; garanta que os logs de origem (ex: binlog/redo) retenham histórico suficiente.
AWS Snowball (Edge Storage/Compute Optimized): transferência de dados offline em escala de petabytes quando as redes são limitadas/caras ou quando você precisa preencher (seed) grandes conjuntos de dados do S3/EFS rapidamente. Encadeie vários dispositivos para cargas de múltiplos petabytes. Use para cargas iniciais em massa, coleta remota/na borda (edge) ou migração de data centers com restrições. Os dados são criptografados de ponta a ponta com o KMS; o rastreamento de dispositivos e os selos à prova de violação suportam a cadeia de custódia.
AWS DataSync: transferência online e acelerada de NFS/SMB para S3/EFS/FSx e entre serviços de armazenamento/Regiões da AWS. Ele lida com detecção de alterações incrementais, paralelização, compressão, controle de largura de banda, agendamento e verificações de integridade. Use para mover deltas recorrentes, fluxos de trabalho híbridos e para substituir scripts rsync personalizados por automação gerenciada. Implante o agente do DataSync on-premises para acessar o armazenamento local.

Cenário de Problema Prático

A Shopify precisa modernizar seu pipeline global de mídia de produtos e dados de catálogo, ao mesmo tempo em que melhora a resiliência e a latência para compradores em todo o mundo. A empresa deve: replicar imagens de produtos entre Regiões e contas com um RPO rigoroso, reduzir a latência de leitura do DynamoDB na América do Norte e na Europa, migrar ativos NFS on-premises com deltas contínuos e simplificar as operações do RDS com backups confiáveis.

Implementar o S3 CRR com Replication Time Control do bucket de mídia principal em us-east-1 (conta de merchandising) para um bucket de destino em eu-west-1 (conta de entrega).

Por quê: O CRR satisfaz a separação entre Regiões e contas para o princípio do menor privilégio e soberania de dados. O RTC oferece um SLA de replicação de 15 minutos e monitoramento para um RPO de nível de conformidade (compliance). A política de bucket entre contas garante que a função de replicação de origem possa escrever, e especificar uma chave KMS de destino mantém os domínios de criptografia.

Definir regras de replicação do S3 filtradas por prefixo e tag para segregar originais, miniaturas e logs, e habilitar a replicação de marcadores de exclusão. Usar o S3 Batch Replication para preencher objetos legados.

Por quê: O escopo das regras evita custos de replicação desnecessários, e a replicação de marcadores de exclusão mantém as Regiões semanticamente consistentes. O S3 Batch Replication preenche lacunas históricas sem a necessidade de scripts personalizados.

Converter o catálogo de produtos e o inventário para uma tabela global do DynamoDB entre us-east-1 e eu-west-1; alterar as tabelas para capacidade sob demanda (on-demand) e adicionar clusters DAX por Região para APIs com uso intensivo de leitura.

Por quê: As tabelas globais fornecem escritas ativo-ativo com leituras/escritas locais de baixa latência e replicação contínua. O modo sob demanda remove o risco do planejamento de capacidade durante picos de tráfego. O DAX reduz as latências P99 para leituras frequentes (hot reads), protegendo o DynamoDB de acessos em rajadas (bursty).

Migrar a carga de trabalho relacional de pedidos para o Amazon Aurora MySQL com endpoints de gravador (writer) e leitor (reader); adicionar um pequeno leitor Aurora Serverless v2 para picos de cargas de trabalho analíticas e habilitar backups automatizados com uma política de retenção de 14 dias.

Por quê: Os endpoints de cluster/leitor desacoplam leitura/escrita e minimizam interrupções durante manutenções ou failover. O Serverless v2 absorve picos analíticos imprevisíveis de forma econômica. Backups automatizados oferecem PITR (Point-In-Time Recovery) e processos de restauração simplificados.

Introduzir o ElastiCache for Redis (com modo cluster ativado) para armazenamento de sessão e cache de disponibilidade de produtos com Multi-AZ e backups de snapshot; definir TTLs alinhados aos SLAs de negócio.

Por quê: As estruturas de dados do Redis e o failover Multi-AZ garantem sessões stateful rápidas e invalidação de cache quase em tempo real. O modo cluster escala horizontalmente conforme o tamanho do catálogo e o tráfego aumentam.

Criar um sistema de arquivos EFS Regional com pontos de montagem (mount targets) em cada AZ da aplicação e Access Points para cargas de trabalho que requerem armazenamento POSIX compartilhado (ex: processadores de mídia). Habilitar as transições de ciclo de vida do EFS para IA após 30 dias.

Por quê: O EFS fornece armazenamento compartilhado elástico e Multi-AZ; os Access Points impõem isolamento por aplicação e identidades POSIX. O gerenciamento do ciclo de vida (lifecycle) reduz custos automaticamente para ativos frios (cold) que permanecem acessíveis.

Migrar bibliotecas de mídia NFS on-premises usando o AWS DataSync com tarefas agendadas para sincronizações incrementais noturnas para o S3 e o EFS.

Por quê: O DataSync lida com detecção de alterações, paralelismo, verificação de integridade e controle de largura de banda melhor do que scripts rsync ad hoc, automatizando deltas contínuos com o mínimo de operações.

Mover o catálogo legado em PostgreSQL para o Aurora usando o AWS DMS (carga completa mais CDC) e o AWS Schema Conversion Tool onde necessário; fazer a transição (cut over) após o lag do CDC ser zerado.

Por quê: O DMS permite uma migração com tempo de inatividade quase zero, com replicação contínua garantindo a paridade dos dados na transição. O SCT lida com as conversões específicas do motor de banco de dados.

Fazer o seeding (carga inicial) de múltiplos petabytes de mídia histórica no S3 usando dispositivos Snowball Edge e, em seguida, mudar para o DataSync para os incrementos contínuos.

Por quê: O Snowball acelera a transferência inicial em massa sem saturar os links WAN; o DataSync sustenta as atualizações contínuas após a carga inicial (post-seed) com verificação e agendamento.

Essa arquitetura reduz as latências de leitura globais, oferece RPOs de replicação previsíveis, simplifica operações relacionais e backups, centraliza o armazenamento compartilhado com controles de acesso e fornece um caminho pragmático desde a migração offline em massa até o movimento de dados incremental e automatizado.

← Arquiteturas Orientadas a Eventos e Automação · Todos os domínios · Redes e Entrega de Conteúdo →

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