Multiplicar terabytes armazenados pelo preço por GB-mês é apenas a primeira linha de uma estimativa de Amazon S3. Requests, recuperação de dados, transições de lifecycle, tamanho mínimo faturável, permanência mínima e transferência podem alterar o total — especialmente quando há muitos objetos pequenos ou acesso a classes de menor frequência.
A forma auditável de estimar é separar cada componente e informar os preços oficiais da região na calculadora de custo total do S3. Assim, uma mudança de tarifa não exige reescrever a fórmula nem confiar em um exemplo antigo.
O inventário mínimo do workload
Antes do preço, registre:
- classe de armazenamento e região;
- GB-mês médios, não apenas o volume no último dia;
- número e tamanho médio dos objetos;
- quantidade mensal de GET, PUT, COPY, POST, LIST e demais grupos cobrados;
- GB recuperados de classes com retrieval;
- quantidade de transições de lifecycle;
- GB transferidos para cada destino;
- exclusões ou transições antes da permanência mínima.
Essas dimensões devem vir de métricas, inventário e logs de um período representativo. Um total de bytes sem contagem de objetos não revela o impacto de tamanho mínimo; uma contagem de requests sem classificar operação não permite aplicar o grupo de preço correto.
A equação em blocos
Uma decomposição geral é:
custo total = armazenamento + requests + retrieval + lifecycle + transferência + ajustes mínimos
Cada parcela mantém quantidade e preço unitário:
armazenamento = GB-mês faturáveis × preço por GB-mês
requests = Σ (quantidade do grupo ÷ unidade de cobrança × preço do grupo)
retrieval = GB recuperados × preço por GB recuperado
lifecycle = transições ÷ unidade de cobrança × preço por transição
transferência = GB cobrados × preço por GB no caminho aplicável
Use a unidade exibida na página oficial. Não misture “por mil” com “por milhão”, nem GB decimais e GiB sem registrar a conversão adotada.
As alturas são ilustrativas e não reproduzem uma fatura. O objetivo é impedir que parcelas não relacionadas ao storage desapareçam da análise.
Classes não diferem só no preço de storage
A documentação oficial descreve características distintas por classe. Na verificação deste artigo, S3 Standard-IA tem duração mínima de armazenamento de 30 dias, tamanho mínimo faturável de 128 KB e cobrança de retrieval. Outras classes possuem regras próprias. Portanto, mover dados frios para uma linha com menor preço de GB-mês pode não reduzir o total quando objetos são muito pequenos, duram pouco ou são recuperados com frequência.
Para modelar tamanho mínimo, use:
GB faturáveis = quantidade de objetos × max(tamanho médio, mínimo faturável)
Essa simplificação por média não substitui a distribuição real. Se o conjunto mistura objetos de 4 KB e 20 MB, segmente os dois grupos para não esconder o efeito.
Para permanência mínima, separe objetos removidos ou migrados antes do prazo e estime o período ainda faturável conforme a regra vigente da classe. Não aplique automaticamente 30 dias a todas as classes.
Exemplo ilustrativo e reproduzível
Imagine 10 milhões de objetos com tamanho médio de 40 KB, 50 milhões de GET, 2 milhões de PUT, 3 TB recuperados e 1 TB de saída no mês. Os números são fictícios. O procedimento correto é:
- escolher a classe e confirmar mínimo de tamanho e permanência;
- calcular storage sobre bytes faturáveis, não apenas bytes lógicos;
- classificar GET e PUT nos grupos exibidos pelo pricing;
- incluir retrieval somente onde a classe cobra;
- classificar o destino da transferência e sua regra;
- incluir lifecycle ou exclusão antecipada quando ocorrer;
- repetir com volume, requests e retrieval em cenários baixo, central e alto.
Neste cenário, o tamanho médio abaixo de um eventual mínimo faturável é um alerta material. O resultado não deve usar a média de 40 KB cegamente. Um inventário por faixa de tamanho dá uma base mais honesta.
Como avaliar lifecycle sem promessa de economia
Uma regra de lifecycle cria uma troca: menor tarifa de armazenamento pode adicionar transições, retrieval e permanência mínima. Compare o custo antes e depois com a mesma janela temporal:
- estado atual por classe;
- transições esperadas por mês;
- tempo de residência em cada classe;
- probabilidade e volume de recuperação;
- objetos que serão excluídos cedo;
- crescimento do inventário.
Se o resultado depender de “ninguém acessará esses dados”, trate a taxa de retrieval como variável e faça sensibilidade. Não publique uma porcentagem de economia sem workload observado e preços datados.
Reconcilie com a fatura
Depois de estimar, compare as parcelas com Cost Explorer, CUR ou outra fonte de billing autorizada. Diferenças comuns vêm de média de GB-mês, classe incorreta, operações não contadas, transferência por caminho diferente e recursos adjacentes. A reconciliação transforma a calculadora em hipótese testável, não em uma caixa-preta.
Checklist final:
- região e data do pricing registradas;
- contagem de objetos e distribuição de tamanho disponíveis;
- operações separadas por grupo de cobrança;
- retrieval e lifecycle modelados por classe;
- destino da transferência identificado;
- mínimos documentados sem generalização entre classes;
- valores unitários atualizados antes da decisão.
Fontes e vigência
As dimensões de cobrança e o exemplo de regras de S3 Standard-IA foram verificados em 8 de agosto de 2026 nas páginas oficiais da AWS. Nenhuma tarifa numérica foi incorporada. Confirme a classe, a região, o caminho de transferência e as regras vigentes no AWS Pricing Calculator e na documentação antes de alterar dados ou lifecycle.