Amazon DEA-C01: Armazenamento de Dados e Arquitetura de Lake — Guia de estudos

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Faz parte do Amazon Data Engineer Associate DEA-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Este domínio abrange como os serviços de armazenamento e os mecanismos de banco de dados da AWS dão suporte a ingestão de dados em larga escala, arquivamento durável, desempenho de consultas e governança segura em plataformas de dados modernas. Engenheiros de dados devem equilibrar custo, latência de acesso, durabilidade e controle de acesso refinado ao integrar serviços como S3, Lake Formation, Redshift e DynamoDB em pipelines. Compreender as vantagens e desvantagens das classes de armazenamento, a automação do ciclo de vida, o armazenamento gerenciado versus local e os padrões de particionamento evita surpresas de desempenho e custo em produção.

Classes de armazenamento e políticas de ciclo de vida do Amazon S3

O S3 oferece várias classes de armazenamento e controles de ciclo de vida para otimizar custos e padrões de acesso. Configure a classe de armazenamento no momento do upload (pelo console ou CLI:

undefined

) ou use regras de ciclo de vida do bucket (

undefined

). O Intelligent-Tiering move objetos automaticamente entre as camadas de acesso frequente e infrequente e tem uma pequena taxa de monitoramento; habilite-o para padrões de acesso desconhecidos ou variáveis. Use regras de ciclo de vida para mover objetos para o GLACIER ou DEEP_ARCHIVE para retenção de longo prazo e para expirar/excluir versões antigas.

Critérios de decisão e trade-offs:

Intelligent-Tiering: baixa sobrecarga operacional para acesso variável, cobrança mensal de monitoramento por objeto; ideal quando o padrão de acesso é imprevisível.
Glacier vs Glacier Deep Archive: O Glacier oferece opções de recuperação padrão e acelerada mais rápidas com um custo de armazenamento maior; o Deep Archive é o mais barato para retenção de vários anos com tempos de recuperação em massa/padrão (horas).
Standard-IA vs Intelligent-Tiering: O Standard-IA tem uma cobrança mínima de 30 dias e taxas de recuperação — evite para dados acessados com frequência ou objetos de curta duração.

Notas operacionais:

Habilite o versionamento (

undefined

) e o object lock (

undefined

) para imutabilidade; habilitar o MFA Delete exige operações de CLI especiais e a conta do proprietário do bucket com MFA.

As transições de ciclo de vida se aplicam a versões de objetos e podem ser delimitadas por prefixo/tags; use

undefined

para evitar vazamentos de armazenamento.

Design de data lake com S3 e Lake Formation

Projete um data lake com o S3 como o repositório central de objetos e o Lake Formation para controle de acesso e catalogação centralizados. Registre os locais do S3 como recursos do Lake Formation, configure um AWS Glue Data Catalog e use concessões (grants) do Lake Formation para bancos de dados/tabelas (

undefined

). O Lake Formation pode aplicar controles refinados: em nível de coluna, em nível de linha (expressões de filtro) e mascaramento em nível de célula usando LF-tags e filtros de dados aplicados a consultas do Glue/Athena.

Padrões de configuração e governança chave:

Registrar local: use o console do Lake Formation para registrar

undefined

e anexar uma IAM role que permita ao Lake Formation rastrear/ler (crawl/read).

Políticas refinadas: defina LF-tags e anexe-as a tabelas/colunas; conceda permissões com uma lista de colunas (column-list) para restringir colunas e use expressões de filtro de linha (row-filter) para limitar as linhas retornadas para um principal (principal).
Lembre-se de que as permissões do Lake Formation podem substituir ou bloquear as permissões do IAM para o S3 no acesso via Glue/Athena — conceda acesso tanto no nível do Lake Formation quanto no nível do S3 quando necessário.

Pontos de decisão:

Use o Lake Formation quando precisar de catalogação centralizada, LF-tags e aplicação de políticas refinadas em múltiplos mecanismos de análise.
Para controle de acesso simples ou acesso por ferramentas externas, considere as políticas de bucket do S3 e o IAM, mas tenha cuidado: mecanismos de análise governados pelo Lake Formation podem ignorar concessões feitas apenas pelo IAM.

Arquitetura e armazenamento do Amazon Redshift

O Redshift separa a computação e o armazenamento gerenciado em nós RA3 em comparação com os nós DS2, que são baseados em SSD local. Os nós RA3 usam o Redshift Managed Storage (RMS), onde os dados residem no Amazon S3 gerenciado pelo cluster; escolha RA3 para armazenamento escalável com desempenho de consulta consistente e a capacidade de pagar pela computação separadamente. Os nós DS2 armazenam dados em discos locais da instância, o que exige um dimensionamento cuidadoso e redimensionamento quando os dados crescem.

Detalhes de configuração e operacionais:

Crie um cluster RA3 via console ou CLI:

undefined

Comando COPY: deve ser executado em um cluster com uma IAM role anexada que conceda acesso de leitura ao S3. Anexe a role na criação do cluster ou modifique o cluster para adicionar iam roles; o ARN da role (

undefined

) é referenciado no comando COPY como credenciais

undefined

Monitore as filas do WLM, a aceleração de consultas curtas (short query acceleration), a limpeza automática (automatic vacuuming) e use SORT/ENCODE para otimizar o armazenamento e o desempenho.

