S3 como Fundação do Data Lake: Classes de Armazenamento, Glacier e Durabilidade

Todo lakehouse deste curso se apoia em uma premissa: Amazon S3 é o substrato. O Glue rastreia ele, o Athena varre ele, o Redshift Spectrum monta ele, o Lake Formation concede sobre ele, o Macie inspeciona ele, o QuickSight lê ele. Nada a jusante salva um lake cuja camada de armazenamento foi desenhada por acidente, e no S3, "por acidente" tem um preço definido. A classe de armazenamento errada te cobra uma taxa de recuperação em cada byte que um motor lê; o layout de prefixo errado engasga a ingestão em 3,500 escritas por segundo; o tamanho de objeto errado adiciona 40 KB de metadados de arquivo por arquivo; o desenho de retenção errado transforma uma regra de ciclo de vida em uma porta de mão única com uma fatura mínima de 180 dias.

A boa notícia é que o modelo de custo do S3 é conhecível. Toda taxa desta lição vem da oferta do AWS Price List para Amazon S3 em us-east-1 (data de publicação 2026-09-28, vigência 2026-09-01, acesso em outubro de 2026), mais o user guide do S3, a página de preços e o FAQ da AWS (acessados em outubro de 2026). Faça a aritmética você mesmo; é a única maneira de desenhar um lake que ainda seja acessível no sétimo ano.

Nesta lição você vai:

• ler a tabela completa de classes de armazenamento: as oito classes mais cada tier do Glacier, com tempo de recuperação, taxa de recuperação e duração mínima de armazenamento;
• percorrer a árvore de decisão de classes de armazenamento e a cascata de ciclo de vida de mão única como diagramas mermaid, e depois ordenar a cascata você mesmo em um drag-and-drop interativo;
• modelar versionamento, replicação, Object Lock (WORM) e legal holds, incluindo exatamente quais mutações a replicação não espelha;
• escolher entre SSE-S3, SSE-KMS, DSSE-KMS e SSE-C, e usar um S3 Bucket Key para reduzir o custo de requisições do KMS "em até 99 por cento";
• desenhar buckets, prefixos e chaves de partição no estilo Hive contra o modelo de ≥3,500 requisições de escrita / ≥5,500 de leitura por segundo por prefixo;
• aplicar Block Public Access (quatro configurações) e os oito padrões de bucket policy que um lake privado precisa;
• construir o plumbing de governança, S3 Inventory e S3 Batch Operations, que regras de ciclo de vida e replicação ao vivo não fazem sozinhas;
• calcular à mão cinco modelos de custo com números reais: a escada de classes de 1 TiB, um restore de Deep Archive de 50 TiB, um desenho de throughput de prefixo quente, um TCO de 7 anos de ciclo de vida até Deep Archive, um break-even de Intelligent-Tiering e a armadilha dos 40 KB de metadados de arquivo;
• estudar dois casos nomeados de clientes da AWS (Nasdaq e Siemens), ler a caixa de atualizações de 2026 e praticar com 12 questões no estilo de exame mais quatro verificações interativas.

---

1. As oito classes: uma durabilidade, oito economias

1.1 A tabela comparativa (em out 2026)

Amazon S3 oferece oito classes de armazenamento atuais mais uma classe descontinuada. A AWS documenta as duas lado a lado na comparação de classes de armazenamento do user guide do S3 (acesso em out 2026). Todas compartilham durabilidade projetada de 99.999999999%, onze nines, então durabilidade nunca é o discriminador. O que discrimina é disponibilidade projetada, footprint de AZ, duração mínima de armazenamento, tamanho mínimo faturável de objeto e taxas de recuperação.

Três detalhes dessa tabela causam mais dano do que qualquer outro:

1. S3 Express One Zone é uma classe de directory buckets. Ela vive em um tipo de bucket diferente (--bucket-prefix directory buckets), é de uma única AZ e custa $0.11/GB-mês, cerca de 4.8× o armazenamento do S3 Standard, em troca de latência consistente de dígitos únicos de milissegundo. É um tier de serving/scratch, nunca o lake de registro.
2. Intelligent-Tiering não tem taxa de recuperação nenhuma. Ele troca essa taxa por uma cobrança de monitoramento por objeto: $0.0025 por 1,000 objetos por mês (oferta do AWS Price List, 2026-09-28). Objetos menores que 128 KB não são monitorados e não pagam taxa, o que é ao mesmo tempo uma armadilha e uma dica (seção 10).
3. As três classes Glacier não são "S3 mais lento." Duas delas (Flexible Retrieval, Deep Archive) não podem ser lidas com GetObject de modo algum até que você execute um restore assíncrono. Esse único fato driveia todo desenho de arquivo deste curso.

