Como a Azion reduz custos de nuvem e egress

Egress é o imposto invisível da nuvem. Ao mover o compute e o caching para mais perto dos usuários, você reduz os bytes e requisições encaminhados à origem — e imediatamente encolhe as faturas de nuvem enquanto melhora a experiência do usuário.

Este artigo sintetiza benchmarks, transformações empresariais e padrões práticos para mostrar como a Plataforma Web da Azion possibilita reduções substanciais no egress de origem, latência e gastos com observabilidade — frequentemente na faixa de 50% a 75%.

Por que o Egress é o novo motor de custos da nuvem

A maioria das conversas sobre custos de nuvem começa com compute e storage. Elas deveriam começar com egress. Cada byte que você envia da origem para a internet pública se transforma em uma cobrança mensal recorrente.

Em regiões com trânsito caro (LATAM, partes da APAC), o egress frequentemente se torna o item de custo de crescimento mais rápido em uma fatura de nuvem.

Em dezenas de implementações, emerge um padrão repetido: introduzir Pontos de Presença (POPs) locais, servir conteúdo cacheável e fragmentos dinâmicos de curta duração por meio de uma rede distribuída, filtrar tráfego ruidoso e comprimir payloads.

O restante deste artigo explica como e por que — com padrões acionáveis e pseudocódigos executáveis que você pode usar como ponto de partida.

Anatomia do custo de Egress e Inter-Região

As próprias planilhas de preço das public clouds deixam claros os fatores de custo:

• Egress para a internet é cobrado por GB e por região (tipicamente $0.02–$0.09/GB, dependendo do nível e da geografia).
• Transferências inter-regionais adicionam custos adicionais por GB.
• Cobranças por Gateways, load balancers e APIs por requisição podem adicionar custos significativos em arquiteturas “tagarelas” (chatty).

Como o egress é proporcional aos bytes e à geografia do tráfego, reduzir os bytes que saem da origem se traduz em grandes economias mensais compostas.

Para uma aplicação que trafega 100 TB/mês, uma redução de 70% no egress de origem pode economizar dezenas de milhares de dólares por mês — e essas economias escalam com o uso.

Impactos observados

• Redução de egress na origin: 60–90%
• Cache-hit ratio: de 20–40% para 70–95% com microcaching e TTLs inteligentes
• Latência: −30% a −80% com POPs locais + HTTP/3
• Economia de largura de banda via compressão: 30–70% em payloads textuais
• Redução de observabilidade: 30–60% com amostragem e agregação distribuídas

Esses intervalos são extraídos de transformações de clientes anonimizados, benchmarks de plataforma e pesquisas públicas. Os resultados reais dependem da combinação de tráfego, tipos de payload e cacheabilidade.

Um caso real de Caching que gera economia

Para ilustrar o impacto estrutural de mover a lógica, o caching e o conteúdo para uma infraestrutura distribuída, considere um caso público da Dafiti — uma das maiores plataformas de e-commerce de moda da América Latina.

A Dafiti atende mais de 7,7 milhões de clientes ativos no Brasil, Argentina, Chile e Colômbia, com receita anual multibilionária em reais e um negócio fortemente dependente de carregamentos rápidos de página, catálogos ricos em imagens e alto uso móvel. Com o aumento das compras online durante a pandemia, o desempenho e a escalabilidade se tornaram fatores competitivos decisivos.

Desafio

A Dafiti utilizava um fornecedor global de CDN até 2020. Apesar da escala, a solução legada enfrentava dificuldades com:

• Tempos de carregamento lentos na América do Sul (TTFB - Time to First Byte, throughput, degradação do LCP - Largest Contentful Paint);
• Alto egress de origem devido à eficiência limitada do caching;
• Consumo caro de transferência de dados;
• A necessidade de processar milhões de imagens de produtos em alta resolução sem prejudicar a experiência do usuário (UX).

Com a experiência do cliente sendo o principal motor de conversão no Brasil (89%), Colômbia (84%) e Argentina (77%), melhorar o desempenho e reduzir custos tornou-se uma prioridade estratégica.

Ações Tomadas

