Acesso de saída à internet: controle o tráfego de saída do Azure

Este artigo explica como controlar o acesso de saída à Internet das redes virtuais do Azure. Ele compara o NAT Gateway, o Firewall do Azure e os padrões combinados de saída para ajudá-lo a escolher um método previsível e seguro para suas cargas de trabalho.

O que este artigo aborda

O controle de tráfego de saída determina como suas cargas de trabalho do Azure acessam a Internet pública. Uma estratégia de saída bem projetada fornece endereços IP públicos previsíveis, impede o esgotamento da porta SNAT e, opcionalmente, filtra conexões de saída por destino.

Note

Este artigo aborda conceitos específicos de saída. Para obter a cobertura completa do firewall, consulte Firewall do Azure e inspeção de tráfego.

Quem precisa deste artigo

Leia este artigo se uma ou mais dessas condições se aplicarem:

  • Suas cargas de trabalho precisam de acesso de saída controlado à Internet para atualizações, APIs ou serviços externos.
  • Você precisa de endereços IP públicos previsíveis para conexões de saída.
  • Você precisa evitar o esgotamento da porta SNAT ou dimensionar a conectividade de saída para cargas de trabalho de alta conexão.
  • Você precisa escolher entre o Gateway de NAT, Firewall do Azure ou um padrão combinado para controle e inspeção de saída.

Tip

Seguindo um cenário específico? Selecione seu cenário na parte superior da página para obter diretrizes personalizadas. As diretrizes principais a seguir se aplicam a todos os leitores.

Foco em migração direta: suas VMs migradas precisam de acesso controlado à Internet. Centralize todo o tráfego de saída por meio do firewall do hub para impor uma política de segurança consistente entre cargas de trabalho migradas.

Leia este artigo se você:

  • Implante cargas de trabalho que precisam acessar a Internet para atualizações, chamadas à API ou serviços de terceiros.
  • Deseja centralizar o controle de saída por meio de Firewall do Azure na VNet do hub.
  • Precisa desativar o acesso de saída padrão em cargas de trabalho migradas e substituí-lo por um método de saída explícito.
  • Exigir um endereço IP público fixo e previsível para conexões de saída.

Foco em modernização: todas as VNets spoke roteiam o tráfego de saída através do firewall hub por meio de rotas definidas pelo usuário (UDR). Esse modelo de saída centralizado é essencial para sua arquitetura de segurança, pois impede que as equipes de aplicativos ignorem os controles de segurança gerenciados por TI.

Leia este artigo se você:

  • É necessário garantir que todas as cargas de trabalho da spoke (AKS, App Service, VMs) encaminhem todo o tráfego de saída por meio do firewall do hub.
  • Deseja roteamento baseado em UDR de cada spoke para o Firewall do Azure hub para uma política de saída consistente?
  • Exija que o firewall do hub atue como SNAT para todas as conexões de saída.
  • É necessário evitar o esgotamento de portas SNAT para cargas de trabalho com grande número de conexões.

Foco em nuvem cruzada: inclua a saída centralizada se o seu projeto exigir uma política de saída controlada para a Internet. Caso contrário, o tráfego entre nuvens passa pelo caminho de trânsito (Firewall do Azure em um hub virtual seguro) e não precisa de uma configuração de saída separada.

Leia este artigo se você:

  • Precisa de uma política centralizada de saída para a Internet em sua zona de destino do Azure.
  • Deseja compartilhar o mesmo Firewall do Azure para inspeção de trânsito entre nuvens e saída para a Internet?
  • Substituir o acesso de saída padrão antes que ele seja desativado.

Azure serviços e recursos

A tabela a seguir descreve os serviços e recursos disponíveis para acesso à Internet de saída em redes virtuais Azure.