1.2 Exemplo resolvido E1: a escada mensal de 1 TiB

Em out 2026 (lista us-east-1). Quanto custa simplesmente manter 1 TiB = 1,024 GB por um mês em cada classe?

Duas leituras dessa escada importam. Primeiro, Deep Archive é 23× mais barato que Standard para manter ($1.014 vs$23.552), e é exatamente por isso que o tier de arquivo é uma decisão de retenção, não de desempenho. Segundo, Express One Zone é 4.8× mais caro que Standard para manter, e é por isso que ele hospeda tabelas gold de serving e feature stores de ML, nunca bronze.

O FAQ do S3 diz isso sem rodeios: "From just $0.00099 per GB-month … S3 Glacier Deep Archive offers the lowest cost storage in the cloud" (acesso em out 2026). Uma ressalva que vale carregar: a oferta do AWS Price List de us-east-1 de 2026-09-28 contém os SKUs de staging do Deep Archive e de Intelligent-Tiering Deep Archive Access, mas nenhum SKU standalone de armazenamento Deep Archive, então trate $0.00099 como publicado pela AWS, e não confirmado pela lista de preços, e verifique de novo antes de comprometer um arquivo de sete dígitos com ele.

• 📚 Você sabia? Reduced Redundancy (RRS) ainda aparece na lista de preços do S3 a $0.0240→0.0220/GB-mês, mas o user guide do S3 diz apenas: "Não recomendamos o uso dessa classe de armazenamento" (acesso em out 2026). Ele é mais caro que o S3 Standard com menos redundância. Qualquer alternativa de estilo de exame, deck de fornecedor ou runbook legado que ainda roteie dados para o RRS está errado em out 2026.

---

2. A família Glacier: cada tier, cada taxa, cada relógio

"Glacier" são três classes de armazenamento e cinco tiers de restore, e a diferença entre elas é a diferença entre uma query que retorna em milissegundos e um ticket que fecha amanhã.

2.1 A tabela de arquivo

Fontes: comparação de storage classes do S3 Glacier e bullets dos tiers (user guide, acesso em out 2026); preços de recuperação e de requisição de restore da oferta us-east-1 de 2026-09-28; "S3 Glacier Flexible Retrieval Bulk data retrievals and requests are free of charge" e "As requisições DELETE e CANCEL são gratuitas" (página de preços do S3, acesso em out 2026).

Leia a tabela na vertical e três regras saltam fora:

• Glacier Instant Retrieval é a única classe de arquivo que um motor de query lê diretamente: milissegundos, mas todo byte lido custa $0.03/GB, sete vezes e meia a própria taxa de armazenamento.
• O tier Bulk do Glacier Flexible Retrieval é gratuito mas lento: $0.00/GB, tipicamente 5 to 12 horas. O FAQ formula assim: "Bulk retrievals typically complete within 5 to 12 hours, and are free of charge."
• Deep Archive não tem tier Expedited via S3. O caminho publicado mais rápido é Standard a $0.02/GB "within 12 hours"; Bulk a $0.0025/GB leva "within 48 hours". A tabela comparativa em outro ponto do mesmo guia cita o intervalo como "9 to 48 hours": planeje contra os bullets dos tiers, não contra o melhor caso.

2.2 Um restore não é um GET

Este é o mecânico mais mal compreendido de todo o modelo de preços do S3, então ele ganha o seu próprio diagrama.

A própria página de preços da AWS afirma a consequência: "Quando você restaura um arquivo, você paga tanto pelo arquivo… quanto por uma cópia… restaurada temporariamente (cobrada na taxa de armazenamento do S3 Standard por uma duração de tempo que você escolher)" (acesso em out 2026). Então a fatura completa de um restore tem quatro componentes: armazenamento de arquivo (ainda acumulando) + a taxa de recuperação por GB do tier + a taxa de requisição de restore por 1,000 + armazenamento S3 Standard na cópia temporária por toda a duração escolhida. O original arquivado nunca muda de classe: HeadObject continua reportando GLACIER ou DEEP_ARCHIVE depois de um restore bem-sucedido.

