Custos de Egress na Nuvem em 2026: Por Que a Conta Não Fecha Mais

Em 2020, migrar para a nuvem significava economizar dinheiro. Em 2026, as contas são outras.

A adoção de cloud atingiu seu pico por volta de 2021. Em toda entrevista com CTO, em todo keynote do re:Invent, o argumento era o mesmo: migre, modernize, economize. E por um tempo, isso era verdade. Empresas saindo de hardware on-prem antigo conseguiam cortar custos, às vezes de forma expressiva.

Mas os preços não ficaram parados. As taxas de egress do AWS S3 subiram. O GCP cortou descontos por uso contínuo. O pricing de bandwidth do Azure mudou silenciosamente. Nada disso virou manchete. Só apareceu na fatura todo mês, acumulando.

Coletamos dados de pricing AWS, GCP e Azure, testados contra três padrões reais de arquitetura: uma plataforma SaaS, um time que fez tudo certo no FinOps, e uma API global. O mesmo problema apareceu nos três casos, só com roupagens diferentes.

Resumo: O preço por GB de egress mal se moveu desde 2020, mas o volume de dados das aplicações cresceu de 3 a 7 vezes. Uma empresa SaaS de médio porte movendo 50 TB por mês fora da AWS paga US$ 54.000 por ano só em bandwidth. Rotear workloads stateless por uma rede distribuída reduz essa conta em 60 a 80% sem mexer no banco de dados nem refazer a arquitetura.

---

Por que os custos de egress da AWS continuam crescendo desde 2020

A AWS cobrava US$ 0,09/GB saindo de us-east-1 em 2020. Em 2026, esse número ainda é US$ 0,09. É aí que o “nada mudou” acaba.

O volume de dados cresceu. As bases de usuários se tornaram globais. As aplicações ficaram mais real-time: mais chamadas de API, mais conexões WebSocket, mais entrega de mídia. O multiplicador de egress de uma aplicação moderna é de 3 a 7 vezes o que os times projetaram nos planos de migração de 2020. O preço unitário ficou parado enquanto o volume multiplicava sem chamar tanta atenção.

Uma empresa SaaS movendo 50 terabytes fora da AWS por mês paga cerca de US$ 4.500 por mês em egress. São US$ 54.000 por ano. De bandwidth. Só bandwidth. Roteie esse mesmo tráfego por uma rede distribuída com pontos de presença globais e a conta cai de 60 a 80%. Mesmos 50 TB. Mesmos usuários. Caminho diferente.

---

Quais arquiteturas cloud estão mais expostas às taxas de egress

O caso SaaS é o mais comum. App server em uma região, banco de dados na mesma região, CDN acoplado por cima. Multi-region foi uma consideração tardia, quando aconteceu. Era a arquitetura que fazia sentido em 2020.

O problema de latência é estrutural. Um usuário em São Paulo acessando uma API em us-east-1 já tem 120 a 180ms de round-trip só pela geografia, antes de qualquer lógica da aplicação rodar. Para autocomplete, dashboards em tempo real ou edição colaborativa, isso quebra o produto. Mover toda a aplicação não resolve; mover a camada stateless resolve. O cache de API, a camada de auth e a entrega de assets estáticos conseguem responder em 30ms. O banco de dados fica onde está.

O caso FinOps é mais frustrante porque o time fez tudo certo. Right-sizing, corte de recursos ociosos, reserved instances: feito com consistência, esse trabalho tira de 15 a 25% de uma conta bruta na nuvem. Mas tem um teto, e a maioria dos times bate nele antes de 18 meses. Ferramentas de FinOps conseguem mostrar de onde vem o egress. Elas não conseguem mudar o preço unitário; quem define isso é o provedor.

Um time de FinOps olhando para uma linha de US$ 25.000 em egress consegue tagear, rastrear e escalar o problema. No final desse processo, vão dizer que a única solução real é uma decisão de engenharia. Não dá pra otimizar uma arquitetura que roteia cada byte pelo cloud origin.

O caso da API global é o que mais surpreende os times. APIs internas, microsserviços se comunicando, data pipelines, integrações com terceiros: tudo isso gera egress. Cada resposta que sai da região é tráfego cobrado.

Times com microsserviços subestimam os custos de tráfego cross-region em cerca de 40% nas projeções iniciais. Em três anos, essa diferença vira um número que o CFO vai perguntar.

---

Três razões pelas quais a conta não é corrigida

A maioria dos engineering leaders que passam por esse cenário já sabe que algo está errado. Já viram os dashboards do CloudWatch e já tiveram a conversa com o financeiro. O problema não é falta de informação.

Viés do custo afundado. Se você liderou a migração para a nuvem, admitir que a equação econômica mudou parece admitir que você errou. Os times então esperam. Essa espera custa dinheiro real todo mês.

Ilusão de complexidade. Mexer na arquitetura parece um projeto de 12 meses com alta chance de quebrar algo em produção. Geralmente não é verdade, mas os vendors que se beneficiam da sua configuração atual não têm motivo para corrigir essa percepção.

Comparação com uma referência errada. A maioria dos times compara a conta de cloud com o que pagava on-prem cinco anos atrás. Essa baseline está obsoleta. As alternativas de hoje não são as mesmas de 2020.

Nenhum desses é um problema técnico.

---

Como auditar seus gastos com egress em menos de quatro horas

A auditoria leva de duas a quatro horas com os dashboards que você já tem abertos.

