Na cloud clássica, crescer costuma significar mais egresso e mais fatura. Edge com zero egresso inverte a lógica: processar perto do dado, cortar latência e reduzir transferência entre regiões.

Cloud central vs edge

Serverless tradicional roda em poucas regiões, com cold start maior. Edge roda em muitos PoPs, perto do usuário, com cold start baixo (isolates).

Cloud centralEdge
Distância do usuárioAltaBaixa (ms)
Cold startMaiorMuito baixo
EgressoCobra saída entre regiões/serviçosPode zerar com storage sem egresso

Segundo a Flexera, egresso já pesa uma fatia relevante da fatura em workloads de volume [2]. Em mídia/telemetria, pode dominar o custo.

O que é zero egresso

Processar o dado onde ele já está. Ex.: objetos em R2 sem cobrança de saída, workers no mesmo ecossistema — em contraste com S3/GCP cobrando por GB transferido [1].

Três padrões de adoção

1. Edge middleware (dias)

Origin igual. Edge na frente: auth, feature flag, roteamento. TTFB cai forte para audiência distribuída. Egresso cai só em parte.

2. Edge + KV (semanas)

Leitura frequente no KV global (flags, sessão leve, config). Trade-off: consistência eventual. Se precisa de consistência forte na leitura, não force.

3. Edge-native (projetos novos)

Compute + storage sem egresso + DB/estado na borda. Ideal para API de alto volume e lógica leve. Ruim para CPU pesada, Node completo ou transação complexa.

Comece no 1. Evolua para o 2. O 3 é destino, não partida.

O que não colocar no edge

  • CPU acima do limite do runtime (hard kill)
  • Consistência forte em toda leitura
  • Debugging/observabilidade sem ferramenta adequada
  • Lógica esporádica e pesada

Regra prática: stateless + leve + alta frequência → edge. Falhou um critério → mantenha na origin.

Decisão

Qual parte da lógica é leve e roda em toda request (auth, roteamento, personalização)? Essa parte não precisa viver longe do usuário.

Quer discutir o caminho na sua stack? Assessment.


Fontes

[1] Amazon Web Services, “Data Transfer Pricing,” aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer.

[2] Flexera, “State of the Cloud Report,” 2024. Disponível em: flexera.com/blog/cloud/cloud-computing-trends/.