2.3 Exemplo resolvido E2: restaurando 50 TiB do Deep Archive

Uma produtora de mídia precisa devolver uma biblioteca de broadcast de 50 TiB (51,200 GB) dentro de uma janela de cinco dias. Mantenha a cópia restaurada por 5 dias.

Veredito: Bulk para recuperações planejadas; Standard apenas quando o relógio do negócio é mais curto que 48 horas. O delta de $896 é pura taxa de recuperação: a cobrança da cópia temporária é idêntica nos dois caminhos, e é por isso que a cópia temporária, não a taxa de recuperação, domina qualquer retenção longa. Precisa dos dados em menos de 15 minutos? Deep Archive não te ajuda: não existe tier Expedited via S3, então um SLA de mesma hora significa que os dados nunca deveriam ter saído do Standard, do Standard-IA ou do Glacier Instant Retrieval.

• 📚 Você sabia? O serviço standalone Amazon Glacier vault, um produto separado, com suas próprias vault APIs e ARNs, "is no longer accepting new customers as of December 15, 2025" (página de preços do S3 Glacier, acesso em out 2026). A AWS agora recomenda: "Recomendamos usar as classes de armazenamento S3 Glacier dentro do serviço Amazon S3 para todos os seus dados de longo prazo." Em 2026, "Glacier" em uma conversa de design significa três classes de armazenamento em um bucket S3 normal, não um vault.

---

3. Escolhendo uma classe: a árvore de decisão e a cascata

3.1 A árvore de decisão de classes de armazenamento

Frequência de acesso, latência exigida e se o objeto é recriável decidem a classe: nessa ordem. Os rótulos das folhas carregam o preço e o relógio que você está assinando.

Dois ramos merecem o comentário:

• "Acesso desconhecido" não significa automaticamente Intelligent-Tiering. Significa Intelligent-Tiering uma vez que os objetos são grandes o suficiente para serem monitorados (≥128 KB) e poucos o bastante para a taxa de monitoramento não ser a fatura inteira. Para um arquivo trimestral conhecido, Glacier Instant Retrieval costuma ser mais barato: a seção 10.3 faz o break-even.
• One Zone-IA é um trade de durabilidade, não só um desconto. Disponibilidade de 99.5% em uma única AZ significa uma pergunta genuína sobre se os dados podem ser recriados. Lakes usam ele para dados derivados reprodutíveis, nunca para a única cópia de dados brutos de origem.

3.2 A cascata de ciclo de vida é de mão única

Amazon S3 "supports a waterfall model for transitioning between storage classes" (user guide de ciclo de vida do S3, acesso em out 2026). Objetos fluem para baixo; não fluem para cima. As setas de retorno no diagrama abaixo não são arestas de ciclo de vida: são operações de restore-and-copy que você roda à mão ou via S3 Batch Operations, e cada uma reinicia o relógio de duração mínima da classe de destino e cobra de novo à taxa de destino.

Regras que os docs de ciclo de vida do S3 põem por escrito (acesso em out 2026):

• "You can't create a single Lifecycle rule that transitions objects from one storage class to another before the minimum storage duration period has passed."
• "O transition de objetos para a classe de armazenamento S3 Glacier Deep Archive só pode ir em um sentido."
• "An object is eligible for only one S3 Lifecycle action per day. When multiple rules match, Amazon S3 applies the least costly action."
• Precedência: exclusão permanente > transition > criação de delete markers. Quando uma transition de Glacier Flexible Retrieval e uma de Standard-IA são elegíveis ao mesmo tempo, "Amazon S3 chooses the S3 Glacier Flexible Retrieval transition."
• Uma configuração comporta até 1,000 regras: "This limit is not adjustable."
• Desde setembro de 2024, "Objetos menores que 128 KB não fazem transition por padrão para nenhuma classe de armazenamento."

---

4. Durabilidade, versionamento e replicação

4.1 Versionamento: três estados, cobrança de objeto inteiro

S3 Versioning é de nível de bucket e tudo-ou-nada, com exatamente três estados: sem versionamento (o padrão), habilitado e suspenso. O user guide da AWS é direto sobre a cobrança: "Cada versão de um objeto é o objeto inteiro; não é apenas um diff… se você tem três versões de um objeto armazenadas, você é cobrado por três objetos" (acesso em out 2026).

Versionamento é pré-requisito de duas coisas que você vai precisar depois: S3 Object Lock (que só funciona em buckets com versionamento) e S3 replication (que exige versionamento nos dois lados, origem e destino).