Serviço ou recurso O que ele fornece Quando usar isso
Acesso de saída padrão (desativado) Azure atribui automaticamente um IP público temporário para conexões de saída. O IP atribuído não é previsível e pode ser alterado sem aviso prévio. Não use para novas implantações. Substitua pelo Gateway de NAT ou Firewall do Azure. Confira as considerações de segurança.
Gateway da NAT do Azure Serviço SNAT gerenciado com IPs públicos fixos e previsíveis. Fornece 64.512 portas SNAT por IP público, até 16 IPs públicos (mais de 1 milhão de portas no total). Nenhuma filtragem de conteúdo. Cargas de trabalho somente de saída que precisam de um IP de saída fixo, aplicativos com um grande número de conexões e cenários em que o esgotamento de portas SNAT representa um risco.
Firewall do Azure Inspeção completa das camadas de 3 a 7 para tráfego de saída. Filtragem de FQDN, filtragem de URL, categorias da Web e SKU Premium (IDPS). Gerenciamento de política centralizado. Quando você precisa controlar a quais destinos seus recursos se conectam, e não apenas se eles têm acesso de saída.
Gateway NAT + Firewall do Azure O NAT Gateway gerencia a escalabilidade de SNAT na sub-rede do firewall. Firewall do Azure manipula a inspeção e a filtragem. Não ocorre nenhum NAT duplo. Ambientes de produção que precisam de saída escalonável e filtragem com reconhecimento de conteúdo. Arquitetura recomendada para cargas de trabalho corporativas.
VM com IP público (saída) A máquina virtual usa seu próprio endereço IP público para tráfego de saída. Nenhum controle centralizado ou filtragem. Evitar em produção. Nenhum gerenciamento centralizado, imprevisível em escala e não se beneficia de recursos SNAT compartilhados.

Como escolher

Diagrama mostrando três caminhos de saída de uma rede virtual de carga de trabalho por meio do Gateway de NAT, Firewall do Azure ou ambos.

Como controlar o acesso de saída

Use a tabela a seguir para selecionar um método de saída com base em seus requisitos.

Seus requisitos Abordagem recomendada Por que
Corrigido somente o endereço IP de saída, sem a necessidade de filtragem Gateway da NAT Fornece IPs públicos previsíveis com alocação automática de porta SNAT. Nenhuma sobrecarga de inspeção ou custo de filtragem. A opção mais simples pronta para uso em produção.
Filtragem de FQDN, filtragem de URL ou inspeção de tráfego Firewall do Azure Filtra conexões de saída por FQDN ou URL de destino. O SKU Premium adiciona inspeção de IDPS e TLS para detecção avançada de ameaças.
IP de saída fixo e filtragem de conteúdo Gateway nat + Firewall do Azure O Gateway NAT no AzureFirewallSubnet fornece SNAT escalonável. O firewall inspeciona o tráfego antes da saída. O melhor dos dois recursos.
Não use para novas implantações Acesso de saída padrão ou IP público de VM O acesso de saída padrão está desativado. Os IPs públicos de VM não fornecem nenhum controle centralizado. Ambos são inadequados para cargas de trabalho de produção.

NAT Gateway versus Firewall do Azure para tráfego de saída

Use a comparação a seguir para entender as vantagens e desvantagens entre o NAT Gateway e o Firewall do Azure quando usados de forma independente.

Capability Gateway da NAT Firewall do Azure
Portas SNAT 64.512 por IP público (até 16 IPs, mais de 1 milhão no total) 2.496 por IP público por instância de back-end (no máximo 250 IPs)
Filtragem de tráfego Nenhum: permite todo o tráfego de saída. Regras de FQDN, filtragem de URL, categorias da Web, regras de rede
Inspeção de IDPS e TLS Não disponível Somente SKU Premium
Throughput Taxa de linha para a sub-rede (sem limite publicado para SNAT). Até 100 Gbps (Premium), 30 Gbps (Standard), 250 Mbps (Básico)
Modelo de custo Recursos por hora + por GB de dados processados Recurso por hora + dados por GB processados (custo base mais alto)
Complexidade de roteamento Associa diretamente a uma sub-rede, sem necessidade de UDR Requer UDR (0.0.0.0/0 → IP privado do firewall) nas sub-redes da carga de trabalho
Caso de uso Conexões de saída de alto volume que precisam de IPs fixos Ambientes regulamentados que exigem filtragem e registro do tráfego de saída

Prioridade de roteamento para tráfego de saída

Azure avalia os métodos de saída na ordem de prioridade a seguir. Métodos de prioridade mais alta substituem os de prioridade mais baixa na mesma sub-rede:

  1. UDR para um dispositivo virtual ou gateway de rede virtual: substitui todos os outros métodos de saída, incluindo o Gateway NAT.
  2. Gateway NAT: tem precedência sobre IPs públicos no nível da instância e regras de saída do balanceador de carga.
  3. IP público no nível da instância na máquina virtual.
  4. Regras de saída do balanceador de carga.
  5. Rota do sistema padrão para a Internet (Microsoft desativado essa opção para novas implantações).

Importante

Uma UDR (rota definida pelo usuário) com o destino 0.0.0.0/0 apontando para um dispositivo virtual (como Firewall do Azure) substitui o Gateway NAT. Esse comportamento faz parte do funcionamento previsto na arquitetura combinada de NAT Gateway + Firewall. A UDR aplicada às sub-redes de carga de trabalho força o tráfego a passar pelo firewall, enquanto o NAT Gateway na AzureFirewallSubnet fornece os endereços IP de saída finais.

