Egress: a linha da fatura que ninguém projeta

Existe uma assimetria curiosa no modelo de cobrança da nuvem: colocar dado para dentro é grátis, tirar dado para fora é pago. Não é acidente — é o que torna a migração de entrada fácil e a de saída cara.

Para a maior parte das aplicações, o valor é pequeno e passa despercebido. Ele deixa de passar despercebido exatamente quando o produto dá certo: mais usuários, mais páginas, mais arquivos baixados. É a única linha da fatura que sobe junto com o sucesso, e a única que ninguém projetou.

O que conta como saída

A regra geral é que sai da rede do provedor e vai para a internet. Mas há variações que custam caro quando ignoradas:

• Servidor para internet. Toda resposta HTTP, imagem, download, resposta de API. É o volume principal.
• Entre regiões do mesmo provedor. Réplica de banco em outra região é tráfego cobrado, e contínuo.
• Entre zonas de disponibilidade. Alguns provedores cobram até dentro da mesma região. Uma aplicação em uma zona conversando com o banco em outra paga por requisição.
• De storage para fora. Servir arquivo direto do bucket para o navegador é egress do bucket.
• Por meio do balanceador ou do NAT. Além do custo do recurso, o volume também é cobrado.

As duas do meio são as que produzem as faturas mais confusas, porque ninguém pensa em tráfego interno como tráfego. Uma arquitetura distribuída por zonas "para ter resiliência" pode gerar mais custo de rede do que o serviço inteiro consumia antes.

Descobrir o seu volume real

Antes de decidir qualquer coisa, meça. O número costuma ser bem diferente da intuição.

Do lado do servidor, o vnstat acumula histórico com custo próximo de zero:

sudo apt install vnstat
sudo systemctl enable --now vnstat

vnstat -m        # por mês
vnstat -d        # por dia
vnstat -t        # os dias de maior volume

A coluna que importa é tx — transmitido, ou seja, saída. A rx é entrada e normalmente não é cobrada.

Se o servidor é web, o log do nginx diz o que está saindo, que é a informação acionável:

sudo awk '{s[$7]+=$10} END {for (u in s) printf "%.1f MB  %s\n", s[u]/1048576, u}' \
  /var/log/nginx/access.log | sort -rn | head -20

O resultado quase sempre concentra em poucos itens: um vídeo na home, um PDF de catálogo, imagens sem compressão, ou um endpoint de API que devolve muito mais campo do que o cliente usa.

As causas mais comuns, em ordem

Depois de medir, o padrão se repete de projeto para projeto:

• Imagem sem otimização. Foto de 4 MB direto da câmera exibida em miniatura de 300 px. Converter para WebP ou AVIF e gerar tamanhos derivados costuma cortar 70% do volume total do site.
• Ausência de cache no navegador. Sem Cache-Control, cada visita rebaixa tudo. Um cabeçalho de trinta dias em arquivo estático elimina a maior parte das repetições.
• Compressão desligada. HTML, CSS, JS e JSON comprimem entre 70% e 90%. É uma linha de configuração.
• API conversadora. Endpoint que devolve o objeto inteiro quando a tela usa três campos multiplica o tráfego por cliente ativo.
• Backup saindo para fora. Enviar dump diário para armazenamento em outro provedor é egress todo dia, para sempre.
• Bot e raspagem. Parte relevante do tráfego de saída de muitos sites não é gente. Vale olhar o User-Agent no log antes de culpar o crescimento.

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/json
           application/javascript text/xml image/svg+xml;

location /static/ {
    expires 30d;
    add_header Cache-Control "public";
}

Essas duas configurações, sozinhas, costumam cortar metade do volume de um site comum. É o melhor retorno por esforço que existe nesse tema.

Onde a arquitetura ajuda

Depois do ganho fácil, as decisões estruturais:

Sirva estático de onde é mais barato. Arquivo grande — vídeo, PDF, imagem de produto — não precisa passar pela VM. Colocá-lo em um bucket S3 tira o tráfego do servidor, reduz a carga da aplicação e simplifica o deploy, que deixa de carregar mídia junto.