4.2 Replicação: CRR, SRR e a parede da classe arquivada

Cross-Region Replication (CRR) e Same-Region Replication (SRR) são o mesmo mecanismo com destinos diferentes. Versionamento deve estar habilitado nos dois lados. O que é replicado por padrão (docs de replicação do S3, acesso em out 2026):

• Replicado: objetos criados depois da configuração, metadados de objeto, tags, anotações, atualizações de ACL, retenção de Object Lock, e objetos criptografados com SSE-S3 / SSE-KMS / DSSE-KMS / SSE-C.
• Não replicado por padrão: objetos que são eles mesmos réplicas (sem encadeamento), delete markers quando a configuração usa um elemento Filter, exclusões permanentes de versão, mudanças de subrecurso de nível de bucket, e delete markers criados por ciclo de vida.
• NÃO replicável de modo algum até ser restaurado: objetos em Glacier Flexible Retrieval, Glacier Deep Archive, Intelligent-Tiering Archive Access e Intelligent-Tiering Deep Archive Access. Palavras exatas da AWS: "You cannot replicate these objects until you restore them and copy them to a different storage class."

Três consequências operacionais para um lake:

1. CRR não é um backup ao vivo de toda mutação. Com a versão de configuração atual (um Filter), delete markers não são replicados a menos que você habilite explicitamente a replicação de delete markers, e exclusões por version ID nunca são espelhadas: deliberadamente, para que um principal comprometido não apague a cópia de DR deletando versões na origem.
2. Backfill retroativo precisa de S3 Batch Replication. Replicação ao vivo cobre apenas objetos criados depois da configuração; tudo mais antigo é um job de Batch Operations.
3. Monitoramento custa $0.015 por 1 milhão de objetos por mês no bucket de origem (oferta de 2026-09-28). Não existe SKU separado de "$0.02 por GB replicado" nessa oferta: você paga armazenamento do bucket de destino e transferência de dados inter-regional ordinária por cima da taxa de monitoramento. Não ensine a cifra por GB sem re-verificar a aba de preços de Replication.

• 📚 Você sabia? A replicação do S3 carrega as informações de retenção do Object Lock para as réplicas: "it applies those same retention controls to your destination buckets" (docs de replicação do S3, acesso em out 2026). É isso que transforma o CRR em uma segunda cópia de conformidade, e não meramente em uma segunda cópia: a data de retenção sobrevive ao salto de Região.

---

5. Object Lock: WORM para zonas reguladas do lake

S3 Object Lock "uses a write-once-read-many (WORM) model" e "funciona apenas em buckets que têm o S3 Versioning habilitado" (user guide do S3, acesso em out 2026). Ele protege uma versão de objeto, não uma key, e essa distinção é onde a maioria dos designs falha.

A AWS tem o Object Lock "avaliado pela Cohasset Associates para uso em ambientes sujeitos às regulamentações da SEC 17a-4, CFTC e FINRA" (acesso em out 2026), e é exatamente por isso que as histórias de dados regulados deste curso (arquivos de vigilância no estilo FINRA, a camada de conformidade da Nasdaq) recorrem a ele.

• 📚 Você sabia? Um limite de regra único que a maioria das pessoas ignora: uma configuração de S3 Lifecycle "can have up to 1,000 rules" e o filtro de cada regra pode usar "an object key name prefix, one or more object tags, object size, or any combination of these" (docs da API do S3, acesso em out 2026), e você não pode usar uma bucket policy para impedir exclusões ou transitions por uma regra de ciclo de vida. Object Lock para principais; expiração de ciclo de vida é uma ação do serviço, então designs de zona auditada casam Object Lock com regras de ciclo de vida que param deliberadamente antes do limite da retenção.

---

6. Criptografia: SSE-S3, SSE-KMS, DSSE-KMS, SSE-C e Bucket Keys

Desde 5 de janeiro de 2023, "todos os novos uploads de objetos para o Amazon S3 são criptografados automaticamente, sem custo adicional e sem impacto no desempenho": esse padrão é SSE-S3 (user guide do S3, acesso em out 2026). Todo o resto é um upgrade com preço e restrição.

Três upgrades que um lake tipicamente precisa:

1. Um S3 Bucket Key. "Using a bucket-level key for SSE-KMS can reduce your AWS KMS request cost by up to 99 percent" (user guide do S3, acesso em out 2026). Nos volumes de escrita de um lake, centenas de milhares de chamadas PutObject por dia, a fatura de requisições do KMS é a diferença entre o SSE-KMS ser acessível e ser uma linha de item.
2. Uma CMK gerenciada pelo cliente para qualquer coisa entre contas. "Objects encrypted using SSE-KMS with AWS managed keys can't be shared cross-account. If you need to share SSE-KMS data cross-account, you must use a customer managed key." Conceda kms:Decrypt à conta consumidora e habilite o Bucket Key.
3. A criptografia sobrevive às transitions de classe, mas note a nota de rodapé da cobrança: "Objects in S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive are billed at S3 Standard storage class rates when you upload them using multipart uploads." Sempre aterrice no Standard (ou complete o multipart upload prontamente) e deixe o ciclo de vida fazer a transition.

Duas armadilhas de formato de requisição que valem decorar: requisições SSE-KMS precisam chegar via TLS com SigV4, e você não deve enviar headers de criptografia em GET/HEAD, o S3 responde HTTP 400.

---

7. Buckets, prefixos e chaves de partição: o modelo de desempenho

7.1 O S3 escala por prefixo, não por bucket

A documentação de desempenho do S3 enuncia o modelo exatamente assim: "your application can achieve at least 3,500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requests per second per partitioned Amazon S3 prefix. There are no limits to the number of prefixes in a bucket… if you create 10 prefixes… you could scale your read performance to 55,000 read requests per second" (acesso em out 2026). A escalada é gradual, e clientes veem erros 503 Slow Down enquanto ela sobe.

O incidente composto descrito no material de laboratório do Well-Architected da AWS bate com esse formato: um job de ingestão de streaming escrevia 800 objetos pequenos/segundo em s3://lake-prod/raw/events/2026-10-11/events.json.gz, um prefixo só, o throughput desabou em ~3,500 escritas/s com 503 Slow Down sustentado, e fazer re-sharding da key do producer para 16 prefixos shard-{000..015} restaurou a folga para ~56,000 escritas/s sem nenhuma outra mudança. A distribuição de partições é um controle de desempenho independente da semântica de partição.

7.2 Chaves de partição são o layout físico

Para tabelas no estilo Hive, o layout da key é o layout físico da partição: s3://lake/events/dt=2026-10-11/hour=07/part-…parquet. Regras de desenho que valem em Glue, Athena, EMR e Redshift Spectrum:

• 📚 Você sabia? Requisições LIST não são gratuitas e não são precificadas como GET: "As requisições LIST para qualquer classe de armazenamento são cobradas na mesma taxa das requisições PUT, COPY e POST do S3 Standard": $0.005 por 1,000 (página de preços do S3 e oferta de 2026-09-28). Requisições DELETE e CANCEL, em contraste, são gratuitas. Este é um segundo argumento, mais silencioso, para um fan-out moderado de prefixos: mais prefixos significam mais fan-out de LIST/GET em scans de bucket inteiro e mais metadados de partição no Glue, então faça shard pelas suas partições reais de tempo, não sinteticamente até o limite.

---

8. Trancando o lake: Block Public Access e bucket policies

8.1 Block Public Access é o interruptor de emergência

"By default, new buckets, access points, and objects don't allow public access." Por cima desse padrão, S3 Block Public Access fornece quatro configurações, BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy e RestrictPublicBuckets, e "if the block public access settings… differ, then Amazon S3 applies the most restrictive combination" (user guide do S3, acesso em out 2026).

A recomendação da AWS para uma conta de lake é inequívoca: "recomendamos que você ative todas as quatro configurações… para a sua conta." Lembre-se da armadilha de camadas: desligar o BPA em um bucket não faz nada se a conta ou a organização ainda bloqueiam, e o S3 sempre impõe a combinação mais restritiva. "Público" significa uma ACL ou política concedendo a AllUsers/AuthenticatedUsers, ou uma bucket policy com um principal curinga não restringido por um aws:PrincipalArn, aws:PrincipalOrgID, aws:SourceAccount, aws:SourceArn, aws:SourceVpc, aws:SourceVpce, aws:SourceIp ou s3:DataAccessPointArn fixos.

8.2 Oito padrões de bucket policy para um lake privado