Arquitetura combinada: Gateway nat + Firewall do Azure

O padrão de produção recomendado para saída empresarial combina ambos os serviços:

  1. As sub-redes de carga de trabalho têm uma UDR que envia o tráfego 0.0.0.0/0 para o endereço IP privado Firewall do Azure.
  2. Firewall do Azure inspeciona e filtra o tráfego de saída usando regras de rede, regras de aplicativo ou ambas.
  3. O Gateway nat é associado ao AzureFirewallSubnet e fornece SNAT escalonável para as conexões de saída do firewall.
  4. Não ocorre nenhum NAT duplo . O firewall envia tráfego para o Gateway nat usando seu IP privado, e o Gateway nat aplica SNAT uma vez usando seus IPs públicos.

Essa arquitetura oferece inspeção centralizada com SNAT escalável. O AzureFirewallSubnet não precisa de UDRs extras porque o Gateway NAT roteia automaticamente o tráfego de saída da Internet quando associado.

Note

O Gateway NAT Standard é um recurso zonal e não dá suporte a implantações com redundância de zona. Se você implantar um Firewall do Azure com redundância de zona, use o Gateway da NAT V2 (SKU StandardV2) para SNAT com redundância de zona. O gateway NAT padrão se torna um único ponto de falha durante uma falha zonal quando combinado com um firewall com redundância de zona. Para obter mais informações, confira SKUs do Gateway de NAT.

Passo a passo do fluxo de dados

A sequência a seguir mostra como uma única solicitação de saída flui pela arquitetura combinada:

  1. Uma VM em uma sub-rede de carga de trabalho inicia uma conexão TCP com uma API externa (por exemplo, api.contoso.com:443).
  2. A UDR da sub-rede corresponde a 0.0.0.0/0 e envia o pacote para o IP privado Firewall do Azure.
  3. Firewall do Azure avalia a conexão com regras de aplicativo e regras de rede. Se uma regra de aplicativo com uma entrada de permissão de FQDN corresponder, o firewall permitirá a conexão.
  4. O firewall envia o pacote permitido de sua própria interface no AzureFirewallSubnet.
  5. O Gateway nat, associado ao AzureFirewallSubnet, executa o SNAT. Ele converte o IP de origem privada do firewall para um de seus IPs públicos e aloca uma porta SNAT do pool.
  6. A resposta da API externa retorna para o IP público do gateway NAT. O Gateway de NAT executa a tradução inversa e entrega o pacote de volta para o firewall.
  7. O firewall envia a resposta à VM de origem por meio do estado de conexão existente.

Nesse fluxo de ponta a ponta, o firewall inspeciona o tráfego exatamente uma vez e o Gateway nat aplica SNAT exatamente uma vez, sem NAT duplo.

Monitoramento e diagnóstico

Monitore sua infraestrutura de saída para detectar problemas de capacidade antes que eles afetem cargas de trabalho:

  • Métricas do Gateway de NAT: Monitore a contagem total de conexões SNAT, a contagem de conexões SNAT (por estado) e a disponibilidade do Datapath em Azure Monitor. Defina alertas quando o uso da porta SNAT exceder 80% de capacidade alocada.
  • Firewall do Azure logs: habilite as configurações de diagnóstico para enviar logs para Log Analytics. Use as categorias de log AzureFirewallApplicationRule e AzureFirewallNetworkRule para auditar conexões de saída permitidas e negadas.
  • Monitor de Conexão: Use o Monitor de Conexão do Observador de Rede para testar a conectividade de ponta a ponta de VMs de carga de trabalho até pontos de extremidade externos. Monitor da Conexão detecta aumentos de latência e falhas de conectividade que podem indicar esgotamento de SNAT ou configuração incorreta do firewall.
  • Métricas de firewall: Acompanhe a taxa de transferência, a contagem de ocorrências de regras e a utilização da porta SNAT para dimensionar com o tamanho certo sua SKU de firewall e identificar regras frequentes.

Considerações sobre o design