A Dafiti migrou para a Plataforma Web da Azion, construída em mais de 100 localizações distribuídas, com foco em desempenho, disponibilidade e eficiência de custos. Através de uma prova de conceito estruturada e implementação completa (full rollout), a Dafiti adotou:

• Application Acceleration com caching em múltiplas camadas;
• Tiered Cache para reduzir o egress de origem;
• Image Processor para otimização em tempo real de mais de 17 milhões de imagens;
• Functions para executar lógica de negócio, personalização e testes A/B próximos aos usuários;
• Entrega distribuída em todos os domínios LATAM (AR, BR, CL, CO).

Resultados

Dentro da primeira fase de implementação, a Dafiti observou:

• 86% mais rapidez no tempo de carregamento em comparação com sua CDN legada (18,33s $\rightarrow$ 2,44s);
• 550 TB de transferência de dados descarregados da origem em um único mês;
• 45% de redução nos custos de transferência de dados na nuvem;
• 75% de redução no tamanho médio dos pacotes de imagens;
• Mais de 40 aplicações criadas nos primeiros dois meses, melhorando a UX em web e mobile;
• Melhor escalabilidade e resiliência durante picos regionais de tráfego.

Impacto no negócio

Esses ganhos apoiaram diretamente a missão da Dafiti de oferecer uma experiência de compra fluida e visualmente rica em toda a América do Sul — aumentando o potencial de receita, fortalecendo a posição competitiva e reduzindo os gastos com infraestrutura simultaneamente.

Essa transformação pública demonstra o mesmo padrão observado em implementações modernas: quando o compute, o caching e a otimização se deslocam para uma infraestrutura distribuída, as organizações simultaneamente reduzem o egress de origem, melhoram a latência e diminuem as contas de nuvem — muitas vezes de forma drástica.

O que possibilitou esses resultados

Arquiteturas distribuídas mudam onde o trabalho e os bytes residem. Os mecanismos a seguir são alavancas repetíveis:

• Camadas de cache e microcaching: usar TTLs longos para ativos imutáveis (imagens, segmentos), aplicar TTLs adaptativos para peças dinâmicas e empregar stale-while-revalidate para mascarar falhas na origem (origin flaps).
• Offload de compute: executar lógica leve (autenticação, personalização, montagem de manifest) em nós distribuídos para evitar que muitas requisições cheguem à origem.
• Compressão e protocolos: aplicar Brotli para payloads de texto e adotar HTTP/3 para reduzir a latência de handshake.
• Filtragem de bots e API shielding: bloquear ou limitar a taxa de tráfego abusivo antes de incorrer em egress da origem.
• Filtragem de observabilidade: amostrar, agregar e encaminhar apenas a telemetria essencial para o storage central.

Boas práticas de Microcaching

A seguir, alguns padrões práticos para aplicar microcaching com eficiência em conteúdo dinâmico:

• Use TTLs sub-minuto para conteúdo dinâmico que é caro de computar, mas seguro para ser armazenado em cache brevemente (ex: snapshots de portfólio).
• Agrupe chaves de cache por permissão de usuário ou variante de dispositivo para manter as taxas de acerto altas e evitar vazamento de dados.
• Combine s-maxage com stale-while-revalidate para manter a UX fluida durante lentidões na origem.

Código: Microcaching + Fetch com conscientização de Brotli (Pseudocódigo de Function)

Observação sobre o modelo de plataforma: os exemplos abaixo são pseudocódigos alinhados com APIs estilo Service Worker / Function (Azion Functions e runtimes similares). Eles devem ser adaptados ao SDK específico de sua plataforma.

// Function: microcache + origin fetch that advertises accept-encoding
export default async function handler(request, event) {
  const auth = request.headers.get('authorization') || '';
  const userHash = hash(auth); // keep this deterministic and privacy-safe
  const cacheKey = `portfolio:${userHash}`;

  // Attempt to serve from cache
  const cached = await caches.default.match(cacheKey);
  if (cached) {
    // Return cached response (preserves headers set at store time)
    return cached.clone();
  }

  // Fetch from origin, advertise Brotli/Gzip support
  const originResp = await fetch(`${ORIGIN}/portfolio`, {
    headers: { 'authorization': auth, 'accept-encoding': 'br, gzip, deflate' }
  });

  // Read origin response body
  const body = await originResp.arrayBuffer();

  // Construct a response with Cache-Control directives for for distributed nodes
  const response = new Response(body, {
    status: originResp.status,
    headers: {
      'Content-Type': originResp.headers.get('content-type') || 'application/json',
      // s-maxage for edge caches; stale-while-revalidate to smooth UX
      'Cache-Control': 's-maxage=30, stale-while-revalidate=60'
    }
  });

  // Write to cache non-blocking
  event.waitUntil(caches.default.put(cacheKey, response.clone()));
  return response;
}