Block Public Access impede o bucket de ir para o ar; a política abaixo impede todo o resto que um data lake realmente precisa recusar. Um statement Deny com "Principal": "*" restringe acesso em vez de conceder, então ele compõe limpo com as quatro configurações de BPA deixadas ligadas.

Notas sobre o JSON, porque cada statement codifica uma regra fácil de errar sutilmente:

• Uma condição por statement nos checks de SSE-KMS. Um único statement com duas chaves StringNotEquals só se aplica quando ambas as condições casam, o que deixaria passar uma requisição com o header de criptografia certo mas a chave errada. Dois statements = duas negações independentes.
• O statement 2 sozinho está incompleto sem o statement 3: fixar o algoritmo não fixa a chave, e uma chave não fixada é um raio de blast não fixado.
• A lista completa de padrões para um lake (docs de bucket policy e condition keys do S3, acesso em out 2026): (1) negar não-TLS; (2) negar PutObject a menos que SSE-KMS; (3) fixar o ARN da CMK; (4) negar DeleteObjectVersion fora do retention role; (5) grants escopados por prefixo como arn:aws:s3:lakehouse-prod/raw/* para roles de engenharia; (6) fixação de Região com aws:RequestedRegion; (7) fixação de organização com aws:PrincipalOrgID; (8) restrições de origem de service principal (aws:SourceArn + aws:SourceAccount) para Lake Formation, Glue, Athena e Macie: mais tetos de retenção via s3:object-lock-remaining-retention-days.

---

9. O plumbing de governança: S3 Inventory e S3 Batch Operations

Regras de ciclo de vida e replicação ao vivo cobrem o movimento para frente. Dois serviços cobrem todo o resto, e ambos são baratos o suficiente para que pulá-los seja uma economia falsa.

9.1 S3 Inventory, o snapshot agendado de metadados

S3 Inventory produz "comma-separated values (CSV), Apache optimized row columnar (ORC) or Apache Parquet output files that list your objects and their corresponding metadata on a daily or weekly basis" (user guide do S3, acesso em out 2026). As propriedades que importam para um lake:

Essa lista de campos é um pipeline de auditoria: quem está travado, até quando, em qual tier, replicado ou não: consultável no Athena, sem uma única chamada ListObjectsV2 contra o bucket ao vivo.

9.2 S3 Batch Operations: governança retroativa

S3 Batch Operations é dirigido por manifesto: construa o manifesto a partir de um relatório do S3 Inventory, escolha uma operação, pague por job e por objeto. Lista us-east-1, em out 2026: $0.25 por job e $1.00 por milhão de objetos processados (oferta de 2026-09-28).

As operações que regras de ciclo de vida e replicação ao vivo não fazem:

• Aplicar retroativamente retenção de Object Lock ou legal hooks a milhões de objetos pré-existentes;
• Restaurar milhões de objetos Glacier (o único caminho sensato de rodar uma recuperação em massa como a E2 em escala);
• Batch Replication para backfill de objetos anteriores à configuração de replicação;
• Aplicar SSE-KMS em massa depois de uma mudança de política de chave;
• Copiar, taggear, atualizar ACLs, ou invocar uma função Lambda por objeto.

O padrão para internalizar: Inventory é o lado da leitura (o que temos, em que estado), Batch Operations é o lado da escrita (mudar tudo isso, uma vez), e o ciclo de vida é a ordem permanente (continuar fazendo isso conforme os objetos envelhecem). S3 Select, aliás, não faz parte desse kit para designs novos: a AWS o fechou para novos clientes em 25 de julho de 2024 e documenta o Athena como a abordagem recomendada para query de data lakes (AWS Storage Blog, 2024-07-25).

---

10. Matemática de custo do ciclo de vida: TCO de Deep Archive e a armadilha do Intelligent-Tiering

10.1 Exemplo resolvido E5, o título: TCO de 7 anos com uma cascata de ciclo de vida

Um lake de conformidade mantém 100 TiB (102,400 GB) de Parquet com média de 256 MB por objeto (≈409,600 objetos), escrito uma vez, consultado por 90 dias, depois arquivado por 7 anos. Todos os preços em lista us-east-1, em out 2026.

A economia de ~$185,000 é real, e é condicionada a exatamente três coisas: os dados genuinamente ficam ≥180 dias no Deep Archive (caso contrário a duração mínima te cobra de qualquer jeito), um SLA de restore de 12 horas / 48 horas é aceitável, e os objetos são grandes o bastante para o overhead de 40 KB de metadados permanecer uma margem de erro (e é: ~$0.08/mês em 409,600 objetos). Erre qualquer uma das três e o modelo quebra, e é por isso que a seção 10.4 existe.

10.2 Exemplo resolvido E6: break-even do Intelligent-Tiering

A mesma pergunta que todo lake faz: 10 TiB (10,240 GB), acesso desconhecido, 200 milhões de objetos. Deveria ser Intelligent-Tiering, ou uma classe explícita?

10.3 Exemplo resolvido E7: a armadilha dos 40 KB de metadados de arquivo

Todo objeto movido para Glacier Flexible Retrieval ou Glacier Deep Archive carrega 40 KB de metadados adicionais: "32 KB… cobrados na taxa padrão daquela classe de armazenamento" mais "an additional 8 KB… charged at the S3 Standard rate" (docs de archival storage do S3, acesso em out 2026). Em arquivos Parquet de 256 MB isso é invisível. Em um lake de arquivos JSON minúsculos, isso é a fatura.

10.4 A armadilha da taxa de monitoramento do Intelligent-Tiering

Uma segunda armadilha, mais silenciosa, da mesma família: multipart uploads para classes Glacier são cobrados às taxas de armazenamento do S3 Standard até que todas as parts completem e o S3 aplique a classe de verdade. Aterrice no Standard (ou termine o upload prontamente) e deixe o ciclo de vida fazer a transition do objeto completado.

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

---

Casos Reais

Caso A, Nasdaq: query-in-place, com uma saída de conformidade

Nasdaq (operadora de bolsa, serviços financeiros). Como o estudo de caso da AWS descreve (página do ano 2020, acesso em out 2026), a Nasdaq migrou para Amazon Redshift em 2014, cresceu um cluster para 70 nós até 2018, e estava ingerindo 30 to 55 bilhões de registros, mais de 4 TB, toda noite de milhares de fontes. A contenção entre carga e query no warehouse era a restrição. A correção foi o padrão que este curso chama de lakehouse: um data lake de 15 TB no Amazon S3 consultável in place via Redshift Spectrum, que a própria Nasdaq chama de "lake house architecture". A AWS reporta queries do Redshift "32 percent faster" e conclusão de data-load de 90% 5 horas mais cedo, e um AWS Data Lab de janeiro de 2019 (quatro dias) sustentou o salto "from 30 billion records to 70 billion records a day."

O motivo de a Nasdaq aparecer nesta lição é a saída, não a aceleração: a AWS posiciona o lake S3 com Glacier e Object Lock como a camada de arquivo/conformidade ao lado dos dados quentes consultáveis. Isso é a árvore de decisão de classes de armazenamento virando real: janelas recentes ficam em S3 Standard para o Spectrum e o Redshift varrerem, e a cauda regulatória de múltiplos anos é um arquivo com Object Lock e gerenciado por ciclo de vida. A lição: arquivo é uma decisão de retenção com um SLA de restore anexado, exatamente como no exemplo resolvido E5.

Resultados relatados por cliente a partir de uma página da AWS sem data; não é um compromisso da AWS. Carimbe a data: como a AWS reportou em 2020.

Caso B, Siemens: 5 to 7 TB por dia, e os server access logs do S3 como trilha de auditoria

Siemens (manufatura industrial e tecnologia; Cloud Security Operations). Segundo o estudo de caso da AWS (página sem data, acesso em out 2026), a Siemens governa 800+ contas AWS e onboardinga 5 to 7 TB/dia de dados de segurança no Amazon Security Lake, encaminhando apenas 600 GB adiante para o Splunk, uma redução de 90% de volume, para uma economia reportada de $1.3 milhão por ano. O onboarding de logs novos caiu de "several weeks" para 1 to 2 dias, e o tempo de identificação de causa raiz caiu 75%. Uma investigação identificou os dados afetados no S3 em 10 minutos versus several days.

O detalhe relevante para a lição está na lista de fontes onboardingadas: VPC Flow Logs, S3 server access logs e AWS WAF logs. O server access logging do S3 é a própria caixa-preta do lake, cada requisição registrada, no lake, às taxas Standard, e é o complemento nativo do S3 para os S3 data events do CloudTrail. Note a armadilha de nome que a própria AWS avisa: Amazon Security Lake é um serviço de agregação de logs de segurança no S3; ele não é AWS Lake Formation, que governa permissões (lição 12).

---

Perguntas de Prática (Practice Questions)