AWS Certified Data Engineer Associate
Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame DEA-C01 avalia. Leia de cima a baixo ou pule para uma seção.
Escolha um serviço Kinesis para ingestão de streaming.
Processamento controlado pelo consumidor em sub-segundos → Kinesis Data Streams. Entrega totalmente gerenciada para S3/Redshift/OpenSearch com conversão de formato opcional → Kinesis Data Firehose.
Por quê: O KDS retém registros (24h–365d) e suporta múltiplos consumidores. O Firehose não tem replay; troca replay por entrega zero-ops.
O stream atinge erros de ProvisionedThroughputExceeded durante o pico.
Refragmentar (Reshard). Cada shard suporta ingestão de 1 MB/s ou 1.000 registros/s, saída de 2 MB/s. Use chaves de partição uniformes; habilite Enhanced Fan-Out para >2 MB/s por consumidor.
Por quê: Chaves de partição "quentes" concentram o tráfego em um shard. Chaves aleatórias ou baseadas em hash distribuem a carga.
A carga de trabalho de streaming é irregular e imprevisível; o resharding manual é uma dor operacional.
Kinesis Data Streams no modo de capacidade sob demanda. Escala automaticamente para 200 MB/s por padrão; pague por volume de dados.
Múltiplos consumidores lendo o mesmo stream atingem o limite de leitura de 2 MB/s/shard.
Enhanced Fan-Out. Cada consumidor obtém 2 MB/s/shard dedicados via SubscribeToShard HTTP/2 baseado em push.
Maximize a taxa de transferência de ingestão do aplicativo produtor.
Kinesis Producer Library (KPL) com agregação + coleção. Agrupa múltiplos registros de usuário em um registro Kinesis de até 1 MB; reduz o custo de PUT.
Por quê: PutRecord de registro único é limitado por taxa e caro a 50k eventos/s. KPL agrega no lado do cliente.
Armazenar clickstream JSON no S3 como Parquet, particionado por tempo de evento.
Firehose com conversão de formato de registro (JSON → Parquet) usando tabela do Glue Data Catalog + particionamento dinâmico no timestamp do evento.
Por quê: Parquet + particionamento reduz drasticamente o custo de varredura do Athena. O particionamento dinâmico evita uma etapa ETL separada.
Alguns registros falham na transformação ou entrega do Firehose; é preciso capturá-los para replay.
Configure backup do S3 com `AllData` ou `FailedDataOnly`. Os registros com falha são enviados para o prefixo configurado com metadados de erro.
Garanta que não haja perda de dados no MSK se uma AZ de broker falhar.
Fator de replicação ≥ 3 em 3 AZs e `min.insync.replicas=2` com `acks=all` do produtor. Habilite Multi-AZ via KRaft sem ZooKeeper ou posicionamento de broker em 3 AZs.
Realize streaming do MSK para S3, OpenSearch ou RDS sem gerenciar um cluster Kafka Connect.
MSK Connect com conector gerenciado (Confluent S3 Sink, Debezium para CDC). Autoescala workers por WCU.
O tópico armazena a versão mais recente de um registro por chave; versões antigas podem ser descartadas.
Defina a política do tópico `cleanup.policy=compact`. O Kafka retém o valor mais recente para cada chave; registros mais antigos com a mesma chave são elegíveis para compactação.
Transferência semanal recorrente de 10 TB de NFS on-premise para S3 via Direct Connect.
AWS DataSync com agente on-premise + tarefa agendada. Verifica a integridade dos dados, suporta transferências incrementais, paralelo.
Por quê: O DataSync é mais rápido que o aws-cli sync e lida com limitação de largura de banda, novas tentativas e verificação nativamente.
Puxar dados de APIs SaaS (Salesforce, ServiceNow, Zendesk) para o S3 em um cronograma.
AWS AppFlow. Conectores gerenciados, OAuth tratado, agendado ou acionado por evento, grava Parquet no S3.
Replicar alterações contínuas de um SQL Server on-premise para Aurora MySQL com tempo de inatividade mínimo.
AWS DMS com carga completa + tarefa CDC. Use o Schema Conversion Tool (SCT) para conversão heterogênea de esquema/código antes do DMS.
Instância de replicação do DMS falha — a replicação é interrompida.
Habilite Multi-AZ na instância de replicação. Standby síncrono em outra AZ; failover automático.
Precisa de análises quase em tempo real em dados OLTP Aurora sem pipeline ETL.
Integração Aurora zero-ETL com Redshift. Replicação contínua de dados Aurora para Redshift; as consultas veem novos dados em segundos.
Por quê: Elimina pipelines DMS / Glue / CDC customizados para o caso de uso de OLTP para data warehouse.
Mover 100 TB de arquivo histórico de on-premise para S3; largura de banda limitada.
AWS Snowball Edge Storage Optimized. Dispositivo físico enviado ao local; copiar dados; enviar de volta.
O JSON de origem tem arrays aninhados; a análise relacional downstream precisa de linhas achatadas.
Transformação `Relationalize` do Glue PySpark (ou `explode()` em DataFrame) achata arrays aninhados em linhas/tabelas separadas.
O Glue Crawler infere tipos ambíguos (`choice<int,string>`) de dados CSV bagunçados.
Aplique a transformação `ResolveChoice` — converta para tipo específico ou projete para struct. Ou corrija na origem, aplicando o esquema.
O job ETL do Glue é executado por hora em dados S3 crescentes; precisa processar apenas novos arquivos.
Habilite os bookmarks de job do Glue. O Glue rastreia arquivos/partições processados e os ignora em novas execuções.
Por quê: Evita reprocessar todo o conjunto de dados. Necessário para pipelines ETL incrementais.
O job Spark do Glue falha com OutOfMemoryError no driver durante grandes agregações.
Mude para workers G.2X ou G.4X (mais memória do driver) ou habilite `--enable-glue-datacatalog` para reduzir dados embaralhados.
Execute Spark Structured Streaming contínuo contra uma fonte Kinesis com infraestrutura gerenciada.
Job ETL de streaming do AWS Glue. Spark Structured Streaming por trás dos panos; checkpointing para S3.
Um analista de negócios precisa limpar e transformar dados sem escrever código.
AWS Glue DataBrew. Transformações baseadas em receita visual (mais de 250), profiling, linhagem. Saída para S3, Redshift, RDS.
Execute o job ETL do Glue somente depois que o Crawler atualizar com sucesso o Data Catalog.
Fluxo de trabalho do Glue com gatilhos condicionais. Sucesso do Crawler → acionar job ETL. Falha → pular / alarme.
O Crawler infere todas as colunas CSV como `string` — precisa de tipos de data e número.
Adicione um classificador Glue personalizado (padrão Grok ou dica de coluna) antes do crawling. Alternativamente, pré-escreva uma linha de cabeçalho com tipos explícitos.
Múltiplos produtores/consumidores no Kafka precisam de evolução de esquema sem quebrar uns aos outros.
AWS Glue Schema Registry com regras de compatibilidade (BACKWARD/FORWARD/FULL). Produtores registram esquema; consumidores buscam + validam.
Escolha entre EMR e Glue para Spark ETL.
Spark personalizado de longa duração com ajuste profundo, múltiplos frameworks (Hive, Presto, Flink) → EMR. ETL serverless pago por job com integração Glue Data Catalog → Glue. Spark irregular/imprevisível → EMR Serverless.
Jobs Spark/Hive intermitentes; quer zero operações de cluster e nenhum recurso de computação ocioso.
EMR Serverless. Pools de capacidade pré-inicializados para inícios de baixa latência; escala por job; pague por vCPU-hora.
Misturar nós de core on-demand + nós de tarefa spot para EMR otimizado em custo.
Instance Fleets com capacidade alvo por tipo. Frota de core on-demand para estabilidade HDFS; frota de tarefas spot com tipos de instância diversificados.
Padronizar no Kubernetes; quer que os jobs Spark do EMR compartilhem o cluster com outras cargas de trabalho.
EMR on EKS. Spark é executado como pods no cluster EKS existente; compartilha infraestrutura e roles IAM via IRSA.
Streaming com estado com agregações em janelas e semântica de "exactly-once".
Kinesis Data Analytics for Apache Flink. Runtime Flink gerenciado; checkpoints para S3; autoescala.
Transformação leve por registro em um stream Kinesis (<1 ms cada).
Lambda com Event Source Mapping no KDS. Ajuste `BatchSize`, `MaximumBatchingWindowInSeconds` e `ParallelizationFactor`.
Por quê: Lambda é mais barato que KCL/Glue Streaming para trabalho pequeno por registro.
Um passo do Step Functions ocasionalmente falha devido a throttling transitório; retentar e depois alertar.
Adicione o bloco `Retry` com `ErrorEquals: ["Lambda.ThrottlingException", "States.TaskFailed"]`, `IntervalSeconds`, `MaxAttempts`, `BackoffRate=2`. Além de `Catch` para um estado de notificação.
Processar 500.000 arquivos JSON em paralelo através de transformação Lambda.
Estado de Map distribuído do Step Functions com `MaxConcurrency` e ItemReader do S3. Distribuição (Fan-out) em milhares de invocações Lambda paralelas.
DAG complexo com dependências entre serviços (Glue + Redshift COPY + Lambda + email) e requisitos de linhagem.
Amazon MWAA (Managed Workflows for Apache Airflow). Operadores Airflow nativos para serviços AWS; sincronização de DAGs via Git.
Precisa reverter as alterações do DAG se um deploy causar falhas.
Armazene DAGs em bucket S3 versionado + sincronize via versionamento S3. Ou mantenha o repositório DAG no Git com ambiente por branch + sincronização S3 via CI.
Dados brutos "quentes" por 30 dias, acesso ocasional pelos próximos 90 dias, arquivamento por 7 anos.
Ciclo de vida do S3: 0–30 dias Standard, transição aos 30 dias para Standard-IA, transição aos 120 dias para Glacier Flexible Retrieval, expirar após 7 anos.
Padrões de acesso imprevisíveis; política de ciclo de vida manual é a escolha errada.
S3 Intelligent-Tiering. Move automaticamente objetos entre Frequent / Infrequent / Archive Instant Access / Archive / Deep Archive com base no padrão de acesso. Taxa de monitoramento por objeto; sem taxas de recuperação em Frequent/IA.
Consultas Athena em data lake são lentas; a partição tem milhares de arquivos JSON de 1-5 KB.
Compacte arquivos pequenos via job Glue/EMR em arquivos Parquet de ~256 MB. Use `OPTIMIZE` do Iceberg ou compactação Hudi para formatos de tabela gerenciados.
Por quê: A sobrecarga por arquivo do Athena/Spark domina com arquivos pequenos. O ideal é Parquet de ~128–512 MB.
Um bucket; múltiplas equipes precisam de diferentes padrões de acesso com escopo de prefixo.
S3 Access Points — endpoint nomeado por equipe com sua própria política vinculada a um prefixo. Mais simples do que uma política de bucket gigante.
Diferentes consumidores precisam de diferentes visualizações do mesmo objeto S3 (PII redigido, resumido).
S3 Object Lambda Access Point. A solicitação GET invoca uma Lambda que transforma o objeto em tempo real; o consumidor vê a visualização transformada.
Precisa de transações ACID, evolução de esquema e time-travel em data lake S3.
Tabelas Apache Iceberg (Glue Catalog + armazenamento S3). Commits atômicos, MERGE/UPDATE/DELETE, isolamento de snapshot, evolução de partição.
Por quê: S3 "append-only" estilo Hive não suporta atualizações em nível de linha. Iceberg/Hudi/Delta resolvem isso.
Múltiplos escritores e leitores em uma tabela de data lake; precisa de consistência transacional e controle de acesso em nível de linha.
Tabelas governadas pelo Lake Formation (baseadas em Iceberg) com LF-Tags para permissões.
Athena, Redshift Spectrum, EMR e Glue ETL precisam de um armazenamento de metadados compartilhado.
AWS Glue Data Catalog. Um único metastore compatível com Hive consumido por todos os serviços de análise.
O cluster Redshift precisa escalar o armazenamento independentemente da computação.
Nós RA3 com armazenamento gerenciado (RMS). Armazenamento suportado por S3; a computação escala separadamente. Necessário para AQUA, Concurrency Scaling, Federated Queries.
A consulta Redshift filtra frequentemente por `created_at`; varreduras de tabela completa são lentas.
Defina uma chave de ordenação em `created_at` (ou uma chave de ordenação composta incluindo `created_at`). O Redshift usa mapas de zona para pular blocos durante a varredura.
Joins frequentes entre `orders` e `order_items`; shuffles de consulta causam lentidão.
Use a mesma DISTKEY (`order_id`) em ambas as tabelas. Linhas co-localizadas evitam o shuffle de rede durante o join.
Por quê: A distribuição KEY co-localiza linhas de junção no mesmo nó de computação.
Carregar 32 arquivos CSV gzip (~1 GB cada) em um cluster Redshift de 4 nós é lento.
COPY em paralelo a partir de um único manifesto. Procure por #arquivos = múltiplo da contagem de slices (slices = nós × vCPU). 4 nós ra3.xlplus = 8 slices → 32 arquivos = 4 por slice.
Unir 5 TB de dados Parquet "frios" no S3 com tabelas de fatos "quentes" do Redshift; não quer carregá-los.
Redshift Spectrum. Tabelas externas no Glue Catalog; consultas leem o S3 diretamente com a computação do Redshift.
Consultas da equipe de relatórios durante o pico desaceleram as cargas de trabalho ETL; ambas executam no mesmo cluster.
Habilite Concurrency Scaling na fila WLM relevante. O Redshift roteia transparentemente as consultas de estouro para clusters escalados.
A consulta do dashboard une repetidamente 3 tabelas grandes e agrega; a latência é alta.
View materializada com atualização automática. O Redshift mantém o resultado pré-computado; a consulta lê a partir dos dados materializados.
Carga de trabalho analítica intermitente; cluster provisionado fica ocioso.
Amazon Redshift Serverless. Auto-provisiona e escala RPUs por carga de trabalho; pague por RPU-hora. Zero ops.
Precisa unir dados do Redshift com dados Aurora MySQL em tempo real sem ETL.
Redshift Federated Queries. CRIE EXTERNAL SCHEMA apontando para Aurora; as consultas empurram predicados pela conexão RDS ativa.
O dashboard une pedidos + clientes + produtos em cada renderização; o esquema em estrela é muito lento.
Desnormalize para uma tabela de fatos ampla ou view materializada. Cargas de trabalho de BI favorecem joins em tempo de leitura resolvidos em tempo de escrita.
Partições S3 por `ano/mês/dia/hora`; `MSCK REPAIR TABLE` leva mais de 30 min.
Habilite a projeção de partição do Athena (sem entradas de partição do Glue Catalog). Defina os tipos e intervalos das chaves de partição nas propriedades da tabela.
Por quê: O Athena calcula as localizações das partições no momento da consulta a partir das regras de projeção — sem MSCK, sem limitação da API do Glue.
Converta os resultados da consulta Athena para Parquet, particionados, em uma única operação.
CREATE TABLE AS SELECT (CTAS) com `format=PARQUET`, `partitioned_by=ARRAY['region']`, `external_location` definido para o prefixo S3 de destino.
O mesmo modelo de consulta é executado com diferentes valores de parâmetro ao longo do dia.
Declarações preparadas do Athena: `PREPARE`, `EXECUTE` com valores de parâmetro. Evita a re-análise e oferece uma parametrização limpa.
Leituras de dispositivos IoT; precisa (1) de todas as leituras para um dispositivo em uma janela de tempo, (2) da leitura mais recente por dispositivo.
PK = `device_id`, SK = `timestamp`. GSI com PK = `device_id`, SK = `timestamp` invertido (ou use Query com `ScanIndexForward=false LIMIT 1`).
A tabela de sessões cresce sem limites; sessões antigas podem ser excluídas após 7 dias.
Habilite DynamoDB TTL em um atributo `expires_at` epoch. O DynamoDB remove itens expirados sem custo (em ~48h).
Dados de sensor IoT: consultas "quentes" nos últimos 7 dias, consultas ocasionais em 2 anos.
Amazon Timestream. Armazenamento em memória para dados recentes (consultas rápidas); auto-tiering para armazenamento magnético para históricos.
Armazenamento compatível com Cassandra para séries temporais de alta escrita com retenção de 90 dias.
Amazon Keyspaces com TTL em linhas. Compatível com Cassandra CQL; capacidade serverless, sem gerenciamento de cluster.
O custo de armazenamento do OpenSearch aumenta; índices antigos raramente consultados.
Políticas ISM do OpenSearch segmentam dados: quente → UltraWarm (com suporte S3) → Cold. O tier Cold é desanexado, mas pesquisável sob demanda.
Valide que a saída ETL tenha ≥1.000 linhas e taxa de nulos de coluna <2% antes do consumo downstream.
Regras de qualidade de dados do AWS Glue (DQDL): `RowCount >= 1000`, `Completeness "col" > 0.98`. O pipeline é interrompido em caso de falha da regra.
Framework de qualidade de dados baseado em Spark personalizado no EMR; precisa de verificações estatísticas em nível de coluna.
Biblioteca AWS Deequ no Spark. Defina restrições (`isComplete`, `hasMin`, `isContainedIn`); o Deequ é executado como um job Spark e emite métricas.
Analistas precisam descobrir, solicitar acesso e entender a linhagem de produtos de dados em várias contas.
Amazon DataZone. Catálogo de dados com glossário de negócios, fluxos de trabalho de acesso, linhagem; abrange Lake Formation, Redshift, RDS.
Lambda emite métricas de processamento por registro; os custos de CloudWatch PutMetricData são altos.
CloudWatch Embedded Metric Format (EMF). Registre JSON no esquema EMF; o CloudWatch extrai métricas de logs sem custo por PutMetricData.
Encontrar todos os jobs Glue cuja duração excedeu 1 hora nos últimos 7 dias.
Consulta do CloudWatch Logs Insights: `fields @timestamp, @message | filter @message like /JobRunDuration/ | parse @message "duration=*" as d | filter d > 3600`.
O job Glue está lento; é preciso saber se está com poucos recursos ou com shuffle enviesado.
Habilite métricas + observabilidade de job do Glue. O CloudWatch mostra o uso máximo de DPU, utilização do executor, leitura/escrita de shuffle por estágio.
Os tamanhos dos jobs Spark do Glue variam em 10× entre as execuções; superprovisionado para pequenas entradas.
Habilite o auto scaling do Glue (Glue 3.0+). Workers adicionados/removidos durante a execução com base no paralelismo do estágio.
O Athena varre 5 TB para responder a consultas que tocam um dia de dados; custo muito alto.
Particione por data e garanta que a cláusula WHERE use chaves de partição. Valide com `EXPLAIN` mostrando o particionamento de partição.
Consultas Athena em data lake JSON são lentas e caras.
Converta para Parquet (colunar) ou ORC. Lê apenas as colunas necessárias; a compressão nativa reduz o custo e o tempo de varredura.
Otimização de custo de cluster EMR sem risco de perda de dados.
Nós de core On-Demand (hospedam HDFS / shuffle). Nós de tarefa Spot via Instance Fleets com tipos de instância diversificados.
O cluster Redshift é executado 24/7; o preço on-demand é caro.
Redshift Reserved Nodes (1 ano ou 3 anos, pagamento total/parcial/sem adiantamento). Até ~75% de desconto em comparação com on-demand para cargas de trabalho de estado constante.
Escolha entre Athena, Redshift e EMR para 500 GB diários / 50 consultas.
Ad-hoc, infrequente → Athena (por TB escaneado). Dashboards de BI previsíveis → Redshift (RA3 + Reservados). Spark customizado pesado → EMR.
Por quê: O Athena cobra por dados escaneados; o Redshift cobra por hora de cluster; o EMR por hora de instância. Correlacione o faturamento com o padrão de acesso.
O job Glue é acionado várias vezes concorrentemente; quer limitar a uma execução por vez.
Defina `MaxConcurrentRuns=1` para o job Glue. Gatilhos subsequentes aguardam; elimina a corrupção de estado concorrente.
As retentativas do Glue ETL produzem linhas de saída duplicadas no destino S3.
Idempotência: escreva para um prefixo temporário por execução, depois renomeie atomicamente via S3 multipart `CompleteMultipartUpload` ou use MERGE de Iceberg/Hudi para upserts.
Uma execução ETL ruim escreveu linhas corrompidas para o Aurora MySQL; recuperar para um ponto no tempo minutos atrás.
Aurora Backtrack (somente compatível com MySQL). Retrocede o cluster para um tempo alvo sem restaurar de um snapshot.
O pipeline sobrescreveu objetos S3 corretos com dados corrompidos.
Versionamento de bucket S3 + restaurar versão anterior. Combine com MFA Delete para evitar expiração acidental de versão.
Automatizar a criação, retenção e cópia entre regiões de snapshots EBS para recuperação de desastres.
Amazon Data Lifecycle Manager (DLM) com política por tag: agendamento, retenção, cópia entre regiões.
Consumidores MSK ficam atrás dos produtores; é preciso detectar e alertar.
Métrica `MaxOffsetLag` do CloudWatch por grupo de consumidores. Alarme quando > limite; aumente a contagem de consumidores ou o paralelismo da partição.
Consumidor Kinesis ficando para trás; quer detectar.
Métrica `GetRecords.IteratorAgeMilliseconds` do CloudWatch. Alarme > 60s geralmente significa consumidores com poucos recursos.
Identificar as consultas Redshift mais lentas da última hora para ajuste.
Consulte `SVL_QLOG` / `STL_QUERY` / `SYS_QUERY_HISTORY` para as entradas de maior tempo decorrido; use `SVL_QUERY_REPORT` para detalhamento por etapa.
Equipes de vendas devem ver apenas as linhas de suas regiões atribuídas no data lake compartilhado.
Segurança em nível de linha do Lake Formation via filtro de dados: `region IN ('NA', 'EU')` por principal IAM. Tabela única; visualização filtrada por principal.
Tabela de saúde — analistas não devem ver as colunas SSN e de diagnóstico.
Permissões em nível de coluna do Lake Formation: GRANT SELECT na tabela EXCETO (`ssn`, `diagnosis_code`).
Muitas equipes + muitas tabelas; concessões por tabela são insustentáveis.
LF-Tags do Lake Formation. Marque tabelas/colunas; conceda permissões baseadas em tag a principais. Adicionar uma nova tabela apenas precisa da tag correta.
A Conta A tem o data lake; os analistas da Conta B precisam de acesso de leitura a tabelas específicas.
Compartilhamento entre contas do Lake Formation via RAM. A Conta A concede permissões ao principal/conta IAM da Conta B; B acessa via Athena/Redshift Spectrum.
Segurança em nível de linha dentro do Redshift (não Lake Formation).
Políticas RLS nativas do Redshift: `CREATE RLS POLICY` com predicado referenciando o contexto da sessão (`current_user`, `session_role`). Anexe a política à tabela.
A conformidade exige chave gerenciada pelo cliente com trilha de auditoria para criptografia do Redshift.
Cluster Redshift criptografado com chave KMS gerenciada pelo cliente. Rotação de chave habilitada; o CloudTrail captura cada operação de Decrypt contra a CMK.
Criptografar entradas/saídas do job Glue ETL com chave gerenciada pela empresa.
Configuração de Segurança do Glue com CMK para S3 + CloudWatch Logs + bookmarks de Job. Role do Glue com `kms:Decrypt`/`Encrypt` na chave.
Descobrir e classificar PII (nomes, SSNs, e-mails) presentes no data lake S3.
Amazon Macie. Descoberta de dados sensíveis baseada em ML no S3; produz descobertas com localização do objeto e tipo de PII.
Auditar cada GetObject / PutObject do S3 no bucket do data lake.
Eventos de dados do CloudTrail para o bucket. Por padrão, o CloudTrail registra apenas eventos de gerenciamento; eventos de dados devem ser habilitados explicitamente.
Por quê: Eventos de dados são cobrados por evento; restrinja apenas ao bucket sensível para controlar o custo.
Precisa de quem/quando/IP para cada acesso S3; eventos de dados do CloudTrail são muito caros.
Registro de acesso ao servidor S3. Gratuito; logs entregues a um bucket de log separado; menos detalhes que o CloudTrail, mas cobre solicitante + IP + caminho.
Impedir que qualquer bucket na conta seja acidentalmente tornado público, mesmo que uma política de bucket o permita.
Bloqueio de Acesso Público do S3 em nível de conta. Sobrescreve qualquer política em nível de bucket; aplicado como um guardrail.
Redshift na VPC deve ler do S3 sem passar pela internet pública.
S3 Gateway Endpoint na tabela de rotas da sub-rede do Redshift. O tráfego é roteado via backbone da AWS; sem NAT, sem IGW.
O job Glue ETL precisa acessar o RDS na sub-rede privada E chamar as APIs do Glue Data Catalog.
Conexão Glue na VPC do RDS + Interface VPC Endpoints para `glue.amazonaws.com` + S3 Gateway Endpoint.
O Glue ETL precisa de leitura S3, escrita Redshift, leitura Secrets Manager.
Única role de execução do Glue com políticas de menor privilégio: `s3:GetObject` no prefixo de origem, `redshift-data:ExecuteStatement`, `secretsmanager:GetSecretValue` no ARN do segredo específico.
Detectar padrões de acesso a dados incomuns — download grande por um usuário IAM sem acesso prévio ao data lake.
Proteção S3 do GuardDuty. Baselines comportamentais por principal IAM; descobertas sobre volumes/padrões de acesso anômalos.
A conformidade exige retenção WORM (write once, read many) em dados financeiros por 7 anos.
S3 Object Lock com modo Compliance + período de retenção de 7 anos. Nem mesmo o root pode excluir; atende a SEC 17a-4 / FINRA.
Coleta contínua de evidências de conformidade para auditorias HIPAA / SOC 2.
AWS Audit Manager com frameworks pré-construídos. Coleta automaticamente evidências do CloudTrail, Config, Security Hub; produz relatórios prontos para auditoria.
