O Ralo Invisível da Fatura AWS
Se você já abriu a fatura da AWS no final do mês e ficou confuso com uma linha chamada “Data Transfer OUT to Internet”, você não está sozinho. Transferência de dados é, historicamente, uma das maiores surpresas para equipes que ainda não configuraram uma CDN adequadamente.
O problema não é o tráfego em si é de onde ele sai. Cada vez que um usuário no Brasil acessa um arquivo armazenado em us-east-1, a AWS cobra pela transferência de dados saindo da região. Se você tem milhares de usuários fazendo isso dezenas de vezes por dia, o valor cresce silenciosamente.
A solução? Amazon CloudFront, a CDN (Content Delivery Network) nativa da AWS, com mais de 600 pontos de presença espalhados pelo mundo, incluindo São Paulo.
1. Entenda o que o CloudFront realmente faz (e por que barateia tudo)
Muita gente pensa no CloudFront apenas como “aquele serviço para entregar sites mais rápido”. Mas o impacto financeiro é tão importante quanto o de performance.
Quando você coloca o CloudFront na frente de um bucket S3 ou de uma instância EC2, o que acontece é:
- O usuário solicita um arquivo (uma imagem, um vídeo, um JSON de API).
- O CloudFront verifica se tem esse conteúdo em cache no Edge Location mais próximo do usuário (em São Paulo, por exemplo).
- Se tiver: entrega direto, sem cobrar transferência de dados da sua origem.
- Se não tiver: busca na origem uma única vez, armazena em cache e entrega. Apenas essa primeira busca gera custo de transferência da origem.
O ponto-chave: a transferência entre a origem AWS (S3, EC2, ALB) e o CloudFront tem custo reduzido e em muitos casos, zero. Quem paga a transferência padrão é o tráfego saindo diretamente da origem para o usuário final, sem CDN.
Na prática, para conteúdo estático com boa taxa de acerto de cache (Cache Hit Ratio), empresas reportam reduções de 60% a 80% na linha de Data Transfer da fatura.
2. Configure sua Distribuição com os parâmetros certo
Criar uma distribuição no CloudFront leva menos de 10 minutos, mas a diferença entre uma configuração padrão e uma otimizada é enorme.
Defina o TTL (Time to Live) de forma inteligente
O TTL determina por quanto tempo o CloudFront mantém o conteúdo em cache antes de buscar novamente na origem. O erro mais comum é deixar o valor padrão (24 horas) para tudo, ou pior, colocar TTL zero (desabilitando o cache).
A estratégia correta é segmentar por tipo de conteúdo:
- Arquivos estáticos versionados (imagens, CSS, JS com hash no nome): TTL longo 30 dias ou mais. Se o arquivo mudar, o nome muda junto, então o cache nunca fica desatualizado.
- HTML e páginas de entrada: TTL curto 5 a 10 minutos. Você precisa que mudanças de conteúdo cheguem rápido ao usuário.
- Respostas de API: TTL personalizado por rota. Endpoints de dados dinâmicos podem ter TTL zero. Endpoints de dados que mudam raramente (listas de categorias, configurações) podem ter 5 minutos.
Ative a compressão automática
Com um clique na configuração da distribuição, o CloudFront passa a comprimir automaticamente arquivos elegíveis (HTML, CSS, JS, JSON, XML) usando Gzip ou Brotli antes de entregar ao usuário. Isso reduz o tamanho da transferência em 60% a 80% para arquivos de texto menos bytes transferidos, menos custo, mais velocidade.
3. Use Origin Shield para proteger sua origem de picos
Imagine que seu conteúdo não está em cache e 50 servidores de borda do CloudFront ao redor do mundo recebem simultaneamente uma requisição pelo mesmo objeto. Sem Origin Shield, todos os 50 servidores vão bater na sua origem ao mesmo tempo um fenômeno chamado de “thundering herd”.
O Origin Shield é uma camada intermediária de cache centralizada que consolida essas requisições. Em vez de 50 chamadas simultâneas chegando na sua origem, apenas uma passa. As outras 49 aguardam o resultado do cache regional.
Os benefícios são duplos:
- Proteção contra picos de tráfego na origem (menos chance de sobrecarregar um EC2 ou de aumentar o RCU do DynamoDB).
- Redução de custo de transferência, porque a origem responde muito menos vezes.
Para ativar, basta selecionar a região geográfica mais próxima da sua origem nas configurações do CloudFront. Para origens em sa-east-1 (São Paulo), escolha a região de São Paulo como Origin Shield.
4. Monitore o Cache Hit Ratio e aja sobre ele
De nada adianta ter o CloudFront configurado se você não sabe se ele está realmente funcionando. A métrica mais importante é o Cache Hit Ratio, a porcentagem de requisições respondidas diretamente pelo cache, sem bater na origem.
Você encontra essa métrica no painel do CloudFront no Console da AWS, em “Reports & analytics” > “Cache statistics”.
O que é um Cache Hit Ratio saudável?
- Abaixo de 50%: Algo está errado. Provavelmente TTL muito baixo, ou o CloudFront está recebendo muitos parâmetros de query string variados que criam chaves de cache únicas demais.
- Entre 70% e 85%: Razoável para aplicações com conteúdo misto (estático + dinâmico).
- Acima de 90%: Excelente. Sua fatura de egresso agradece.
Como melhorar o Cache Hit Ratio
O problema mais comum é a fragmentação de cache por query string. Se sua URL é https://cdn.suaempresa.com/imagem.jpg?v=1&user=12345×tamp=1714167890, o CloudFront entende isso como um objeto completamente diferente de imagem.jpg?v=1&user=99999×tamp=1714167891. Cada combinação cria uma entrada única no cache.
A solução é configurar o CloudFront para ignorar parâmetros de query string irrelevantes para o conteúdo através das Cache Policies. Mantenha apenas os parâmetros que realmente alteram o conteúdo entregue.
Conclusão
O CloudFront não é apenas uma ferramenta de performance, é uma decisão de engenharia financeira. Configurá-lo com TTLs inteligentes, Origin Shield ativo e monitoramento constante do Cache Hit Ratio é a diferença entre uma fatura previsível e uma surpresa no fim do mês.
Se o seu ambiente AWS ainda não tem uma distribuição CloudFront na frente dos recursos mais acessados, você está, literalmente, pagando mais do que precisa.