Notas: Não defina manualmente o Content-Encoding a menos que você esteja, de fato, comprimindo o payload na borda; em vez disso, anuncie o Accept-Encoding para a origem e dependa da compressão integrada da plataforma ou realize a compressão explícita dentro da function se o runtime permitir.

Código: Montagem de manifest na Borda (device-aware)

// Pseudocode: assemble a video manifest variant per device on distributed nodes
export default async function handleRequest(request, event) {
  const ua = request.headers.get('user-agent') || '';
  const device = /Mobile|Android|iPhone/i.test(ua) ? 'mobile' : 'desktop';
  const videoId = /* extract param from URL or route */ extractVideoId(request);
  const manifestKey = `/manifests/${device}/${videoId}.json`;

  const cached = await caches.default.match(manifestKey);
  if (cached) return cached.clone();

  const baseResp = await fetch(`${ORIGIN}/base-manifest/${videoId}`);
  const data = await baseResp.json();

  // Tailor profile to device
  data.profile = device === 'mobile' ? data.profileMobile : data.profileDesktop;

  const body = JSON.stringify(data);
  const response = new Response(body, {
    headers: {
      'Content-Type': 'application/json',
      'Cache-Control': 's-maxage=30'
    }
  });

  event.waitUntil(caches.default.put(manifestKey, response.clone()));
  return response;
}

Estes exemplos são intencionalmente mínimos; em produção, você deve adicionar tratamento de erros, normalização da chave de cache e hooks de observabilidade (métricas de borda) para poder medir as taxas de acerto e as economias de egress.*

Arquitetura: Centralizada vs Distribuída

FinOps, Telemetria e Automação

A telemetria distribuída permite políticas de custo mais inteligentes:

• Métricas em tempo real podem acionar regras automatizadas (ex: aumentar TTLs, limitar (throttle) endpoints, impor rate limits quando o egress dispara).
• Amostragem e agregação através da rede distribuída cortam os custos de ingestão enquanto preservam o sinal.
• Combine deployment gates com alertas de orçamento para detectar regressões precocemente.

Checklist de piloto de 30 Dias

Antes de iniciar a otimização, siga este checklist para estruturar um piloto consistente, medir impacto real e validar ganhos de performance e custo:

1. Identifique seus 3 endpoints de origem mais pesados (por bytes e requisições).
2. Capture baselines (linhas de base) por 30 dias: egress de origem (GB), requisições de origem, taxa de acerto de cache, latência mediana/p95, volume e custo de telemetria.
3. Implemente microcaching baseado em infraestrutura distribuída e uma function distribuída (autenticação, montagem de manifest ou snapshot de portfólio).
4. Habilite Brotli e HTTP/3 na infraestrutura distribuída.
5. Adicione filtragem de bots / API shielding na borda para endpoints ruidosos.
6. Execute medição A/B por pelo menos 2 semanas e compare custos e métricas de UX.
7. Estenda para os 10 principais endpoints mais caros e integre regras FinOps automatizadas.

Implicações de negócio e mudança estrutural

Uma arquitetura nativamente distribuída é mais do que uma otimização técnica — é uma mudança estrutural na economia da nuvem.

• Em vez de negociar descontos de trânsito entre regiões, as empresas podem evitar esses bytes inteiramente.
• Equipes de produto lançam mais rápido com melhor UX (latências locais).
• Equipes de segurança bloqueiam o abuso antes que ele se torne uma fatura.
• Finanças ganha previsibilidade em itens de egress menores.

Para empresas em regiões sensíveis a custos (LATAM, APAC), essa vantagem estrutural se traduz em um custo unitário por usuário ativo mais baixo e maior flexibilidade de preço.