Ciclo de Vida de Dados, Migração e Organização de Lago

Tarefa 2.3, "Gerenciar o ciclo de vida dos dados," é onde o engenheiro de dados para de ser construtor e vira guardião. A lista de conhecimentos da tarefa é deliberadamente sem glamour, soluções de armazenamento quente e frio, otimização de custo ao longo do ciclo de vida, exclusão guiada por requisitos de negócio e legais, políticas de retenção e estratégias de arquivo, proteção de resiliência, e suas habilidades são concretas: executar operações de carga e descarga entre Amazon S3 e Amazon Redshift, gerenciar políticas do S3 Lifecycle para mudar o tier de armazenamento, expirar dados com base na idade e gerenciar o versionamento do S3 e o TTL do DynamoDB. O exame, portanto, recompensa um hábito acima de todos os outros: saber exatamente o que acontece com um objeto específico, em um dia específico, a um preço específico.

Nesta lição você vai:

• ler uma regra do S3 Lifecycle como a AWS a define, ID, Status, Filter e os cinco tipos de ação, incluindo as peculiaridades de avaliação que decidem qual ação realmente roda;
• percorrer a cascata de transição de mão única e separar a idade mínima de transição (removida para as classes IA em 16 de julho de 2026) da duração mínima de armazenamento (30 / 90 / 180 dias, inalterada);
• aplicar o piso padrão de 128 KB, a aritmética de transições encadeadas e os filtros de tag, prefixo e tamanho;
• calcular dinheiro de ciclo de vida: taxas de requisição de transição, ponto de equilíbrio Standard versus IA, o precipício da duração mínima e uma comparação de classes de um ano (em outubro de 2026);
• separar expiração, expiração de versões não atuais, aborto de upload multipart e limpeza de delete markers, e explicar por que Expiration sozinho nunca encolhe um bucket versionado;
• operar versionamento, delete markers e MFA Delete, e nomear os pré-requisitos de replicação para CRR e SRR;
• aplicar os modos do S3 Object Lock (Compliance, Governance, legal hold) como restrição de ciclo de vida;
• configurar o TTL do DynamoDB, segundos de época, atraso de exclusão, comportamento de capacidade, e montar o pipeline de arquivamento TTL plus Streams;
• escolher uma classe Glacier pelo SLA de recuperação, não só pelo preço;
• escolher a ferramenta de migração certa: AWS DMS com conversão de schema (homogêneo versus heterogêneo), Snow Family, AWS DataSync e AWS Transfer Family;
• executar carga e descarga no Redshift do jeito que a primeira habilidade da Tarefa 2.3 exige;
• desenhar as zonas medallion bronze, silver e gold, corrigir o problema dos arquivos pequenos com compactação e catalogar cada zona separadamente;
• estudar quatro estudos de caso de clientes da AWS (Nasdaq, EOS Group, FINRA e BMW Group) e uma caixa de atualização de outubro de 2026 com fontes;
• praticar com 14 questões no estilo do exame mais quatro verificações interativas.

---

1. S3 Lifecycle: como uma regra é realmente construída

1.1 Uma configuração por bucket, 1.000 regras

Cada bucket do S3 carrega uma configuração de ciclo de vida contendo até 1.000 regras (uma cota fixa, em outubro de 2026). Uma regra é um objeto pequeno:

1.2 Os cinco tipos de ação

1.3 Filtros: prefixo, tags e tamanho

O Filter de uma regra delimita quais objetos ela pode tocar. O prefixo estreita para um caminho, as tags estreitam para objetos que carregam um par chave/valor (por exemplo tier=hot), e os predicados de tamanho estreitam objetos acima ou abaixo de um limiar em bytes. Duas regras para um mesmo bucket são comuns e legítimas, uma regra ampla de transição mais uma regra estreita guiada por tag, mas lembre de que os filtros são avaliados contra o objeto no momento da execução: remover a tag de um objeto normalmente impede que uma ação com escopo de tag se aplique a ele, embora a AWS documente que isso não é garantido, então um ciclo de vida guiado por tag nunca deve ser seu único controle de segurança.