Mantenha o que conversa muito no mesmo lugar. Aplicação e banco na mesma rede interna trocam volume alto e não deveriam pagar por isso. Réplica em outra região é uma decisão de continuidade de negócio com custo recorrente de rede — legítima quando é isso que se quer, cara quando foi acidente de arquitetura.

Use CDN para audiência distribuída. Se o público está espalhado, a CDN serve do ponto mais próximo e reduz tanto o egress do servidor quanto a latência. Se o público é todo brasileiro e o servidor está no Brasil, o ganho é menor — e vale medir antes de adicionar mais uma peça.

Cuidado com egress de saída de fornecedor. Ao migrar de provedor, o custo de tirar os dados é do provedor de origem. Um arquivo histórico grande pode transformar a migração em despesa relevante. Vale consultar a política de saída antes de começar.

Estimar antes de lançar

Medir serve para o que já existe. Para o que ainda vai ao ar, dá para estimar com aritmética simples e chegar perto o suficiente.

O modelo tem três entradas: peso de uma sessão típica, número de sessões e fator de repetição.

Comece pelo peso. O navegador informa o total transferido de uma visita na aba de rede das ferramentas de desenvolvedor. Ou pela linha de comando, somando o que uma página carrega:

curl -s -o /dev/null -w '%{size_download}\n' https://meusite.com.br/

Com o peso em mãos, a conta mensal é direta. Uma página de 2,5 MB, com 50 mil visitas por mês e 3 páginas por visita, gera cerca de 375 GB. Com cache bem configurado, a partir da segunda página o visitante baixa só o HTML e os dados — talvez 200 KB —, e o mesmo tráfego cai para cerca de 150 GB.

Repare no tamanho do efeito: a mesma audiência, com a mesma aplicação, consumindo menos da metade por causa de um cabeçalho de cache. É a razão de a otimização vir antes da negociação de tarifa.

Depois, some o que não é visita:

• Downloads diretos. Um PDF de 8 MB baixado 2 mil vezes são 16 GB, sozinho.
• API de aplicativo móvel. Costuma ter volume por usuário muito maior que a web, porque sincroniza em segundo plano.
• Backup e replicação que saem da rede.
• Margem para pico. Trabalhe com 1,5× a estimativa. Mês de campanha não se comporta como mês comum.

Guarde essa estimativa junto da projeção de crescimento. Quando o número real divergir muito do previsto, a diferença é informação — quase sempre aponta para um arquivo pesado que entrou no caminho, ou para tráfego que não é de gente.

Por que previsibilidade importa mais que preço por GB

Comparar centavos por gigabyte leva à discussão errada. O que dói em tráfego não é a tarifa, é a variação.

Uma campanha de marketing que funciona bem, um vídeo que viraliza, um cliente novo que faz integração pesada — qualquer um desses multiplica o volume em um mês específico. Se a tarifa é por consumo sem teto, a fatura acompanha, e o time descobre depois do fato.

É por isso que franquia generosa ou tráfego incluído mudam o planejamento mais que uma diferença de tarifa: transformam uma variável em constante. Para quem embute infraestrutura no preço de um serviço, isso é a diferença entre margem previsível e margem que depende de quanto o cliente usou.

Vale ler junto a conta completa da cloud em dólar — egress é justamente uma das linhas que não aparecem na calculadora e reaparecem na fatura.

O que fazer nesta semana

Uma sequência curta e de retorno rápido:

• Instale o `vnstat` e deixe acumular. Sem histórico, qualquer conclusão é palpite.
• Ligue compressão e cache de estático. Quinze minutos de trabalho.
• Rode o `awk` do log e olhe os dez maiores. Costuma haver um item respondendo por boa parte do volume.
• Mova mídia pesada para bucket, deixando o servidor com aplicação.
• Revise o destino dos backups. Se o dump sai da rede todo dia, avalie manter a cópia dentro do mesmo ambiente e usar a saída só para a cópia externa periódica — o que o script de backup para bucket já contempla com retenção.

Feito isso, o egress deixa de ser a surpresa do mês e vira uma linha que você projeta como qualquer outra — e o mais provável é que ela encolha bastante no caminho, porque quase todo site serve mais bytes do que precisa.