A classe mais barata do S3 é a que você nunca abre

Um time tira alguns milhões de objetos do S3 Standard. O armazenamento por gigabyte cai. O financeiro respira. Dois meses depois alguém roda um job que lê quase o prefixo inteiro. A fatura não ficou mais barata. Ficou uma taxa de retrieval com uma storage class colada.

Esse é o erro clássico do S3. A pessoa otimiza o preço de guardar o byte. A conta também cobra por tocar nele, por apagar cedo demais e por objeto menor do que a classe quer faturar.

Se você guardar uma coisa: escolha a classe pela frequência de leitura, pela velocidade que essa leitura precisa ter e por conseguir ou não reconstruir o objeto se uma zona sumir. O resto é casar essas três respostas com uma classe que a AWS já nomeou.

Referência oficial: Understanding and managing Amazon S3 storage classes. Preço fica em Amazon S3 pricing. Este artigo não cita valor em dólar. Isso muda por região e por data. O formato da troca não muda.

Frequência é o enredo inteiro

S3 Standard é o padrão. Sobe o objeto, não manda o header de storage class, você está em Standard. GET em milissegundo. Projetada para 99,99% de disponibilidade em pelo menos três Availability Zones. Sem duração mínima de armazenamento. Sem tamanho mínimo faturável. Você paga mais por GB guardado do que nas classes de arquivo, e não paga retrieval por GB numa leitura normal.

Use quando o objeto está no caminho da requisição: imagem de produto, artefato de sessão, o dataset que a API bate esta semana, qualquer coisa que você teria vergonha de restaurar de um arquivo enquanto o usuário espera.

Não use como sótão de dez anos. Tecnicamente dá. Você vai pagar Standard em dado que ninguém abre.

A armadilha do outro lado é jogar tudo numa classe infrequent ou Glacier porque a linha de storage é menor. Infrequent-access e Glacier somam cobrança de retrieval. Várias delas também faturam duração mínima e tamanho mínimo de objeto. Um prefixo cheio de arquivo miúdo que você reescreve toda semana é um encaixe ruim nessas classes, mesmo se você "quase nunca" pensa neles.

Quando você não conhece o padrão de acesso

S3 Intelligent-Tiering existe para a resposta honesta: "ainda não sei."

A AWS desenhou para acesso desconhecido, que muda, ou imprevisível. Ela observa os objetos e move entre tiers quando esfriam, e volta para Frequent Access se alguém lê de novo. Não tem taxa de retrieval dentro do Intelligent-Tiering. Você paga monitoramento e automação por objeto.

Tiers automáticos, pela documentação atual:

• Frequent Access: onde o objeto novo começa.
• Infrequent Access: depois de 30 dias seguidos sem acesso.
• Archive Instant Access: depois de 90 dias seguidos sem acesso. Continua milissegundo, alto throughput.

Opcionais, só se a aplicação puder esperar:

• Archive Access: assíncrono. Mesmo formato de performance do S3 Glacier Flexible Retrieval. Restore standard costuma levar de 3 a 5 horas.
• Deep Archive Access: assíncrono. Mesmo formato de performance do S3 Glacier Deep Archive. Restore standard costuma ficar dentro de 12 horas.

Objeto menor que 128 KB não é monitorado. Fica em Frequent Access. Se o bucket é milhões de objetos miúdos, a taxa de monitoramento pode dominar e o auto-tiering nunca começa. Nesse caso Intelligent-Tiering é o default errado.

Encaixa bem: data lake, dump de analytics, prefixo de produto novo cujo padrão de leitura você só vai aprender em produção.

Encaixa mal: caminho quente que você já conhece (use Standard), ou arquivo conhecido que você não vai ler por anos (pule a taxa de monitoramento e coloque no Glacier de propósito).

Infrequent não é "Standard mais barato"

S3 Standard-IA e S3 One Zone-IA mantêm acesso em milissegundo, como o Standard. A AWS descreve como dado de vida longa que você toca mais ou menos uma vez por mês. As duas cobram retrieval por GB. As duas têm 30 dias de duração mínima e 128 KB de tamanho mínimo faturável. Apagar, sobrescrever ou transicionar antes de 30 dias ainda cobra o resto do mês, proporcional.

Por isso "mover para IA no segundo dia" pode sair mais caro do que deixar no Standard.