• 📚 Você sabia? Duas ações de ciclo de vida são rotundamente confundidas porque ambas “removem” coisas: AbortIncompleteMultipartUpload é o único mecanismo que limpa uploads multipart incompletos, a expiração comum de objeto não os toca (AWS: “Object expiration lifecycle configurations don't remove incomplete multipart uploads”), enquanto ExpiredObjectDeleteMarker faz o trabalho oposto: ele exclui um marker que não está escondendo nada, então a versão anterior volta a ser a atual. Uma libera bytes abandonados, a outra desesconde dados que você ainda possui (documentação do S3 Lifecycle da AWS, acesso em outubro de 2026).

---

2. Transições: a cascata e os gates de idade

2.1 A cascata de mão única

As classes de armazenamento são uma encosta. Os objetos podem descer para uma classe abaixo da classe atual, nunca voltar o degrau na mesma hora:

Duas regras estruturais decorrem desse diagrama: Glacier Flexible Retrieval só pode ser reclassificado para Deep Archive, e Deep Archive não tem transição de saída nenhuma: escapar dele significa restaurar o objeto e copiá-lo para outro lugar, o que é uma operação de restauração mais armazenamento novo, não uma transição. Um status de replicação pendente ou com falha também bloqueia transições em buckets versionados, então uma regra de replicação quebrada congela silenciosamente seu plano de tiering.

2.2 Idade mínima de transição versus duração mínima de armazenamento: a mudança de 16 de julho de 2026

São dois números diferentes e o exame cobra a diferença:

A armadilha é que remover o gate de elegibilidade não fez nada com o piso de cobrança. Um objeto transicionado para Standard-IA no dia 0 e excluído no dia 7 ainda é cobrado por 30 dias de Standard-IA, porque a duração mínima de armazenamento é uma cobrança, não uma regra. Um material de estudo que ainda diz “você precisa esperar 30 dias antes de transicionar para IA” está desatualizado; um material que diz “sair da IA antes da hora é grátis” sempre esteve errado.

2.3 O piso de 128 KB

Desde setembro de 2024, objetos menores que 128 KB não são transicionados por padrão: um objeto abaixo de 128 KB configurado com uma transição simples baseada em Days simplesmente permanece em Standard, a menos que você opte com um filtro ObjectSizeGreaterThan ou com a configuração de nível de bucket x-amz-transition-default-minimum-object-size. Configurações legadas criadas antes dessa mudança mantêm o comportamento antigo até serem editadas. E o piso corta dois vezes: esses objetos pequenos também são cobrados pelo piso de 128 KB nas classes IA e Glacier Instant, então um bucket cheio de arquivos JSON de 20 KB paga mais por objeto do que sua contagem de bytes sugere (considerações de transição do S3 Lifecycle da AWS, acesso em outubro de 2026).

2.4 Transições encadeadas precisam respeitar as durações mínimas: Exemplo trabalhado E5

Uma única regra que pula por duas classes precisa sair de cada classe só depois que a duração mínima daquela classe tiver corrido. O exemplo da própria AWS afirma que você não pode especificar uma regra que transicione objetos para Glacier Instant Retrieval depois de 4 dias e depois para Deep Archive depois de 20 dias, o segundo salto deve ser depois de pelo menos 94 dias:

Duas regras separadas podem expressar a mesma intenção (o S3 não as rejeita), mas você paga de qualquer jeito a cobrança de duração mínima de cada classe: a restrição passa de “rejeitada na hora da configuração” para “cobrada na hora da fatura”.

3. Expiração: o que “excluir” significa, conforme o estado do versionamento

3.1 A mesma ação, três resultados diferentes

3.2 Versões não atuais: NoncurrentDays mais NewerNoncurrentVersions

O NoncurrentVersionExpiration dispara apenas quando ambas as condições são excedidas: a versão não atual é mais antiga que NoncurrentDays e está além das NewerNoncurrentVersions versões mais recentes que você escolhe reter (1 to 100). Essa é a diferença entre um bucket com trilha de auditoria e um bucket com uma fatura que só cresce: NewerNoncurrentVersions: 5 com NoncurrentDays: 30 significa “manter as cinco versões não atuais mais recentes por pelo menos 30 dias cada, depois purgá-las permanentemente”.

3.3 O par canônico de regras

Ler o que está escrito de volta é a habilidade sendo testada: objetos tier=hot sob events/ entram no Standard-IA imediatamente (Days: 0, legal desde 16 de julho de 2026), Glacier Instant no dia 90, Deep Archive no dia 365, a versão atual expira no dia 2555 (cerca de sete anos), as versões não atuais migram para IA depois de 30 dias e são purgadas assim que passarem de 30 dias e das cinco mais recentes, e os uploads multipart incompletos são abortados depois de sete dias. A regra de aborto não tem filtro de tag: é por isso que ela fica em sua própria regra com um filtro de prefixo vazio em vez de dentro do tier-down.

---

4. Matemática de custo de ciclo de vida: quatro exemplos resolvidos

Todos os preços abaixo são preços de lista do Amazon S3 para us-east-1, em outubro de 2026: sempre confira aws.amazon.com/s3/pricing/ para a sua Região antes de depender de um número.

4.1 A tabela de preços a partir da qual você constrói as respostas

Outros fatos de requisição da mesma página: PUT $0,005 por 1.000 (tier Standard), GET $0,0004 por 1.000, DELETE é grátis, o monitoramento do Intelligent-Tiering é $0,0025 por 1.000 objetos por mês, os arquivos de arquivo carregam um overhead de 40 KB por objeto (8 KB na taxa Standard mais 32 KB na taxa de arquivo), e sair de uma classe antes da duração mínima cobra a cobrança normal mais o resto proporcional.

4.2 Exemplo trabalhado E1: taxas de requisição de transição em escala

Você faz o tier de 1.000.000 objetos em uma execução noturna. A $0,01 por 1.000 requisições a taxa parece trivial até você multiplicar:

A lição não é o valor em dólares, é o golpe duplo em objetos pequenos: se esses 1.000.000 objetos tiverem 20 KB cada, a taxa de transição se aplica a todos e cada um passa a ser cobrado pelo piso de 128 KB na classe de destino: 6,4x seu tamanho real, 20.000.000 KB cobrados em vez de 3.125.000 KB.

4.3 Exemplo trabalhado E2: ponto de equilíbrio Standard versus Standard-IA

Com que idade viver em Standard-IA custa o mesmo que viver em Standard? Igual as duas cobranças para um GB mantido por L dias:

Então um objeto esperado para viver mais que cerca de 16 dias é mais barato em Standard-IA antes de qualquer recuperação ser considerada; menos que cerca de 16 dias ele deve ficar em Standard, ou usar Intelligent-Tiering, que não tem duração mínima e não cobra taxa de recuperação. A recuperação vira a aritmética de novo: o Standard-IA cobra $0,01/GB para ler, então um objeto lido 20 vezes por mês nunca vence só no armazenamento. (Aritmética derivada dos preços de lista da AWS S3, us-east-1, em outubro de 2026.)

4.4 Exemplo trabalhado E3, o precipício da duração mínima

Um terabyte (tratado aqui como 100.000 GB para a aritmética) transiciona para Standard-IA no dia 0 e é excluído no dia 7:

E o precipício não suaviza com o tempo: excluído no dia 1 em vez do dia 7, a conta do Standard-IA é idêntica ($1.250,00) enquanto um dia de Standard custa $76,67, uma diferença de 16x. A duração mínima de armazenamento é um piso fixo, não uma assinatura proporcional: o dia em que você transiciona define a fatura, não o dia em que você sai. (Aritmética derivada dos preços de lista da AWS S3, us-east-1, em outubro de 2026, não publicada pela AWS.)

4.5 Exemplo trabalhado E4: dez terabytes, um ano, cinco classes

Escale a última linha para 100 TB: Standard é $27.600 por ano contra $1.188 por ano do Deep Archive: uma diferença de 23x que é todo o argumento econômico das políticas de ciclo de vida. O que a tabela esconde é igualmente examinável: Flexible e Deep Archive acrescentam taxas de restauração mais uma cópia temporária em S3 Standard enquanto você lê, e cada salto acima acrescenta uma cobrança de requisição de transição.

Passe o mouse sobre qualquer barra para ler o número do Exemplo trabalhado E4: os mesmos 10 TB mantidos por doze meses custam $276,00 em Standard e $11,88 em Deep Archive: uma aritmética só de armazenamento que deliberadamente exclui taxas de restauração, cobranças de requisição de transição e os precipícios de duração mínima, tudo o que o exame pode acrescentar por cima.

• 📚 Você sabia? A retrospectativa de 20 anos do S3 pela própria AWS (13 de março de 2026) relata que os clientes economizaram mais de US$ 6 bilhões em custos de armazenamento usando S3 Intelligent-Tiering em vez de S3 Standard, e coloca o preço de destaque de armazenamento em pouco mais de 2 centavos por gigabyte, cerca de 85% abaixo do preço de lançamento de 2006 de 15 centavos (em outubro de 2026, verifique a precificação atual antes de usar). A própria economia do Intelligent-Tiering é sutil: ele não tem duração mínima nem taxa de recuperação, mas cobra $0,0025 por 1.000 objetos por mês para monitorá-los, para 10 milhões de objetos pequenos, só essa linha de monitoramento é $25 por mês, e é por isso que filtros de tamanho e regras de ciclo de vida ainda batem o tiering automático em buckets com muitos objetos.

---

5. Versionamento, delete markers e MFA Delete

5.1 O que realmente acontece em cada chamada de API

Cada PUT atribui um version ID único; o bucket guarda uma versão atual mais qualquer número de versões não atuais. Um DELETE sem versionId insere um delete marker, tornando a versão anterior não atual: o GET retorna 404 enquanto os bytes estão totalmente intactos e ainda são cobrados. A remoção permanente exige DELETE ?versionId=..., e excluir o próprio marker restaura a versão anterior.

5.2 MFA Delete

O efeito líquido é o ponto da feature: com o MFA Delete ligado, um atacante com permissões normais de exclusão pode esconder dados mas não pode destruí-los, e só um root autenticado por MFA pode purgar versões ou suspender o versionamento.

• 📚 Você sabia? MFA Delete e versionamento respondem perguntas diferentes e são frequentemente confundidos: versionamento é um comportamento de armazenamento (manter cada versão), MFA Delete é um controle de destruição (tornar a destruição cara). Você pode rodar o versionamento por anos sem MFA Delete, e habilitar o MFA Delete não muda o que um DELETE faz: ele muda quem pode fazer aquela exclusão permanente (documentação de Versioning e MFA Delete do S3 da AWS, acesso em outubro de 2026).

---

6. Replicação: pré-requisitos de CRR e SRR

Replicação copia objetos entre buckets; regras de ciclo de vida movem objetos dentro de um bucket. Manter esses dois mecanismos separados é metade das questões de ciclo de vida do Domínio 2.

O S3 Replication Time Control (RTC) carrega um SLA: 99,99% dos objetos novos replicados em 15 minutos. Sem RTC, a replicação é melhor esforço sem SLA (a AWS documenta 24 to 48 horas como expectativa geral). O RTC é a resposta sempre que uma questão nomear um prazo de replicação; “eventualmente” não é nível de serviço.

---

7. S3 Object Lock: retenção que o ciclo de vida não pode anular

O Object Lock é uma feature do serviço Amazon S3 que está no escopo: ele não é uma entrada separada na lista de serviços no escopo do DEA-C01, e nenhuma declaração de tarefa nomeia WORM explicitamente, então trate-o como jogo justo exatamente porque o próprio S3 está no escopo. Ele precisa ser habilitado na criação do bucket, e habilitá-lo implica versionamento.

A retenção se conecta às versões de objeto; delete markers nunca são protegidos por WORM; uma política de bucket pode elevar a retenção máxima para 100 anos; e um Expiration de ciclo de vida não pode excluir uma versão sob retenção ou legal hold: que é exatamente por que arquivos regulados combinam Object Lock com tiering de ciclo de vida em vez de escolher um dos dois. Os ganchos regulatórios nomeados são SEC 17a-4, FINRA 4511 e CFTC 1.31.

8. TTL do DynamoDB: segundos de época, atraso de exclusão e o pipeline de arquivamento

8.1 O contrato do atributo

O TTL é habilitado por tabela e lê um único atributo, o nome é sensível a maiúsculas/minúsculas, cujo valor deve ser um Number contendo tempo Unix em segundos:

8.2 Atraso de exclusão: “em até dois dias”

A referência de API da AWS afirma que o DynamoDB “tipicamente exclui itens expirados em até dois dias” e avisa que “itens que expiraram e não foram excluídos ainda aparecem em leituras, consultas e scans” (em outubro de 2026). Três consequências disso:

1. O TTL não é uma exclusão de conformidade. Se uma regulação exigir apagamento instantâneo, só o TTL não satisfaz.
2. As leituras precisam filtrar. Acrescente FilterExpression: "ttl > :now" ou proteja as escritas com uma ConditionExpression até a exclusão acontecer.
3. O armazenamento continua sendo cobrado por até 48 horas após a expiração nominal.

8.3 Exemplo trabalhado E6: transformando uma política de retenção em época

Um dispositivo se registra em 1770000000 (segundos de época) e a política diz “excluir 90 dias após a criação”:

A distractor clássica do exame é um timestamp em milissegundos: ele faz parse como Number, então nada dá erro, o item simplesmente nunca é excluído, silenciosamente. O mesmo tipo de falha silenciosa vale para um nome de atributo digitado errado, porque a busca é sensível a maiúsculas/minúsculas.

8.4 TTL mais Streams: o pipeline de arquivamento

As exclusões do TTL são observáveis antes de estarem completas, e é isso que faz o padrão de arquivo funcionar:

Como as exclusões do TTL são executadas pelo serviço, os registros do stream carregam userIdentity.type = "Service" e principalId = "dynamodb.amazonaws.com"; um filtro de origem de evento naquela identidade derruba todo o resto. A orientação da AWS mostra o efeito prático: filtrar pode cortar as invocações do Lambda de cerca de 2 milhões de modificações por hora para 100.000 por hora, e o Lambda processando um stream do DynamoDB não é cobrado por GetRecords. Duas restrições importam para o exame: as exclusões do TTL são identificáveis apenas na Região onde ocorreram, e os Streams retêm 24 horas, então um consumidor quebrado precisa ser reparado dentro de um dia, não de uma semana. Dashboards construídos sobre esse padrão precisam tolerar até 48 horas de visibilidade pós-expiração.

• 📚 Você sabia? O padrão de arquivo existe porque o TTL te dá exclusão barata mas nenhuma cópia durável: o item sai do DynamoDB de graça, mas se ninguém capturou o registro do stream antes, sete anos de histórico simplesmente desaparecem. Capturar o evento de exclusão (ou a imagem final do item) no S3 antes da janela de dois dias fechar, e depois aplicar uma regra de ciclo de vida do S3 para fazê-lo subir de tier, transforma uma purga em um arquivo, e o custo de invocação do Lambda é a única linha nova na fatura (orientação de TTL do DynamoDB com DynamoDB Streams da AWS, acesso em outubro de 2026).

---

9. Escolha de arquivo: escolha pelo SLA de recuperação, não pelo preço

Restaurar custa a taxa de recuperação do arquivo mais uma cópia temporária em S3 Standard enquanto a cópia restaurada existir: um arquivo é barato de manter e deliberadamente caro de ler. A AWS documenta uma taxa de restauração de cerca de 1 to 2 PB por dia por conta. O S3 Intelligent-Tiering oferece um caminho adjacente: as recuperações Standard e Bulk de sua camada Archive Access (depois de 90 dias sem acesso) e de sua camada Deep Archive Access (depois de 180 dias) são gratuitas.

9.1 Exemplo trabalhado E7: durações mínimas quando você sai cedo

Exclusão antecipada (e sobrescrita antecipada) antes da duração mínima cobra a cobrança normal mais o resto proporcional: a mesma cláusula que faz o precipício do Standard-IA do Exemplo E3 funcionar. E lembre da saída de emergência: o Deep Archive é de mão única dentro da cascata de ciclo de vida; trazer um objeto de volta para o Standard exige RestoreObject e depois CopyObject.

---

10. Ferramentas de migração I: AWS DMS e conversão de schema

10.1 Homogêneo versus heterogêneo

O AWS Database Migration Service move bancos de dados, nada além disso. Suas duas formas são a primeira bifurcação do exame:

Duas features do DMS decidem se a conversão é sequer necessária: a change data capture (CDC) lê os logs de transação nativos da origem (então não são necessárias mudanças de aplicação para a sincronização contínua), e a conversão de schema reescreve DDL, procedimentos armazenados, funções e SQL embarcado para o motor de destino.

10.2 Tipos de tarefa e as ressalvas operacionais

Ressalvas que valem decorrer: o DMS roda em uma replication instance (Multi-AZ opcional) ou como DMS Serverless; a AWS afirma claramente que “a CDC do AWS DMS não fornece replicação em tempo real … Não existem SLAs para a latência da CDC”, então uma questão prometendo replicação “instantânea e garantida” via CDC está errada.

10.3 O fluxo heterogêneo

10.4 A questão do status do SCT (guia do exame v1.1)

O AWS Schema Conversion Tool baixável varria o código de aplicação em busca de SQL embarcado e suportava mais motores que seu sucessor gerenciado. A partir do guia do exame v1.1 (12 de dezembro de 2025), porém, o AWS SCT foi removido da lista de serviços no escopo do DEA-C01, o DMS Schema Conversion gerenciado (baseado na web, construído sobre o engine do SCT) é o que o guia agora aponta. Regra prática para o dia do exame: “SCT” ainda pode aparecer como vocabulário legado dentro de uma narrativa de conversão, mas ele não pode mais ser o serviço no escopo nomeado que lhe pedem para selecionar; prefira AWS DMS e DMS Schema Conversion (página de revisões do guia do exame, acesso em outubro de 2026).

• 📚 Você sabia? Uma janela de CDC do DMS de vários meses é uma conta de compute, não só uma escolha de arquitetura: desde 2 de dezembro de 2025, os AWS Database Savings Plans cobrem Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream e AWS DMS com descontos de até 35% (anúncio dos AWS Database Savings Plans, 2 de dez de 2025; acesso em outubro de 2026). Então quando um estudo de caso como o da EOS Group relata uma redução de 50% em infraestrutura, parte dessa história é o mecanismo de migração (DMS → S3 → Redshift) e parte é a alavanca comercial sobre os bancos de dados que restam: uma questão do Domínio 2 sobre “minimizar o custo de uma replicação de longa duração” pode legitimamente ser respondida com um desconto por compromisso em vez de uma mudança de arquitetura.

11. Ferramentas de migração II: Snow Family, DataSync e Transfer Family

11.1 Os três movers que não são de banco de dados

11.2 Exemplo trabalhado E8: a regra da semana, calculada

Mover 600 TB por um link de 1 Gbps, ignorando overhead de protocolo:

Tudo que levar mais de cerca de uma semana de transferência online sustentada pertence à conversa offline: para clientes da AWS que ainda podem pedir dispositivos, isso é a Snow Family, e o banner da documentação do Snowball direciona clientes novos para AWS DataSync, AWS Data Transfer Terminal ou soluções de parceiros da AWS. Para movimentação recorrente (um job noturno de 2 TB de NFS para S3 sobre Direct Connect) a resposta é sempre DataSync, e para depósitos de arquivos de fornecedores via SFTP é sempre Transfer Family.

---

12. Carga e descarga no Redshift: a primeira habilidade da Tarefa 2.3

A lista de habilidades da Tarefa 2.3 abre com “executar operações de carga e descarga entre Amazon S3 e Amazon Redshift”, e a AWS é direta sobre qual direção está correta: “recomendamos fortemente usar o comando COPY para carregar grandes volumes de dados. Usar instruções INSERT individuais … pode ser proibitivamente lento.”

A orientação da própria AWS para o UNLOAD relata o Parquet como “up to 2x faster … 6x less storage” em relação ao texto, o mesmo argumento da escolha de formato do lago, chegando pelo lado do warehouse. O pareamento a decorar: COPY para dentro, UNLOAD para fora, ambos pelo S3, ambos cientes da Região.

---

13. Organização do data lake: zonas medallion, arquivos pequenos e catalogação

13.1 As três zonas

Um layout medallion dá a cada zona um contrato diferente e, portanto, um ciclo de vida, uma classe de armazenamento e uma entrada de catálogo diferentes:

13.2 Catalogue cada zona separadamente

MSCK REPAIR TABLE varre uma árvore de prefixos inteira, então registrar bronze, silver e gold sob uma raiz com uma única instrução de repair arrisca misturar tabelas sem relação em um único objeto de catálogo. Catalogue cada zona em seu próprio database do Glue (ou em seu próprio namespace de S3 Tables / Iceberg) com seu próprio Location, e prefira ALTER TABLE ADD PARTITION quando você já sabe quais partições mudaram: a varredura de caminho completo é o padrão caro, não o padrão seguro.

13.3 Arquivos pequenos e o loop de compactação

A orientação do Athena da AWS enuncia o problema sem rodeios: “conjuntos de dados que consistem em muitos arquivos pequenos resultam em desempenho de consulta ruim no geral”, e a meta é no máximo 1.000 arquivos por partição. Um job do Glue rodando de hora em hora escrevendo arquivos de 3 MB produz 720 arquivos por dia por partição: passando do limite antes do almoço.

Ordem de correção (faça em sequência, não em paralelo):

1. Faça a origem escrever arquivos maiores (coalesce em direção a 256 to 512 MB).
2. Combine com Glue ETL (coalesce ou repartition).
3. Reduza o número de chaves de partição: super-particionar fragmenta os dados tão eficazmente quanto escritas pequenas.

Compactação gerenciada (o otimizador do Glue para Iceberg/Parquet) dispara quando uma tabela tem mais de 100 arquivos com cada arquivo abaixo de 75% do tamanho alvo, onde write.target-file-size-bytes tem padrão de 512 MB; a mesma família de otimizadores também oferece otimizadores de retenção de snapshot e de arquivos órfãos. Layouts que não são Iceberg precisam de uma reescrita Glue/Spark (bin-packing ou repartition). Para formatos, aponte para blocos Parquet de cerca de 128 MB ou stripes ORC de cerca de 64 MB, e empurre chaves de alta cardinalidade para bucketing em vez de mais níveis de partição.

13.4 Exemplo trabalhado E9, o que o ciclo de vida de uma zona bronze realmente rende

Uma zona bronze guarda 10 TB de dados de eventos com este conjunto de regras (todos os preços us-east-1, em outubro de 2026): Standard nos primeiros 30 dias, Standard-IA dos dias 31 to 180, Glacier Instant dos dias 181 to 365, expiração no dia 365. Aproximando cada janela como uma fração de um ano:

As taxas de transição são $1,20 contra uma economia de $185: todo o argumento das políticas de ciclo de vida em uma linha: em stores de objetos, a classe de armazenamento domina, as taxas de requisição são erros de arredondamento, e os mínimos de exclusão antecipada são a única armadilha real (aritmética derivada dos preços de lista da AWS S3, em outubro de 2026).

• 📚 Você sabia? Particionamento, bucketing e tamanho de arquivo são três eliminações diferentes e o exame as mantém separadas: partições podam diretórios (year=2026/month=10/ no estilo Hive), bucketing poda buckets de hash dentro de uma partição (o lugar certo para chaves de alta cardinalidade), e tamanho de arquivo conserta o imposto de listagem: super-particionar fragmenta os dados tão mal quanto escrever arquivos minúsculos, e é por isso que a orientação da AWS diz para particionar por colunas de baixa cardinalidade que as consultas realmente filtram, geralmente o tempo (orientação de particionamento e desempenho do Amazon Athena, acesso em outubro de 2026).

Atualizações de 2026 (em outubro de 2026)

Casos Reais

Todos os números abaixo são afirmações de clientes ou da AWS, não auditadas, com a fonte nomeada para você conferir. O ponto examinável é o padrão, qual mecanismo de ciclo de vida, controle de retenção ou ferramenta de migração fez o trabalho, não o marketing.

Caso A, Nasdaq: um lago S3 com Glacier e Object Lock

“Conseguimos suportar com facilidade o salto de 30 bilhões para 70 bilhões de registros por dia por causa da flexibilidade e da escalabilidade do Amazon S3 e do Amazon Redshift.”: Robert Hunt, VP de Engenharia de Software, Nasdaq

Leia como uma pilha de ciclo de vida, não como uma exibição de escala: S3 como caminho de escrita, Glacier para o arquivo, Object Lock para a retenção, Redshift e Spectrum para o caminho de leitura. É exatamente por que “copie os dados para o warehouse e apague o lago” é uma distractor, o lago segue sendo a fonte autoritativa, e a retenção é imposta por uma política WORM de nível de bucket em vez de por alguém lembrando de manter os backups.

Caso B, EOS Group: migração de warehouse liderada pelo DMS

“Ao eliminar a necessidade de infraestrutura on-premises, a EOS Group alcançou uma redução de 50% nos custos de infraestrutura …”

O detalhe examinável é a sequência: o DMS aterrissa o banco de dados, o S3 é a camada de staging, o Redshift carrega do S3: a mesma forma do caminho de escrita do Caso A, chegada pelo lado da migração. “O DMS grava direto no warehouse e isso é a migração inteira” é a distractor; fazer staging pelo S3 é o que torna a carga repetível e permite que regras de ciclo de vida gerenciem os dados pousados depois.

Caso C, FINRA: um lago S3 regulado em escala de vigilância

“A FINRA processa aproximadamente 6 terabytes de dados e 37 bilhões de registros em um dia médio … Em dias movimentados, as bolsas de valores podem gerar mais de 75 bilhões de registros.”: John Brady, VP de Cyber Security/CISO, FINRA

Leia a FINRA como o caso de separação de custo e retenção: o S3 guarda a cópia durável e gerenciada por ciclo de vida (centenas de milhões de objetos que precisam envelhecer para classes mais baratas e permanecer defensáveis para reguladores), enquanto EMR e Redshift são computação alugada que pode ser redimensionada ou aposentada sem tocar no arquivo. A distractor a rejeitar é “compre um warehouse maior de cara”, o resultado publicado da FINRA é o oposto, e o padrão é idêntico ao da Nasdaq, só com um regulador em vez de um prazo de bolsa como força motriz.

Caso D, BMW Group: um lago on-premises substituído por zonas S3 e o catálogo do Glue

O detalhe examinável é a postura no catálogo: os dados de cada camada vivem no S3, mas os schemas são registrados por zona no Glue Data Catalog: exatamente a regra de “catalogar cada zona separadamente” da Seção 13 desta lição. Quando uma questão descreve produtores escrevendo pelo Firehose em zonas do S3 que os consumidores consultam com Athena, ela está descrevendo a arquitetura publicada da BMW; a alternativa errada é sempre a que ignora o catálogo ou mescla todas as zonas em uma única árvore de prefixos sem gestão.

• 📚 Você sabia? Os volumes publicados da FINRA fazem um ótimo exercício de aritmética derivada que você pode fazer de cabeça: 37 bilhões de registros ÷ 86.400 segundos ≈ 428.000 registros/segundo em um dia típico, e 75 bilhões ≈ 868.000 registros/segundo em um dia movimentado (derivado dos totais publicados pela AWS: rotule como sua própria aritmética, nunca cite como número da AWS). É essa taxa sustentada que explica por que a resposta da FINRA nunca foi um único warehouse maior: nessa escala você precisa de uma camada de armazenamento (S3) cujas curvas de ciclo de vida e custo são independentes de qualquer motor de consulta que você alugue neste trimestre (material de caso da AWS, acesso em outubro de 2026).

• 📚 Você sabia? Os dois estudos de caso convergem para o Amazon S3 como pivô do ciclo de vida: a Nasdaq escreve lá e arquiva de lá, a EOS faz staging lá antes do Redshift ler de lá. Essa repetição é a dica do exame: quando uma questão do Domínio 2 precisa de um lugar onde retenção, tiering, replicação e catalogação possam ser aplicados aos mesmos bytes, a resposta quase sempre é S3 mais uma regra de ciclo de vida, com o TTL do DynamoDB como resposta paralela para expiração em nível de item em uma loja NoSQL (estudos de caso da AWS, acesso em outubro de 2026).

Perguntas de Prática (Practice Questions)

Veredito Comparativo: como este tópico se compara no dia do exame

• Verso outras nuvens: o guia DEA-C01 testa apenas serviços da AWS: Amazon S3 e S3 Glacier, Amazon DynamoDB, AWS DMS, AWS DataSync, AWS Snow Family, AWS Transfer Family, Amazon Redshift, AWS Glue. Nada no guia compara a AWS com outro provedor, então qualquer alternativa que pivote para o tiering, o arquivo ou a migração de um concorrente está fora de escopo por construção; responda com um serviço da AWS no escopo ou com uma regra publicada pela AWS (durações mínimas, SLAs de recuperação, atraso de exclusão).
• Verso autogerenciado / on-premises: você pode construir a automação de ciclo de vida você mesmo com jobs cron e scripts, mas aí você é dono dos retries, das falhas parciais, da evidência de auditoria e da garantia de retenção. A preferência do exame é o controle declarativo e gerenciado: regras de ciclo de vida para classes de armazenamento, TTL para expiração de itens, Object Lock para WORM, DMS para movimentação de banco de dados. Escolha a alternativa com menos trabalho operacional não diferenciado, e note que on-premises ainda é a resposta correta sempre que o cenário exigir explicitamente permanecer no local (um site desconectado, uma barreira legal de residência de dados).
• Verso outro serviço da AWS fazendo um trabalho vizinho: o ciclo de vida move objetos dentro de um bucket; a replicação copia objetos entre buckets; o Object Lock bloqueia exclusões; o TTL expira itens do DynamoDB; o DataSync sincroniza arquivos; o Transfer Family expõe um protocolo; o DMS move bancos de dados; o Glue compacta arquivos do lago. Uma questão perguntando “como parar de pagar pelos dados do ano passado” nunca responde “replicação”, e uma perguntando “como garantir uma cópia de 15 minutos para outra Região” nunca responde “ciclo de vida”: essas são RTC e tiering, respectivamente.
• Verso um processo manual e humano: a retenção WORM da Nasdaq e a migração em estágios do DMS da EOS são resultados de mecanismos (Object Lock, regras de ciclo de vida, DMS para S3 para Redshift), não de um engenheiro lembrando de excluir ou arquivar. No exame, prefira a alternativa que codifica a política sobre a alternativa que depende de alguém lembrar dela, e trate toda porcentagem publicada como “o cliente alcançou”, nunca como “a AWS garante”.