Otimização de custos de armazenamento no S3 na prática: da análise de dimensões de cobrança a 7 ações práticas

Muitas equipes focam apenas em “quantos TB estão armazenados” ao analisar a fatura do S3, mas os custos reais do S3 geralmente são compostos pela soma de quatro tipos de despesas: capacidade de armazenamento, quantidade de requisições, transferência de dados e recursos de gerenciamento. A otimização também deve ser feita a partir dessas quatro dimensões, em vez de simplesmente migrar todos os buckets para classes de armazenamento mais frias.

Os preços a seguir utilizam us-east-1 como exemplo (consulte os valores reais para a sua região da AWS): os primeiros 50TB no S3 Standard custam cerca de $0.023/GB-month; Standard-IA custa cerca de $0.0125/GB-month; Glacier Instant Retrieval custa cerca de $0.004/GB-month; e Glacier Deep Archive custa cerca de $0.00099/GB-month. Embora o Deep Archive pareça muito mais barato, ele possui tempo mínimo de armazenamento, tempo de recuperação e taxas de recuperação, portanto não se deve migrar cegamente.

1. Primeiro, identifique a origem dos custos

Recomenda-se analisar detalhadamente no Cost Explorer agrupando por Usage type:

• TimedStorage-ByteHrs: Capacidade de armazenamento de objetos.
• Requests-Tier1/Tier2: Requisições como PUT, LIST, GET, etc.
• DataTransfer-Out-Bytes: Transferência para a internet pública ou entre regiões.
• Monitoring-Automation, Inventory, StorageLens: Recursos de gerenciamento e análise.

Um erro comum é: o custo de armazenamento não é alto, mas há muitas requisições LIST/GET, ou o acesso ao S3 a partir de uma sub-rede privada passa por um NAT Gateway, aumentando a fatura de rede. A otimização do S3 não deve focar apenas no bucket size.

2. Intelligent-Tiering e Regras de Ciclo de Vida

Se o padrão de acesso aos objetos for instável, o S3 Intelligent-Tiering é um ponto de partida de baixo risco. Ele move objetos automaticamente entre camadas como Frequent, Infrequent e Archive Instant. Não há taxas de recuperação entre as camadas automáticas, mas há uma taxa de monitoramento e automação, cujo valor típico é de $0.0025/1,000 objects-month. Se os objetos forem muito pequenos e em grande quantidade, esse custo de gerenciamento pode não valer a pena.

As regras de ciclo de vida são adequadas para dados com padrões de acesso claros, como logs, backups e amostras de treinamento:

{
  "Rules": [
    {
      "ID": "logs-to-glacier",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" },
        { "Days": 180, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 730 }
    }
  ]
}

Atenção ao tempo mínimo de armazenamento: geralmente 30 dias para Standard-IA, 90 dias para Glacier Instant Retrieval / Flexible Retrieval e 180 dias para Deep Archive. Objetos com ciclo de vida curto não devem ser movidos para camadas frias precocemente.

3. Glacier IR e Deep Archive: Apenas para Dados “Realmente Frios”

O Glacier Instant Retrieval é ideal para arquivamentos de “baixa frequência, mas que exigem leitura em milissegundos”, como auditorias de conformidade e relatórios históricos. Já o Deep Archive é adequado para dados que quase nunca serão lidos e que podem aguardar várias horas para serem restaurados, como backups de múltiplos anos.

O critério de decisão pode ser simples: se há uma grande probabilidade de um objeto não ser lido em 6 meses, vale a pena avaliar o Deep Archive. Se a área de negócios não puder tolerar o tempo de espera para restauração, não force a migração apenas para reduzir a fatura.

4. Limpeza de Versões Antigas e Multipart Upload Incompletos

Ao ativar o Versioning, a exclusão de um objeto gera apenas um delete marker, e as versões antigas continuam sendo cobradas. Os “custos fantasma” de muitos buckets vêm de versões históricas.

Primeiro, você pode listar as versões:

aws s3api list-object-versions --bucket my-bucket --prefix app/

Em seguida, use as regras de ciclo de vida para limpar as versões não atuais:

{
  "Rules": [
    {
      "ID": "expire-old-versions",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

A opção AbortIncompleteMultipartUpload é facilmente esquecida. Quando o upload de um arquivo grande falha, os pedaços (parts) podem permanecer no S3 por muito tempo, continuando a ser cobrados.

5. Otimização de Requisições: LIST é Mais Caro do que Você Imagina

No S3 Standard, o preço comum para requisições do tipo PUT/COPY/POST/LIST é de cerca de $0.005/1,000 requests, enquanto o GET custa em torno de $0.0004/1,000 requests. Embora o custo unitário pareça baixo, quando o número de objetos chega a centenas de milhões, varreduras com LIST tornam-se caras e também deixam o sistema mais lento.

Recomenda-se na prática:

• Evitar usar ListObjectsV2 como se fosse uma consulta de banco de dados.
• Projetar a key dos objetos incluindo data, inquilino (tenant) ou prefixos de negócios para reduzir varreduras desnecessárias.
• Utilizar o S3 Inventory em vez de varreduras completas com LIST.
• Agrupar ou cachear pequenos objetos muito acessados para mitigar tempestades de GET.

6. Use VPC Endpoint para Evitar Desvios pelo NAT Gateway

Quando instâncias EC2, ECS ou funções Lambda em sub-redes privadas acessam o S3, se a rota passar por um NAT Gateway, haverá cobrança pela taxa de processamento de dados do NAT. Em us-east-1, o preço comum do NAT Gateway é de aproximadamente $0.045/hour mais $0.045/GB processed. Assim, transferir 1TB/mês gera cerca de $45 apenas em processamento do NAT.

Ao acessar o S3 e o DynamoDB, dê preferência à configuração de um Gateway VPC Endpoint:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxx \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-xxxx \
  --vpc-endpoint-type Gateway

Geralmente, o Gateway Endpoint não cobra tarifa por hora e também reduz o tráfego que passa pelo NAT. Após a alteração, verifique a route table para confirmar que a prefix list do S3 aponta para o endpoint.

7. Compressão: Compressão no Lado da Aplicação vs. Gateway Transparente

A compressão é a otimização de capacidade mais direta, mas depende do tipo de dado. Logs em Parquet, ORC ou compactados com gzip, além de imagens e vídeos, geralmente já estão comprimidos, oferecendo ganho limitado. No entanto, JSON, CSV, logs de texto, objetos não compactados e alguns arquivos de backup podem apresentar retornos significativos.

A vantagem da compressão no lado da aplicação é a arquitetura simples e sem gateways adicionais; a desvantagem é a necessidade de alterar código, lidar com compatibilidade e migrar dados históricos. Outra abordagem é o gateway de compressão transparente: a aplicação continua utilizando a API do S3, mas aponta o cliente para o gateway, que fica responsável por comprimir os dados antes de gravá-los no S3.

O S4 (Squished S3) pertence a essa última categoria. Ele é uma EC2 AMI que inclui o codec GPU NVIDIA nvCOMP, rodando em instâncias de GPU como g4dn/g5/g6; após apontar o cliente S3 para o gateway transparente, geralmente é possível reduzir de 50% a 80% dos bytes de armazenamento do S3 para dados compactáveis, sem necessidade de alterar o código da aplicação. Ele não é ideal para todos os cenários: se os dados já estiverem compactados, os objetos forem pequenos ou se houver altíssima taxa de requisições com volume total baixo, o ganho pode não ser significativo. O cenário ideal para avaliação é: grande volume de dados textuais ou semiestruturados no S3, onde o custo de capacidade é o principal gargalo e não se deseja alterar a aplicação.

Você pode fazer uma estimativa inicial usando a calculadora de economia do S4; ela não exige o envio de arquivos CSV de faturamento próprio, permitindo testar também com dados de exemplo.

Por fim: primeiro meça, depois altere a estratégia

Ordem recomendada de implementação:

1. Use o Cost Explorer para encontrar o principal usage type do S3.
2. Use o S3 Storage Lens para analisar a distribuição de buckets, prefix, versões e tamanho dos objetos.
3. Primeiro, limpe as versões antigas e multipart incompletos.
4. Em seguida, configure o ciclo de vida, Endpoint e a otimização de requisições.
5. Por fim, avalie a compressão ou arquiteturas alternativas.

A redução de custos do S3 não se resume a “mover tudo para camadas frias”. A abordagem realmente eficaz consiste em analisar em conjunto o padrão de acesso aos dados, o tamanho dos objetos, o caminho das requisições e o período de retenção.

Divulgação: o autor deste artigo é da abyo software (desenvolvedora do S4, um produto de otimização de custos disponível no AWS Marketplace).