Standard-IA guarda o objeto em pelo menos três Availability Zones. Projetada para 99,9% de disponibilidade. Orientação da própria AWS: use para a cópia principal que você não consegue recriar. Backup que você pode precisar restaurar neste trimestre, dado antigo da aplicação que ainda precisa servir um GET em milissegundo, arquivo de compliance quieto mas não congelado.

One Zone-IA guarda o objeto numa Availability Zone só. Projetada para 99,5% de disponibilidade. Storage mais barato. Não aguenta a perda daquela zona. A AWS é explícita: use para dado que você reconstrói, ou para réplica, não como única cópia de algo que você não substitui.

Se o objeto é a única cópia das notas fiscais do ano passado, One Zone-IA é o tipo errado de barato.

Glacier são três produtos diferentes que compartilham o nome da montanha

Ainda se fala "joga no Glacier" como se fosse um botão. São três classes com três histórias de retrieval.

S3 Glacier Instant Retrieval. Preço de arquivo, GET em milissegundo. Feita para dado de vida longa que você talvez toque uma vez por trimestre. Mínimo de 90 dias. Mínimo faturável de 128 KB. Tem taxa de retrieval. O objeto fica disponível em tempo real. É a classe do "quase nunca abrimos, mas quando o jurídico pede, quer agora."

S3 Glacier Flexible Retrieval. O objeto está arquivado. Um GET normal não devolve os bytes até você restaurar. Mínimo de 90 dias. Metadado extra é cobrado por objeto (40 KB: 32 KB na tarifa Glacier Flexible, 8 KB na Standard, para o S3 ainda listar a key). Opções de retrieval na documentação atual de restore:

Opção	Tempo típico (Flexible Retrieval)
Expedited	1 a 5 minutos para objeto abaixo de 250 MB
Standard	3 a 5 horas (minutos a 5 horas com Batch Operations)
Bulk	5 a 12 horas, retrieve de menor custo

Bulk retrieval em objeto no Flexible Retrieval é gratuito. Expedited é caminho premium. Sem capacidade provisionada, Expedited pode ser recusado sob carga.

Use Flexible Retrieval para restore grande que você consegue planejar: dump anual, árvore de disaster recovery que você espera nunca tocar, arquivo em que "ainda hoje à tarde" serve.

S3 Glacier Deep Archive. Menor custo de storage desta família. Mínimo de 180 dias. Mesmo estilo de cobrança extra de metadado. Restaura primeiro, depois lê. Expedited não existe. Restore standard costuma ficar dentro de 12 horas (cerca de 9 a 12 horas com Batch Operations). Bulk costuma ficar dentro de 48 horas.

Use para dado que você guarda porque a política falou "sete anos", não porque um engenheiro vai dar curl numa terça.

Restore não é uma cópia sentada ao lado do arquivo para sempre. Você restaura por um número de dias, depois a cópia temporária expira. Se o runbook diz "é só dar GET no objeto", Deep Archive quebra esse runbook.

Uma decisão que cabe numa passada

Passe o objeto (ou o prefixo) por estas perguntas:

1. Alguma coisa trava neste GET? Requisição do usuário, API, etapa de pipeline. Fique no Standard, nos tiers instantâneos do Intelligent-Tiering, no Instant Retrieval ou no Express One Zone. Não coloque no Flexible Retrieval nem no Deep Archive.
2. Eu conheço o padrão de acesso? Não: Intelligent-Tiering, se o objeto for grande o bastante para monitorar. Sim, quente: Standard. Sim, frio mas instantâneo: Standard-IA ou Instant Retrieval. Sim, frio e assíncrono: Flexible Retrieval ou Deep Archive.
3. Consigo recriar se uma AZ sumir? Não: não use One Zone-IA (nem Express One Zone) como única cópia.
4. Quanto tempo vai viver, e qual o tamanho? Menos de 30 dias ou muitos objetos abaixo de 128 KB: IA e Instant Retrieval vão faturar como se o objeto fosse maior e mais velho do que é.
5. Quem paga se a gente ler o prefixo inteiro? Se um job mensal varre tudo, classe com preço de retrieval pode ganhar do Standard no storage e perder no job.

