Imagem de Molnia
Ao gerenciar buckets do Amazon S3, ter métricas de armazenamento precisas é fundamental para controlar custos e planejar capacidade. Mas divergências nos tamanhos reportados podem acontecer, gerando confusão e possíveis erros na estimativa de custos. Este artigo traz um caso real de um de nossos clientes em que diferentes ferramentas da AWS mostraram tamanhos muito distintos para o mesmo bucket S3, e apresenta uma solução para calcular com precisão o consumo real de armazenamento.
Um de nossos clientes se deparou com uma divergência significativa ao revisar as métricas de armazenamento de um bucket específico:
- S3 Metrics e CloudWatch: indicavam mais de 220TB de armazenamento
- AWS CLI e a opção "Calculate total size" do S3: mostravam menos de 8TB
Essa diferença de 27 vezes no tamanho reportado acendeu o alerta sobre a precisão dos dados e o possível impacto nos custos.
Ao investigar, encontramos as seguintes configurações do bucket:
- Storage Class: todos os objetos estavam em S3 Standard
- Versionamento: não habilitado no bucket
- Lifecycle Rule: configurada para excluir objetos após 45 dias
À primeira vista, essas configurações não explicavam a enorme diferença nos tamanhos reportados, o que motivou uma análise mais aprofundada.
Para confirmar a divergência, começamos verificando as métricas do bucket S3 e do CloudWatch:
- Console do S3: revisamos as métricas de armazenamento do bucket
- CloudWatch: examinamos as métricas correspondentes ao bucket
As duas fontes indicavam, de forma consistente, que o bucket armazenava mais de 200TB de dados.
Métricas do bucket S3
Métricas do CloudWatch
Para investigar mais a fundo, usamos dois métodos adicionais para medir o armazenamento do bucket:
- Recurso "Calculate Total Size" no Console do S3
- Comando da AWS CLI para listar o conteúdo do bucket
Tanto o "Calculate total size" quanto o comando da AWS CLI mostraram que o bucket tinha 7,5TB de armazenamento, com mais de 6 milhões de objetos.
Usando o "Calculate total size" no bucket S3.
Resultado do "Calculate Total" do S3
Comando da AWS CLI para calcular o tamanho do bucket:
aws s3 ls — summarize — human-readable — recursive s3://
Esse comando lista todos os objetos do bucket especificado e exibe um resumo do tamanho total.
Saída da AWS CLI
O contraste gritante nos tamanhos reportados criou um mistério e tanto: como o mesmo bucket podia mostrar volumes de dados tão diferentes? A divergência pedia uma investigação mais profunda, já que poderia impactar bastante o controle de custos e o planejamento de armazenamento. Para desvendar o enigma, seguimos os passos abaixo:
- Habilitar o S3 Storage Lens: recomendamos ao cliente habilitar o Amazon S3 Storage Lens, um recurso robusto de análise de armazenamento em nuvem. A ferramenta dá visibilidade em toda a organização sobre o uso e as tendências de atividade no armazenamento de objetos.
- Aguardar a coleta de dados: vale lembrar que o S3 Storage Lens pode levar até 24 horas para coletar e publicar as métricas.
- Analisar os resultados: assim que os dados ficaram disponíveis, examinamos com calma o dashboard do S3 Storage Lens. Os insights da ferramenta foram fundamentais para a investigação.
S3 Storage Lens mostrando o tamanho total dos Incomplete Multipart Uploads.
O S3 Storage Lens revelou que a causa da divergência estava nos S3 Incomplete Multipart Uploads.
Os S3 Incomplete Multipart Uploads são partes de objetos que foram enviadas parcialmente, mas nunca concluídas. O ponto-chave é que esses uploads incompletos consomem espaço e geram cobrança, mesmo sem aparecer nas listagens padrão do bucket.
O tamanho dos Incomplete Multipart Uploads passava de 200TB. A diferença entre as ferramentas acontece porque a operação "Calculate total size" no console do S3 e o comando da AWS CLI não consideram os Incomplete Multipart Uploads.
Ao identificar o problema, conseguimos explicar a enorme diferença entre os tamanhos reportados e indicar um caminho para otimizar o uso do armazenamento S3 do cliente.
Para ajudar o cliente a limpar o bucket, configuramos a lifecycle rule do S3 chamada "delete-incomplete-mpu-7-days" para excluir os Incomplete Multipart Uploads.
Lifecycle Rule do S3 para excluir Incomplete Multipart Uploads
Depois de deixar a lifecycle rule "delete-incomplete-mpu-7-days" rodar por alguns dias e dar tempo para as métricas do CloudWatch se atualizarem, voltamos a checar as métricas do bucket. Confirmamos que a regra funcionou e removeu todos os Incomplete Multipart Uploads. Em seguida, comparamos as métricas de armazenamento nas mesmas ferramentas, e os valores reportados para o bucket finalmente se alinharam.
Métricas do bucket S3 depois de aplicar a lifecycle rule
Métricas do CloudWatch depois de aplicar a lifecycle rule
Usando o "Calculate total size" do S3 depois de aplicar a lifecycle rule "delete-incomplete-mpu-7-days".
Usando o "Calculate total size" no bucket S3.
"Calculate total size" do S3 depois de aplicar a lifecycle rule
Script com a AWS CLI para calcular o tamanho do bucket depois de aplicar a lifecycle rule
Este estudo de caso é só um exemplo dos desafios complexos que as empresas enfrentam ao gerenciar seus ambientes AWS. Aplicando nossa expertise em serviços AWS e nossa capacidade de analisar e interpretar métricas de nuvem, descobrimos a causa raiz da divergência no tamanho do armazenamento e entregamos uma solução eficaz. Isso não só resolveu o problema imediato como deu ao cliente uma visão muito mais clara sobre o uso e os custos do armazenamento S3.
Na DoiT International, somos especialistas em ajudar empresas a navegar pelas complexidades dos ambientes em nuvem, resolver problemas e otimizar a infraestrutura AWS. Se você está lidando com divergências parecidas em métricas de armazenamento ou outros desafios na nuvem, nosso time de especialistas está pronto para ajudar. Não deixe que a complexidade da nuvem atrapalhe suas operações. Fale com a DoiT hoje mesmo e descubra como podemos ajudar você a extrair o máximo de eficiência e custo-benefício do seu ambiente em nuvem, garantindo o melhor retorno sobre o seu investimento em AWS.