Comparação (RA3 vs DS2):

RA3: armazenamento desacoplado, tiering automático de dados para o S3, menor gerenciamento de armazenamento, ideal para conjuntos de dados em crescimento.
DS2: armazenamento SSD local, menor latência para dados locais, mas capacidade limitada e mais difícil de escalar.

DynamoDB e seleção de bancos de dados específicos

Escolha o DynamoDB para cargas de trabalho de chave-valor e de documentos em alta escala que exigem latência de milissegundos de um dígito. O design da tabela depende da seleção da chave de partição (e da chave de classificação opcional): use chaves de alta cardinalidade e bem distribuídas para evitar partições quentes (hot partitions). Para chaves sequenciais ou baseadas em timestamp, implemente prefixos aleatórios (sharding) ou use UUIDs para distribuir as escritas. Use a capacidade sob demanda (on-demand) para evitar o provisionamento, mas considere a capacidade provisionada com autoscaling para cargas de trabalho previsíveis e para aproveitar a capacidade adaptativa em partições quentes.

Notas práticas de configuração:

CLI para criar tabela: aws dynamodb create-table –table-name Events –attribute-definitions AttributeName=pk,AttributeType=S AttributeName=sk,AttributeType=S –key-schema AttributeName=pk,KeyType=HASH AttributeName=sk,KeyType=RANGE –billing-mode PAY_PER_REQUEST.
Use GSIs para padrões de acesso alternativos, habilite o TTL para expiração automática e use DynamoDB Streams + Lambda para padrões de captura de dados de alteração (change-data-capture).
Para cache de cargas de trabalho com leitura intensiva, adicione o DAX; para consultas complexas ou necessidades relacionais, escolha Aurora ou Redshift Spectrum dependendo da complexidade da consulta e das necessidades de consistência.

Critérios de decisão para seleção do mecanismo:

Use o DynamoDB para padrões de acesso previsíveis a uma única tabela e escala massiva com baixa latência.
Use o Redshift para análises complexas e OLAP em grande escala.
Use o Aurora para cargas de trabalho relacionais transacionais.

Armadilhas Comuns e Critérios de Decisão

Usar o S3 Standard-IA para dados acessados com frequência — o Standard-IA tem uma cobrança mínima de 30 dias; use o Standard ou o Intelligent-Tiering para objetos de curta duração ou acessados com frequência.
Esquecer que as permissões do Lake Formation sobrepõem as permissões do IAM para o S3 no Glue/Athena — conceda acesso tanto no Lake Formation quanto no S3 ao usar Glue/Athena e verifique as permissões efetivas no console do Lake Formation.
O comando COPY do Redshift requer uma IAM role anexada ao cluster, não apenas permissões de usuário — anexe uma IAM role com acesso ao S3 ao cluster e referencie seu ARN nas operações de COPY.
Partições quentes (hot partitions) no DynamoDB devido a chaves sequenciais — evite chaves monotônicas; use chaves com hash, prefixos aleatórios ou UUIDs e considere a capacidade sob demanda (on-demand) ou provisionada com autoscaling.
Habilitar o S3 Object Lock e o MFA Delete incorretamente — o Object Lock requer que o versionamento esteja habilitado e as permissões adequadas; o MFA Delete só pode ser habilitado/desabilitado usando a CLI com MFA e tem requisitos rigorosos de propriedade do bucket.
Transições de ciclo de vida inadequadas sem testar os custos e tempos de recuperação — teste os fluxos de trabalho de recuperação para as classes do Glacier para evitar latência e cobranças de recuperação inesperadas.

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

A Acme Media precisa armazenar 50 TB de ingestão de vídeo bruto, fornecer aos analistas acesso para consultar metadados transformados e impor acesso em nível de linha e coluna para diferentes unidades de negócio, minimizando o custo de armazenamento.

Ingerir o vídeo bruto no S3 usando multipart upload, marcar os objetos com a data de ingestão e o conjunto de dados, e usar o Intelligent-Tiering para padrões de acesso iniciais desconhecidos.
Configurar regras de ciclo de vida para transicionar a mídia para GLACIER ou DEEP_ARCHIVE após um período de retenção configurável (garantir o alinhamento de mais de 30 dias para o Standard-IA, se considerado).
Registrar os locais do S3 no Lake Formation, criar crawlers do Glue para popular o Data Catalog e conceder permissões em nível de linha e coluna baseadas em tags do LF para as unidades de negócio.
Armazenar metadados curados no Redshift RA3 para análise; anexar uma IAM role ao cluster para operações de COPY do S3 e usar as operações VACUUM/ANALYZE em janelas de manutenção.
Usar o DynamoDB com chaves UUID com hash para uma tabela de consulta de manifestos de vídeo de alta performance e habilitar a capacidade sob demanda (on-demand) para absorver picos de tráfego.

Justificativa: Esta abordagem isola o custo de armazenamento frio com as classes do Glacier, usa o Intelligent-Tiering para padrões desconhecidos, aplica o Lake Formation para controle de acesso seguro e granular entre os mecanismos de análise, e seleciona o RA3 para armazenamento analítico escalável, enquanto o DynamoDB lida com as consultas operacionais de baixa latência.

← Ingestão e Coleta de Dados · Todos os domínios · Catalogação de Dados e Gerenciamento de Metadados →

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