Use Firewall do Azure para toda a comunicação de saída de cargas de trabalho migradas. Essa abordagem oferece filtragem centralizada de FQDN, registro em log e detecção de ameaças desde o primeiro dia:

  • Desative o acesso de saída padrão: Para novas implantações, as sub-redes são privadas por padrão (sem tráfego de saída automático). Para VNets existentes, substitua explicitamente a rota de saída padrão pela rota de saída do Firewall do Azure para evitar depender de IPs públicos imprevisíveis e não controlados.
  • UDR em sub-redes de carga de trabalho: crie uma rota definida pelo usuário (0.0.0.0/0 → IP privado do Firewall do Azure) em cada sub-rede de carga de trabalho spoke. Essa configuração força todo o tráfego destinado à Internet a passar por meio do firewall do hub.
  • NAT Gateway na AzureFirewallSubnet: Associe o NAT Gateway à sub-rede do firewall para SNAT escalável. Essa combinação fornece IPs de saída previsíveis e evita o esgotamento da porta SNAT.
  • Comece com regras de permissão amplas, aperte ao longo do tempo: Durante a migração, permita a saída para destinos de que seus aplicativos precisam (Windows Update, repositórios de pacotes, APIs de terceiros). Após a migração se estabilizar, audite os logs de firewall e restrinja o acesso a FQDNs conhecidos.

O roteamento baseado em UDR de cada spoke para o firewall hub é a base do seu modelo de segurança de saída. As equipes de aplicativos não podem ignorar controles de saída gerenciados por TI:

  • UDR em cada VNet spoke: cada sub-rede de carga de trabalho spoke tem uma tabela de rotas com 0.0.0.0/0 → IP privado do Firewall do Azure hub. Essa configuração garante que os nós do AKS, as sub-redes integradas à VNet do App Service e as VMs direcionem todo o tráfego de saída pelo firewall.
  • Firewall do hub como SNAT: Firewall do Azure executa NAT de origem para todas as conexões de saída. Todas as cargas de trabalho spoke compartilham os endereços IP de saída do firewall, o que simplifica a inclusão de firewalls parceiros em listas de permissão.
  • Gateway nat para dimensionamento de SNAT: Associe o Gateway nat ao AzureFirewallSubnet. Com 16 IPs públicos (mais de 1 milhão de portas SNAT), você lida com cargas de trabalho de alta contagem de conexões, como clusters do AKS, com muitos pods fazendo chamadas à API externa.
  • Regras de aplicativo para controle de FQDN: Use as regras de aplicativo do Firewall do Azure para restringir o tráfego de saída por FQDN. As equipes de aplicativos solicitam que o FQDN permita entradas por meio de um processo de gerenciamento de alterações. Negar por padrão impede a exfiltração de dados.

O Firewall do Azure no hub virtual seguro inspeciona tanto o tráfego de trânsito entre nuvens quanto o tráfego de saída para a Internet. O compartilhamento de um único firewall para ambos os caminhos simplifica a arquitetura:

  • Firewall de hub virtual seguro para tráfego de saída: Se você implantar a WAN Virtual com um hub seguro, o Firewall do Azure no hub gerenciará o tráfego de saída para a Internet de todas as VNets conectadas. Configure a política de roteamento de tráfego de Internet do hub seguro para enviar 0.0.0.0/0 por meio do firewall.
  • A saída e o trânsito entre nuvens compartilham o mesmo firewall: O tráfego destinado à Internet e ao tráfego destinado à AWS/Google Cloud por meio de túneis IPSec passam por Firewall do Azure para inspeção. Esse design significa que você mantém uma regra definida para todos os caminhos de saída.
  • Centralize somente se necessário: Se o design entre nuvens não exigir saída centralizada da Internet (por exemplo, cargas de trabalho só se comunicam entre nuvens), você pode ignorar essa configuração e depender apenas da inspeção do firewall de trânsito entre nuvens.

Pré-requisitos

Antes de implementar controles de saída, confirme os seguintes itens:

  • Uma rede virtual é implantada com sub-redes dimensionadas para suas cargas de trabalho. Consulte redes virtuais e sub-redes para obter diretrizes de design de sub-rede.
  • Você entende as UDRs (rotas definidas pelo usuário) e como elas substituem o roteamento de Azure padrão. Consulte redes virtuais e sub-redes para obter detalhes de configuração de UDR.
  • Sua sub-rede de firewall será dimensionada corretamente se você usar Firewall do Azure. O AzureFirewallSubnet requer um mínimo de /26 (64 endereços).
  • Você conhece os requisitos de escala do SNAT. Calcule as conexões de saída simultâneas de pico para determinar quantos IPs públicos do Gateway nat você precisa (64.512 portas por IP).

Considerações de segurança

Substituir o acesso de saída padrão

O acesso de saída padrão está desativado. Para versões da API lançadas após 31 de março de 2026, as novas redes virtuais são definidas como sub-redes privadas por padrão (sem saída automática). As redes virtuais existentes não são afetadas, mas você deve migrar para um método de saída explícito. Para obter detalhes completos, consulte a documentação de acesso de saída padrão.

Note