Classe	Acesso	Restore primeiro?	Duração mínima	Tamanho mínimo faturável	Zonas
Standard	Milissegundo, frequente	Não	Nenhuma	Nenhum	>= 3
Intelligent-Tiering	Milissegundo nos tiers automáticos	Só nos tiers opcionais de arquivo	Nenhuma	Nenhum (abaixo de 128 KB fica Frequent)	>= 3
Standard-IA	Milissegundo, infrequent	Não	30 dias	128 KB	>= 3
One Zone-IA	Milissegundo, infrequent	Não	30 dias	128 KB	1
Glacier Instant Retrieval	Milissegundo, raro	Não	90 dias	128 KB	>= 3
Glacier Flexible Retrieval	Minutos a horas	Sim	90 dias	Overhead de metadado	>= 3
Glacier Deep Archive	Horas	Sim	180 dias	Overhead de metadado	>= 3

A durabilidade projetada dessas classes é 99,999999999%, na mesma tabela de comparação. Disponibilidade não é o mesmo número. Standard e Flexible Retrieval (depois do restore) são projetadas para 99,99%. Standard-IA, Intelligent-Tiering e Instant Retrieval são projetadas para 99,9%. One Zone-IA é projetada para 99,5%.

Pilhas concretas de objeto

Lê todo dia. Thumbnail, config atual, working set de um serviço. S3 Standard. Lifecycle depois, não no primeiro dia.

Lê de vez em quando, ainda precisa de GET rápido. Relatório do trimestre passado, "baixar nota" de um pedido antigo. Standard-IA se o objeto for grande o bastante e for viver mais de 30 dias. Instant Retrieval se a leitura estiver mais perto de uma vez por trimestre do que uma vez por mês.

Backup. Se o restore é incêndio e precisa ser rápido, Standard-IA ou Instant Retrieval. Se o restore é um fim de semana planejado, Flexible Retrieval. Se o restore é "a gente guarda porque o audit pediu", Deep Archive. One Zone-IA só se outra região ou outro sistema já tiver uma cópia em que você confia.

Guardar por anos, quase nunca abrir. Deep Archive. Coloque um lifecycle no prefixo para não depender de alguém lembrar.

Job que pode varrer o prefixo. Prefira Standard ou Intelligent-Tiering. Taxa de retrieval em IA e Instant Retrieval é precificada para leitura rara, não para "reprocessamos o lake."

Acesso desconhecido, objeto que não é miúdo. Intelligent-Tiering como classe padrão no PutObject (x-amz-storage-class: INTELLIGENT_TIERING). Deixe os tiers opcionais assíncronos de arquivo desligados até a aplicação souber restaurar.

Mais uma classe se o problema de verdade for latência

A documentação atual também lista S3 Express One Zone: acesso em milissegundo de um dígito numa Availability Zone só, directory bucket, feito para compute sensível a latência perto do dado. Projetada para 99,95% de disponibilidade. Não substitui Standard numa API multi-AZ. Não é classe de arquivo. Se a dor é "Standard está lento demais neste loop apertado", leia aquela página. Se a dor é a fatura, é a página errada.

A AWS ainda documenta Reduced Redundancy Storage. A mesma página pede para não usar. Standard é o substituto.

Como o time costuma errar isso

Eles tratam uma classe como se fosse do bucket. Classe é por objeto. Regra de lifecycle move prefixo conforme envelhece: Standard por 30 dias, Standard-IA depois, Instant Retrieval ou Flexible Retrieval um ano mais tarde. Você não precisa de um bucket novo para cada classe.

Eles esquecem que overwrite e delete entram na duração mínima. Um prefixo "barato" de IA que é trocado a cada deploy não é infrequent. É Standard com taxa extra.

Eles tratam Glacier como pasta. O objeto continua no S3. Flexible Retrieval e Deep Archive só não fazem GET até o RestoreObject terminar.

Eles otimizam storage e ignoram listagem, monitoramento e restore. A taxa por objeto do Intelligent-Tiering e os bytes de metadado do Glacier são reais. Pesam mais quando o objeto é pequeno e numeroso.

Um default que você consegue defender

• Caminho quente, conhecido: Standard.
• Desconhecido, objeto que vale monitorar: Intelligent-Tiering, só os tiers automáticos.
• Frio, precisa de GET agora, multi-AZ: Standard-IA ou Instant Retrieval, conforme a raridade da leitura.
• Frio, precisa de GET agora, você reconstrói: One Zone-IA.
• Frio, você aguenta esperar horas: Flexible Retrieval.
• Frio, você aguenta esperar um dia, vai guardar por anos: Deep Archive.

Se ainda parecer chute, não chute Glacier. Chute Intelligent-Tiering ou Standard, e coloque um lifecycle quando tiver log de acesso de verdade. A classe cara é a que te surpreende quando alguém finalmente abre o objeto.