Qual percentual da sua conta mensal é egress? Acima de 15% você tem um alvo imediato. Acima de 25% você está perdendo dinheiro que não precisaria perder.

Qual é a latência média de API para usuários fora da sua região principal? Se você não souber o número de cabeça, essa já é uma resposta. Puxe do New Relic, Datadog ou qualquer ferramenta de observabilidade que você usa.

Quais workloads são stateless versus stateful? Workloads stateless (respostas de API, autenticação, entrega de assets, serverless functions) são candidatos a mover. Workloads stateful (bancos de dados, filas, armazenamento persistente) ficam. Essa é a linha de decisão.

Qual é o seu custo de egress por usuário ativo por mês? Seu cloud provider não vai mostrar esse número no console. Divida o custo total de egress pelos seus usuários ativos mensais. Se esse número cresce mais rápido que a receita por usuário, a arquitetura está trabalhando contra o negócio.

---

Stateless vs. stateful: onde a redução de custos de egress realmente acontece

Tipo de workload	Exemplos	Onde roda	Impacto no egress
Stateless	Respostas de API, auth, entrega de assets, edge functions	Rede distribuída	Baixo — o tráfego para de bater no cloud origin a cada request
Stateful	Bancos de dados, filas, armazenamento persistente	Cloud (sem mudança)	Contido — nenhuma alteração arquitetural necessária

O princípio é simples: workloads stateless ficam na rede distribuída, workloads stateful ficam na nuvem. A maioria dos times roda as duas camadas na nuvem por padrão, e é por isso que a conta de egress continua crescendo.

A rede distribuída da Azion roda Functions, WAF e controles de segurança de aplicação em mais de 100 localidades globalmente. Um usuário em São Paulo acessa em 15ms ao invés de 180ms. O egress cai porque o tráfego para de ser roteado pelo cloud origin a cada request. O banco de dados não se move. O time não precisa reconstruir a arquitetura do zero.

Times que fizeram essa divisão estão vendo reduções de egress de 60 a 80% e melhorias de latência de 40 a 60% fora da região principal. A mudança não é um rip-and-replace. É mover os 20% de workloads que respondem por 80% da conta de egress.

---

Em 2020, a resposta padrão era: coloca na nuvem. Em 2026, esse padrão é bem diferente.

A nuvem ainda é a escolha certa para workloads stateful. Para tudo que é stateless, egress-heavy e distribuído globalmente, a conta parou de fechar há algum tempo. A maioria dos times simplesmente não revisou isso.

Comece pelo egress como percentual da sua conta total. Puxe os dados de latência para usuários fora da sua região principal. Trace a linha stateless/stateful na sua arquitetura. Esses três números vão dizer se você tem um problema estrutural ou um problema de right-sizing — e só um deles é resolvível com uma ferramenta de FinOps.

Fale com um especialista da Azion para ver como mover workloads stateless para uma rede distribuída impacta a sua conta de egress.

---

Perguntas frequentes

O que é custo de egress na nuvem? Custo de egress é a taxa que os provedores de cloud cobram pela transferência de dados para fora da rede deles. A AWS cobra US$ 0,09 por GB saindo de us-east-1. Para uma empresa movendo 50 TB por mês, isso é US$ 4.500 por mês ou US$ 54.000 por ano só em taxas de bandwidth, antes de qualquer custo de compute ou storage.

Por que as taxas de egress da AWS são tão altas em 2026? O preço por GB não mudou muito desde 2020, mas o volume de dados das aplicações cresceu de 3 a 7 vezes em relação ao que os times projetaram nos planos originais de migração. Funcionalidades real-time, bases de usuários globais e arquiteturas de microsserviços multiplicam o egress muito além das projeções iniciais.

Qual é a diferença entre workloads stateless e stateful na nuvem? Workloads stateless — respostas de API, autenticação, entrega de assets e serverless functions — não dependem de estado de sessão armazenado e podem rodar em qualquer lugar. Workloads stateful — bancos de dados, filas e armazenamento persistente — precisam ficar em um local consistente. Essa distinção determina quais workloads podem ser movidos para uma rede distribuída para reduzir custos de egress sem quebrar o restante da arquitetura.

FinOps consegue reduzir os custos de egress na nuvem? FinOps consegue identificar e rastrear os gastos com egress, mas não consegue mudar o preço por GB definido pelo provedor. Right-sizing e reserved instances costumam reduzir as contas de cloud em 15 a 25%, mas a redução de egress exige uma mudança arquitetural: mover workloads stateless e egress-heavy para uma rede distribuída mais próxima dos usuários.

Como calcular o custo de egress por usuário ativo? Divida o custo total mensal de egress pelos seus usuários ativos mensais. Se esse número cresce mais rápido que a receita por usuário, seus custos de infraestrutura estão escalando mais rápido que o negócio. Isso é um problema estrutural, não de right-sizing, e não tem como resolver só com uma ferramenta de FinOps.

Como é a divisão stateless/stateful na prática? Caches de API, camadas de autenticação, entrega de assets estáticos e edge functions vão para uma rede distribuída com pontos de presença globais. Bancos de dados, filas e armazenamento persistente ficam na nuvem sem alteração. O resultado é que os requests dos usuários são atendidos mais perto de onde eles estão, o egress saindo do cloud origin cai significativamente, e a infraestrutura central da aplicação não precisa ser reconstruída.