As redes virtuais e as VMs existentes que atualmente usam o acesso de saída padrão continuam funcionando. No entanto, o IP público atribuído não é previsível, não fornece filtragem e dispara Assistente do Azure alertas. Planeje a migração para o NAT Gateway ou o Firewall do Azure, independentemente do cronograma de desativação.

Roteamento de UDR para inspeção centralizada por firewall

Ao usar o Firewall do Azure para controle de saída, crie uma UDR em cada sub-rede de carga de trabalho com:

  • Destino: 0.0.0.0/0
  • Tipo de próximo salto: Virtual Appliance
  • Endereço do próximo salto: Firewall do Azure IP privado (por exemplo, 10.0.1.4)

Essa configuração garante que todo o tráfego associado à Internet de sub-redes de carga de trabalho passe pelo firewall para inspeção. Sem essa UDR, o tráfego ignora o firewall e usa qualquer método de saída configurado diretamente na sub-rede.

Impedir o esgotamento da porta SNAT

O esgotamento de portas SNAT ocorre quando uma carga de trabalho abre mais conexões de saída simultâneas do que a quantidade de portas disponível comporta. Os sintomas incluem tempos limite de conexão intermitentes, pacotes TCP RST em conexões de saída e solicitações HTTP com falha e erros de socket. Os logs de aplicativo mostram erros de "endereço já em uso" ou "não é possível atribuir o endereço solicitado". A exaustão geralmente se manifesta sob carga, quando muitas conexões de curta duração são abertas rapidamente para o mesmo endereço IP e porta de destino.

Para evitar o esgotamento:

  • Use o Gateway de NAT para cargas de trabalho com altas contagens de conexões de saída. Cada IP público fornece 64.512 portas SNAT com alocação dinâmica em todos os recursos na sub-rede.
  • Adicione IPs públicos ao seu Gateway NAT se o monitoramento indicar que o uso das portas excede 80%. Adicione 16 IPs públicos.
  • Use o pool de conexões no código do aplicativo para reutilizar conexões existentes em vez de abrir novas para cada solicitação.
  • Diversifique os endpoints de destino quando possível. A alocação de portas SNAT é feita para cada tupla de IP/porta de destino, portanto distribuir o tráfego entre vários IPs de destino reduz a pressão sobre as portas.
  • Reduza os tempos limite de inatividade para recuperar portas mais rapidamente. O tempo limite ocioso padrão do Gateway nat é de 4 minutos. Reduza esse valor para cargas de trabalho que criam muitas conexões de curta duração.

Grupos de segurança de rede complementam o controle de saída

Os NSGs (grupos de segurança de rede) e os métodos de saída atendem a diferentes finalidades e trabalham juntos. Os NSGs filtram o tráfego por endereço IP e porta no nível de sub-rede ou NIC. O NAT Gateway e o Firewall do Azure controlam como o tráfego chega à Internet. Use ambas as camadas para defesa em profundidade. Consulte grupos de segurança de rede e grupos de segurança de aplicativos para obter diretrizes de design do NSG.

Considerações sobre túnel forçado

O tunelamento forçado de saída por meio de infraestrutura local pode introduzir latência e adicionar dependência ao firewall local. Considere Firewall do Azure para inspeção de saída se a baixa latência for importante. Se a conformidade exigir inspeção local, teste a latência de ponta a ponta das sub-redes de carga de trabalho e certifique-se de que o caminho local possa lidar com os requisitos de taxa de transferência sem se tornar um gargalo.

Impedir a exfiltração dos dados

Firewall do Azure filtragem de FQDN impede a exfiltração de dados restringindo conexões de saída somente a nomes de domínio aprovados. Defina regras de aplicativo que permitem o tráfego para FQDNs específicos (por exemplo, *.blob.core.windows.net ou api.partner.com) e nega todas as outras conexões de saída. Essa abordagem garante que cargas de trabalho comprometidas não possam enviar dados para pontos de extremidade controlados por invasores.

Saiba mais

Próximas Etapas 

Tip

Explorando por conta própria? Retorne ao navegador de visão geral para encontrar seu próximo artigo por funcionalidade.

Próximo passo na sua jornada de migração:

Configure o firewall do hub: configure Firewall do Azure para inspeção centralizada leste-oeste e controle de tráfego de saída.

A seguir, em sua jornada de modernização:

Configure o firewall do seu hub: Configure o Firewall do Azure como SNAT/DNAT no seu hub para inspecionar todo o tráfego antes que ele chegue à camada de aplicativo.

A seguir, em sua jornada multinuvem:

Configure o monitoramento multinuvem: ambientes multinuvem são mais difíceis de solucionar problemas. Estabeleça o monitoramento antes de entrar em atividade.