Migrar para a nuvem costuma ser tratado como o fim de um projeto — até a fatura seguinte chegar com um valor que ninguém tinha previsto. Em muitas empresas, o custo de egress do Azure após a migração é justamente esse item que escapa do orçamento: invisível no desenho da arquitetura, mas presente em cada gigabyte que sai do ambiente. Este texto mostra como identificar de onde vem esse tráfego, medi-lo com os recursos que o Azure já oferece e governá-lo de forma contínua, para que a conta deixe de surpreender.
O que é custo de egress no Azure e por que ele aparece depois da migração
O custo de egress no Azure corresponde à cobrança pelo tráfego de dados que deixa um recurso ou região da nuvem rumo a outro destino — seja a internet pública, outra região do Azure ou até outra zona de disponibilidade dentro da mesma região. Enquanto a entrada de dados (ingress) é gratuita na maioria dos cenários, a saída é medida em gigabytes e faturada de forma progressiva. Empresas que migram de um datacenter local para o Azure costumam subestimar esse componente porque, no modelo on-premises, o tráfego interno entre servidores não gera fatura por volume trafegado.
O impacto aparece quando a arquitetura migrada preserva padrões de comunicação que eram invisíveis no ambiente físico: aplicações que replicam dados entre nós a cada minuto, backups que varrem discos inteiros para um repositório central e logs que viajam para fora da região de produção. No Azure, cada um desses fluxos pode gerar egress. A conta não sobe por acaso — ela sobe porque o desenho da nuvem expõe, em reais, decisões de acoplamento que antes ficavam escondidas no switch local.
Egress, ingress e tráfego entre zonas: onde a cobrança começa
O Azure separa o tráfego em três categorias principais de cobrança. O ingress (entrada de dados) é, em regra, gratuito — dados que chegam a uma máquina virtual, conta de armazenamento ou banco de dados não geram custo de rede. O egress (saída) é o oposto: cada gigabyte que deixa o recurso em direção à internet ou a outra região entra na fatura. A terceira categoria, menos evidente, é o tráfego entre zonas de disponibilidade: ele é cobrado mesmo quando origem e destino estão na mesma região, porque atravessa a infraestrutura de rede interna da Microsoft entre datacenters fisicamente separados.
Há uma distinção prática que confunde equipes de TI no pós-migração. Tráfego entre máquinas na mesma zona de disponibilidade usando IP privado normalmente não gera egress. Mas basta que uma réplica, um cluster ou um balanceador cruze de uma zona para outra para que o volume passe a ser medido. Em arquiteturas de alta disponibilidade — justamente as que o setor financeiro e de pagamentos adota para sustentar operações Pix —, o tráfego entre zonas é estrutural, não acidental. Ele precisa ser desenhado com consciência de custo desde o primeiro dia.
Por que a fatura muda de patamar no primeiro mês pós-migração
O primeiro ciclo de faturamento após a migração costuma revelar três comportamentos que a estimativa pré-migração não capturou. O primeiro é o tráfego de sincronização inicial: replicação de bases, cópia de snapshots e espelhamento de volumes geram um pico de egress concentrado nas primeiras semanas. O segundo é o regime permanente de telemetria: agentes de monitoramento, logs de aplicação e métricas de segurança que, somados, produzem um fluxo contínuo de saída. O terceiro é o tráfego de contingência: ambientes de disaster recovery que replicam dados para outra região de forma contínua, independentemente de haver incidente.
Além disso, a calculadora de preços do Azure usada na fase de planejamento frequentemente considera apenas o custo de computação e armazenamento. O egress entra como linha separada, fácil de ignorar quando o foco está em dimensionar VMs e discos. O resultado é uma fatura que muda de patamar não por erro de estimativa de capacidade, mas por omissão de um componente inteiro de custo. Medir o egress real nas primeiras semanas é o que transforma essa surpresa em linha de base gerenciável.
O que define o custo de egress no Azure
O valor do egress não é fixo por gigabyte em todos os cenários. Ele depende de origem e destino, do tipo de serviço que origina o tráfego e do caminho de rede que os dados percorrem. Entender essas variáveis é o que separa uma otimização cirúrgica de um corte cego que pode degradar a aplicação. Decisores de TI em empresas de médio e grande porte precisam dessa granularidade para negociar arquitetura com os times técnicos sem cair em simplificações.
Origem e destino do tráfego: internet, entre regiões e entre zonas de disponibilidade
As faixas de cobrança mais relevantes no pós-migração seguem uma hierarquia clara:
- Saída para a internet — a mais cara, medida por GB com preço que varia conforme a região de origem.
- Saída entre regiões do Azure — cobrada quando dados cruzam de uma região para outra, mesmo dentro do mesmo tenant.
- Saída entre zonas de disponibilidade — tarifada por GB quando o tráfego atravessa zonas na mesma região.
- Saída via peered VNets — tráfego entre redes virtuais emparelhadas, com cobrança própria por volume.
Uma aplicação que responde a usuários na internet paga o egress de borda; uma arquitetura multi-região paga também o egress de replicação entre datacenters; um cluster de banco distribuído em três zonas paga o tráfego interno entre nós. Os três custos coexistem em muitos ambientes financeiros, e cada um exige uma estratégia diferente de redução.
Serviços que geram egress sem aparecer no desenho da arquitetura
Alguns serviços do Azure geram egress de forma pouco visível no diagrama de arquitetura. O Azure Monitor envia logs e métricas para fora da região quando o workspace do Log Analytics está em outra localidade. O Azure Backup replica dados para cofres que podem estar em regiões pareadas por padrão de resiliência. O Azure SQL Database com replicação geográfica ativa mantém um secundário em outra região, gerando tráfego contínuo de saída do primário.
Outros exemplos comuns incluem contas de armazenamento com RA-GRS (replicação geográfica com acesso de leitura), que copiam dados para uma região secundária distante, e clusters AKS que puxam imagens de container de registries públicos a cada deploy. Nenhum desses fluxos aparece como "egress" no desenho funcional — eles aparecem como "alta disponibilidade", "observabilidade" ou "automação". A fatura, porém, os contabiliza um a um.
CDN, ExpressRoute e peering: quando o caminho de saída muda a conta
O caminho que o dado percorre altera o custo de saída de forma significativa. O Azure CDN reduz o egress de origem ao servir conteúdo a partir de pontos de presença na borda, mais próximos do usuário — o que também melhora a latência para aplicações voltadas ao público. O ExpressRoute, por sua vez, oferece conexão privada entre o datacenter do cliente e o Azure com modelo de cobrança por porta e por volume de saída, que pode ser vantajoso para grandes volumes contínuos, mas não elimina o egress por completo.
O peering de VNets merece atenção específica: o emparelhamento permite comunicação entre redes virtuais, mas o tráfego entre elas é medido e cobrado por gigabyte quando cruza regiões ou zonas. Times que emparelham VNets de produção, staging e contingência sem avaliar o volume de dados trocados entre elas descobrem, na fatura, que a "rede interna" da nuvem não é gratuita. A escolha entre peering, Private Endpoint e Service Endpoint deixa de ser apenas técnica e passa a ser financeira.
Como descobrir de onde vem o seu egress com os dados que o Azure já tem
Antes de otimizar, é preciso medir. O Azure entrega ferramentas nativas suficientes para diagnosticar o egress sem depender de estimativas de terceiros. O ponto de partida é aceitar que a fatura agregada não diz qual workload consome a saída — apenas que o total subiu. A decomposição exige cruzar dados de custo com dados de rede, e é exatamente esse cruzamento que transforma o egress de caixa-preta em alvo de ação.
Cost Management, análise de custo por serviço e por tag
O Microsoft Cost Management permite filtrar o custo por serviço, região, grupo de recursos e — fator decisivo para governança — por tag. Se a migração foi feita com uma política de tagging disciplinada, cada workload, departamento ou centro de custo pode ter seu egress isolado. A análise por serviço revela, por exemplo, a participação relativa de cada componente no egress da região.
Sem tags, o diagnóstico vira arqueologia: é preciso inferir a origem do tráfego por nome de recurso, grupo ou assinatura. Por isso, a recomendação prática é estabelecer tags de ambiente, aplicação e responsável antes de encerrar a migração — retroagir tagging em centenas de recursos é caro e impreciso. A análise de custo por serviço e por tag é o primeiro filtro; ela aponta o que gera egress, mas não por onde o tráfego sai.
Network Watcher, flow logs e métricas de tráfego de saída
O Azure Network Watcher complementa o Cost Management com visão de rede. Os flow logs de NSG registram, por regra, os fluxos aceitos e negados, com origem, destino, porta e volume. As métricas de tráfego de saída por interface de rede mostram a taxa de bytes que deixa cada recurso ao longo do tempo. Cruzando os dois, é possível identificar que uma VM específica envia 2 TB por mês para um endpoint externo — e que esse fluxo usa a porta 443 para um serviço de backup não gerenciado.
Para ambientes com requisitos de segurança e compliance — comuns em empresas que processam transações Pix —, o flow log também serve como evidência de auditoria. Ele documenta quais fluxos cruzaram a fronteira da rede e quando. A leitura de egress deixa de ser apenas uma questão de custo e passa a integrar a rotina de monitoramento de segurança, alinhada às boas práticas de proteção contra ransomware e de visibilidade de tráfego.
Montando uma linha de base de egress antes de otimizar
A linha de base de egress é um retrato quantificado do tráfego de saída em condições normais de operação, por workload e por destino. Ela deve ser construída nas primeiras semanas após a estabilização da migração, quando os picos de sincronização inicial já passaram e o regime permanente se estabeleceu. Sem essa referência, qualquer variação futura — um pico de replicação, um vazamento de dados, um serviço mal configurado — se confunde com ruído.
Uma linha de base útil contém pelo menos quatro elementos:
- Volume mensal de egress por serviço — extraído do Cost Management.
- Top 10 fluxos de saída por volume — extraídos dos flow logs.
- Distribuição por destino — internet, entre regiões, entre zonas.
- Sazonalidade esperada — picos de fechamento contábil, campanhas, eventos de pagamento.
Essa linha de base é o que permite, meses depois, distinguir uma anomalia real de uma variação normal de negócio. Também é o ponto de partida para qualquer iniciativa de FinOps, que depende de medição consistente antes de propor metas de redução.
Erros de arquitetura que transformam egress em custo recorrente
O egress elevado raramente é fruto de um único erro. Ele é o acúmulo de decisões arquiteturais que, isoladas, parecem razoáveis, mas que juntas criam um padrão de tráfego caro. Identificar esses padrões é o primeiro passo para corrigi-los sem reescrever a aplicação inteira.
Tráfego entre zonas de disponibilidade tratado como se fosse interno
Arquiteturas de alta disponibilidade espalham réplicas entre zonas de disponibilidade para resistir a falhas de datacenter. O que muitos times não consideram é que cada comunicação entre essas réplicas — sincronização de banco, replicação de fila, heartbeat de cluster — gera egress cobrado. Em clusters de banco com replicação síncrona, o volume entre zonas pode superar o tráfego de saída para a internet.
O erro não está em usar múltiplas zonas; está em não modelar o custo do tráfego entre elas na decisão de arquitetura. Para cargas com estado, como bancos de dados de transações financeiras, a replicação entre zonas é frequentemente necessária. Para cargas sem estado, porém, distribuir instâncias entre zonas sem necessidade apenas multiplica o egress. A pergunta correta é: este componente precisa conversar com outro em zona diferente, ou basta que cada zona atenda seus próprios usuários?
Serviços conversando entre regiões por padrão
A replicação geográfica ativa do Azure SQL, o armazenamento RA-GRS e o cofre de backup com redundância geográfica são configurações que, por padrão ou por escolha de resiliência, colocam dados em outra região. Cada escrita no primário gera tráfego de saída para o secundário. Em ambientes de alto volume transacional — como uma plataforma de pagamentos instantâneos —, esse fluxo é contínuo e significativo.
O erro de arquitetura é tratar a região secundária como "gratuita" porque ela faz parte do mesmo tenant. A resiliência geográfica tem preço, e ele aparece como egress entre regiões. A decisão correta envolve avaliar o RTO e o RPO exigidos pelo negócio: se a tolerância a perda permite replicação assíncrona com atraso, o custo pode ser menor do que uma replicação síncrona contínua. Se a exigência regulatória ou contratual impõe recuperação em minutos, o egress é o preço da conformidade — e deve ser orçado, não descoberto.
Saída para a internet sem CDN, cache ou proxy de saída
Aplicações web que servem conteúdo estático diretamente da origem pagam egress de internet por cada requisição. Sem CDN, cada imagem, script e folha de estilo trafega da região do Azure até o usuário final, acumulando volume. Sem cache, o mesmo conteúdo é servido repetidamente para os mesmos usuários. Sem proxy de saída, máquinas virtuais que precisam acessar a internet para atualizações, APIs externas ou telemetria o fazem individualmente, sem deduplicação.
O impacto é duplo: custo de egress mais alto e latência pior para o usuário. Um CDN na borda reduz ambos ao mesmo tempo. Um proxy de saída centralizado, como o Azure Firewall ou um appliance virtual, consolida o tráfego e permite aplicar políticas de segurança — exigência relevante para quem opera com dados sensíveis e precisa demonstrar controle sobre o que sai do ambiente.
Backup, replicação e logs trafegando para fora da região de produção
Backup e logs são os maiores geradores silenciosos de egress. Um backup diário completo de 5 TB enviado para um cofre em outra região gera 150 TB de egress por mês — volume que raramente aparece na estimativa inicial. Logs de aplicação em volume alto, quando enviados para um workspace do Log Analytics em outra região, adicionam um fluxo contínuo de saída. A replicação de snapshots de máquinas virtuais para disaster recovery faz o mesmo.
A correção começa por revisar a política de retenção: quantos dias de log são realmente necessários para auditoria e investigação? Depois, por revisar a localização dos destinos: o cofre de backup precisa estar em outra região, ou a exigência de continuidade aceita um cofre na mesma região com redundância de zona? A legislação de proteção de dados e as normas de segurança do setor financeiro impõem requisitos de retenção e de localização, mas não determinam, por si sós, que todo log e todo backup cruzem fronteiras de região. A conformidade, tema explorado em conteúdo sobre LGPD, define o que reter e por quanto tempo — e é essa definição que dimensiona o egress.
Como reduzir o custo de egress sem quebrar a arquitetura
Reduzir egress não significa cortar redundância, desligar monitoramento ou sacrificar desempenho. Significa reposicionar componentes, introduzir camadas de cache e controlar rotas de saída para que o tráfego percorra o menor caminho possível — ou nem precise percorrer caminho algum. As alavancas abaixo atuam sobre a origem, o caminho e o destino do tráfego.
Aproximar quem consome de quem serve: região, zona e colocação de serviços
A regra mais simples e mais ignorada: coloque quem consome dados na mesma região e, quando possível, na mesma zona de quem os serve. Uma aplicação que lê de um banco em outra região paga egress por cada consulta. Mover o banco para a região da aplicação elimina esse custo — e reduz a latência. O mesmo vale para serviços de cache, filas e armazenamento de objetos.
Em arquiteturas multi-região por exigência de disponibilidade, a aproximação se aplica dentro de cada região: cada região deve ser autossuficiente para o tráfego de leitura, com replicação apenas para escrita e contingência. O tráfego entre regiões fica restrito ao mínimo necessário para manter a consistência, em vez de ser o caminho padrão de toda requisição.
Cache, compressão e CDN na borda
O cache ataca o egress na raiz: se o dado não precisa sair da origem, não há tráfego de saída. O Azure Front Door e o Azure CDN servem conteúdo estático e dinâmico a partir da borda, reduzindo o volume que deixa a região de origem. Para APIs, o cache de respostas no Front Door ou em um Redis Cache na mesma região elimina chamadas repetidas ao backend.
A compressão de payloads — habilitada em nível de aplicação ou de borda — reduz o volume de bytes trafegados sem alterar a lógica. Para cargas que retornam JSON ou XML grandes, a compressão pode reduzir o egress em 60% ou mais, dependendo do conteúdo. A combinação de cache, compressão e CDN é a alavanca de maior retorno para aplicações voltadas à internet, especialmente as que atendem picos de transações.
Private Endpoints, Service Endpoints e rotas de saída controladas
O Service Endpoint mantém o tráfego entre uma VNet e um serviço do Azure — como Storage ou SQL — dentro da rede de backbone da Microsoft, sem passar pela internet pública. Isso elimina o egress de internet para esses fluxos e melhora a postura de segurança, já que o tráfego não sai para a rede pública. O Private Endpoint vai além: coloca o serviço dentro da VNet com um IP privado, eliminando completamente a exposição pública.
Para tráfego que precisa sair para a internet — atualizações, APIs de terceiros, telemetria —, uma rota de saída controlada via Azure Firewall ou NAT Gateway consolida e audita o fluxo. O NAT Gateway também reduz o custo ao evitar que cada VM tenha um IP público individual com cobrança própria. A combinação de Service Endpoints para serviços internos e rota controlada para o que realmente precisa sair é a base de uma arquitetura de rede com egress mínimo e visibilidade total, alinhada às práticas de criptografia de dados e proteção em trânsito.
Políticas de retenção e ciclo de vida para dados que saem do ambiente
Dados que não precisam mais existir não geram egress. A política de retenção define por quanto tempo logs, backups e snapshots são mantidos — e cada dia a mais é volume a mais trafegando para fora da região de produção. Revisar a retenção de logs de 90 para 30 dias, quando a exigência de auditoria permite, reduz o egress proporcionalmente. O mesmo vale para backups: retenção longa exige mais armazenamento e mais tráfego de replicação.
O ciclo de vida de blobs no Azure Storage automatiza a transição de dados entre camadas — quente, fria e de arquivamento — e pode mover dados antigos para camadas que não replicam para outras regiões. Para ambientes que processam dados sensíveis, a política de retenção deve ser definida em conjunto com a área de compliance, para que a redução de custo não comprometa a capacidade de atender a auditorias ou investigações. A conformidade com a LGPD orienta a definição de finalidades específicas para o tratamento de dados — e é sobre essa base que o ciclo de vida deve ser desenhado.
Governança contínua: como o egress não volta a estourar
Otimizar egress uma vez não resolve o problema de forma permanente. Novas aplicações, novas regiões, novos fornecedores de dados e mudanças de arquitetura reintroduzem tráfego de saída ao longo do tempo. A governança contínua é o que mantém o egress dentro da linha de base — e dispara ação quando ele se desvia dela.
Tags, orçamentos e alertas de anomalia de custo
A governança começa com tags obrigatórias para todo recurso criado, aplicadas por política do Azure Policy. Sem tags, o egress volta a ser um agregado indistinto, impossível de atribuir a um dono. Com tags, cada workload tem seu custo de saída rastreado e comparável mês a mês.
O Microsoft Cost Management permite criar orçamentos por escopo — assinatura, grupo de recursos ou tag — e configurar alertas de anomalia que disparam quando o custo real se desvia da tendência esperada. Um alerta de egress que salta 30% em uma semana aciona a investigação antes que o mês feche. Para times de operação, o alerta de anomalia é o equivalente financeiro do alerta de segurança: um sinal precoce de que algo mudou no ambiente.
Revisão de arquitetura e de tráfego como rotina, não como projeto
A revisão de egress não pode ser um projeto pontual pós-migração. Ela precisa entrar na rotina mensal de operação, com pauta fixa: comparar o egress real com a linha de base, revisar os top fluxos de saída e avaliar se novas implantações alteraram o padrão. A revisão trimestral de arquitetura avalia mudanças estruturais — nova região, novo serviço, novo padrão de replicação — antes que elas se consolidem como custo fixo.
Essa rotina também captura o que os dashboards não mostram: a aplicação que passou a chamar uma API externa nova, o time que ativou replicação geográfica em um banco de teste, o pipeline de CI/CD que passou a publicar artefatos em outra região. A revisão contínua transforma o egress de surpresa em indicador gerenciado.
Quem responde pelo egress: papéis entre finanças, arquitetura e operação
O egress não tem dono natural na maioria das empresas. Finanças vê a fatura, arquitetura desenha o fluxo e operação executa a mudança — e ninguém responde pelo custo de saída. A governança eficaz define papéis explícitos:
- Finanças/FinOps — mantém a linha de base, os orçamentos e os alertas de anomalia.
- Arquitetura — aprova mudanças estruturais que alteram região, zona ou padrão de replicação.
- Operação — executa a revisão mensal de fluxos e responde aos alertas de desvio.
- Segurança/Compliance — valida que as rotas de saída e as políticas de retenção atendem aos requisitos normativos.
Sem essa divisão, o egress volta a estourar porque ninguém é acionado quando ele sobe. Com papéis definidos, o custo de saída passa a ter o mesmo tratamento de qualquer outro indicador crítico de operação — medido, revisado e corrigido em ciclo contínuo.
Perguntas frequentes sobre custo de egress do Azure após a migração
O egress do Azure é cobrado por gigabyte ou por taxa fixa?
O egress é cobrado por gigabyte trafegado, com preço que varia conforme a origem do tráfego e o destino. Não há taxa fixa mensal de egress: o valor depende do volume. Regiões diferentes do Azure têm preços diferentes de saída, e o tráfego entre regiões tem tarifa própria.
Tráfego entre duas VMs na mesma região gera egress?
Depende da zona de disponibilidade. Duas VMs na mesma zona, comunicando-se por IP privado, normalmente não geram egress cobrado. Se estiverem em zonas diferentes da mesma região, o tráfego entre elas é medido e cobrado, mesmo sendo "interno" à região.
Backup para outra região conta como egress?
Sim. A replicação de dados de backup para um cofre em outra região gera tráfego de saída entre regiões, cobrado por gigabyte. O mesmo vale para replicação geográfica de bancos de dados e para armazenamento com redundância geográfica.
O Cost Management mostra o egress separado por workload?
Mostra por serviço, região e tag, desde que os recursos estejam tagueados. Sem tags, a atribuição por workload exige análise adicional com flow logs e métricas de rede. A disciplina de tagging é pré-requisito para o diagnóstico granular.
CDN elimina o custo de egress?
Não elimina, mas reduz o egress da origem ao servir conteúdo a partir da borda. O tráfego entre a origem e o CDN ainda gera egress, mas em volume muito menor do que servir cada usuário diretamente da região de origem.
ExpressRoute é mais barato que saída para a internet?
Para grandes volumes contínuos, o ExpressRoute pode ter custo por gigabyte de saída mais baixo do que o egress de internet, mas exige contratação de porta com valor mensal. A decisão depende do volume: para tráfego baixo, a internet pode ser mais econômica; para volumes altos e estáveis, o ExpressRoute tende a compensar.
Como saber se o egress atual está acima do esperado?
Comparando o egress real com a linha de base construída após a estabilização da migração. Se a linha de base não existe, o primeiro passo é criá-la com os dados do Cost Management e dos flow logs. Alertas de anomalia configurados no Cost Management também sinalizam desvios automaticamente.
O tráfego entre zonas de disponibilidade pode ser evitado?
Em arquiteturas que exigem alta disponibilidade com replicação síncrona, não — e o custo deve ser orçado como parte da resiliência. Em cargas sem estado ou com tolerância a falha de zona, é possível concentrar réplicas em menos zonas para reduzir o tráfego entre elas. A decisão é caso a caso, com base no RTO e RPO exigidos.
