Laboratório Técnico: Identify appropriate use cases for Azure NAT Gateway
Questões
Questão 1 — Múltipla Escolha
Uma equipe de desenvolvimento mantém dezenas de máquinas virtuais em uma sub-rede que precisam acessar APIs externas na internet. O time relata que, em momentos de pico, algumas requisições falham com erros de esgotamento de portas. A arquitetura atual usa um Load Balancer Standard com uma regra de saída configurada.
Qual característica do Azure NAT Gateway justifica sua adoção como substituto da regra de saída do Load Balancer nesse cenário?
A) O NAT Gateway elimina a necessidade de endereços IP públicos, roteando o tráfego por meio de IPs privados gerenciados pela Microsoft.
B) O NAT Gateway oferece um pool de portas SNAT significativamente maior por endereço IP público, reduzindo o risco de esgotamento mesmo com alto volume de conexões simultâneas.
C) O NAT Gateway distribui o tráfego de saída entre múltiplas sub-redes de forma automática, balanceando a carga de conexões SNAT.
D) O NAT Gateway substitui o Load Balancer Standard integralmente, assumindo também as funções de balanceamento de carga de entrada.
Questão 2 — Cenário Técnico
Uma empresa configurou o Azure NAT Gateway associado a uma sub-rede que contém VMs sem endereço IP público. O administrador reporta que as VMs conseguem acessar a internet normalmente, mas conexões iniciadas da internet em direção às VMs estão sendo bloqueadas, gerando reclamações de um parceiro que precisa acessar um serviço exposto nessas VMs.
Qual é a causa correta desse comportamento e qual é a abordagem adequada para resolver o problema?
A) O NAT Gateway bloqueia tráfego de entrada por padrão; o administrador deve habilitar a opção de "inbound NAT" nas configurações do recurso.
B) O comportamento é esperado: o NAT Gateway é um serviço exclusivamente de saída. Para aceitar conexões de entrada, as VMs precisam de um endereço IP público próprio ou de um Load Balancer com regra de entrada.
C) O Network Security Group da sub-rede está sobrescrevendo as regras do NAT Gateway; remover o NSG resolverá o problema.
D) O NAT Gateway precisa ser associado também à interface de rede de cada VM para permitir tráfego bidirecional.
Questão 3 — Múltipla Escolha
Um arquiteto precisa garantir que todas as VMs de uma sub-rede usem sempre o mesmo conjunto de IPs públicos ao se comunicar com um serviço externo que aplica allowlist por IP. A solução deve ser simples de gerenciar e não deve depender de configuração individual por VM.
Qual combinação representa a abordagem mais adequada?
A) Atribuir um IP público a cada VM individualmente e documentar todos os IPs para o parceiro.
B) Usar um Load Balancer Standard com regras de saída e um único IP público de frontend.
C) Associar um NAT Gateway à sub-rede com um ou mais prefixos de IP público estáticos, garantindo que todo o tráfego de saída use IPs previsíveis e gerenciados centralmente.
D) Usar uma Azure Firewall com política de SNAT para mascarar os IPs das VMs com um IP fixo.
Questão 4 — Cenário Técnico
Considere a seguinte configuração de uma sub-rede:
Sub-rede: snet-workloads (10.1.1.0/24)
- NAT Gateway: natgw-prod (associado)
- IP público do NAT Gateway: 20.x.x.10
- VM-A: sem IP público, sem Load Balancer
- VM-B: IP público próprio atribuído diretamente à NIC (40.y.y.5)
Um engenheiro afirma que ambas as VMs usarão o IP 20.x.x.10 ao acessar a internet, pois o NAT Gateway está associado à sub-rede.
Qual é a avaliação correta dessa afirmação?
A) A afirmação está correta; o NAT Gateway tem precedência absoluta sobre qualquer IP público atribuído a interfaces de rede na sub-rede.
B) A afirmação está incorreta; a VM-B usará seu próprio IP público 40.y.y.5 para tráfego de saída, enquanto a VM-A usará o IP do NAT Gateway 20.x.x.10.
C) A afirmação está incorreta; em sub-redes com NAT Gateway, nenhuma VM pode ter IP público próprio, e a configuração seria rejeitada pelo Azure.
D) A afirmação está parcialmente correta; o NAT Gateway é usado pela VM-B apenas quando seu próprio IP público estiver indisponível.
Questão 5 — Verdadeiro ou Falso
Afirmação: O Azure NAT Gateway pode ser associado simultaneamente a uma sub-rede que já possui uma rota padrão (0.0.0.0/0) apontando para uma Azure Firewall, e nesse cenário o NAT Gateway terá precedência sobre a rota definida na tabela de rotas para o tráfego de saída à internet.
Verdadeiro ou Falso?
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O esgotamento de portas SNAT é um problema clássico em arquiteturas com alto volume de conexões de saída simultâneas. O Load Balancer Standard oferece, por padrão, um número limitado de portas SNAT por instância de backend, o que pode ser insuficiente em cenários de pico.
O NAT Gateway resolve isso ao fornecer 64.512 portas SNAT por endereço IP público associado, e permite associar até 16 IPs públicos, totalizando mais de 1 milhão de portas disponíveis. Esse pool é compartilhado de forma dinâmica entre as VMs da sub-rede, sem alocação estática prévia por instância.
Os distratores representam erros comuns: o NAT Gateway não opera com IPs privados (A é falso), não faz balanceamento de carga entre sub-redes (C confunde NAT com Load Balancer), e não substitui funções de entrada do Load Balancer (D é falso). A escolha de D é um equívoco frequente de quem não distingue os planos de entrada e saída.
Gabarito — Questão 2
Resposta: B
O Azure NAT Gateway é, por design, um serviço de saída unidirecional. Ele permite que recursos sem IP público iniciem conexões para a internet, mas não aceita conexões iniciadas externamente. Esse comportamento não é uma falha de configuração nem pode ser alterado por nenhuma opção do recurso.
Para que o parceiro acesse serviços hospedados nas VMs, é necessário usar um mecanismo de entrada separado: um endereço IP público atribuído diretamente à NIC da VM ou um Load Balancer Standard com regra de NAT de entrada ou balanceamento de carga.
A alternativa A é um distrator perigoso porque soa razoável, mas a opção de "inbound NAT" simplesmente não existe no NAT Gateway. A alternativa C é incorreta porque o NSG não interfere no plano de controle do NAT Gateway; ele filtra pacotes, mas não reverte a natureza unidirecional do serviço. A alternativa D confunde associação por sub-rede com associação por NIC, que não é suportada pelo NAT Gateway.
Gabarito — Questão 3
Resposta: C
O caso de uso de allowlist por IP exige que o IP de saída seja previsível e estável. O NAT Gateway associado a um prefixo de IP público é a solução mais direta: todos os IPs do prefixo são conhecidos antecipadamente, o NAT Gateway garante que todo o tráfego da sub-rede saia por esses IPs, e a gestão é centralizada em um único recurso.
A alternativa A resolve o problema funcionalmente, mas é inviável operacionalmente em escala, pois exige configuração e comunicação individual por VM. A alternativa B com Load Balancer também funciona para um IP fixo, mas o NAT Gateway é mais adequado especificamente para cenários de saída de alta escala sem necessidade de balanceamento de entrada. A alternativa D com Azure Firewall também é tecnicamente válida, mas introduz custo e complexidade desnecessários quando o único requisito é previsibilidade de IP de saída, tornando o NAT Gateway a escolha mais precisa e eficiente para o cenário descrito.
Gabarito — Questão 4
Resposta: B
O Azure NAT Gateway respeita uma ordem de precedência para determinar qual IP público será usado no tráfego de saída de uma VM. Quando uma VM possui um IP público diretamente associado à sua NIC, esse IP tem precedência sobre o NAT Gateway da sub-rede.
Portanto, a VM-B usará seu próprio IP 40.y.y.5, enquanto a VM-A, sem IP público próprio, usará o IP do NAT Gateway 20.x.x.10. Esse comportamento é intencional e documentado, permitindo exceções individuais dentro de uma sub-rede gerenciada por NAT Gateway.
A alternativa A inverte a lógica de precedência, que é um erro conceitual sério. A alternativa C é falsa: o Azure permite VMs com IP público em sub-redes associadas a um NAT Gateway. A alternativa D também é incorreta: o IP público da VM-B é sempre utilizado para saída, não apenas como fallback.
Gabarito — Questão 5
Resposta: Falso
Quando uma tabela de rotas com rota padrão (0.0.0.0/0) apontando para a Azure Firewall (ou outro appliance) está associada a uma sub-rede, essa rota tem precedência sobre o NAT Gateway. O tráfego de saída seguirá o caminho definido na UDR (User Defined Route), ignorando o NAT Gateway.
Essa é uma distinção crítica de arquitetura: o NAT Gateway opera na camada de tradução de endereços, mas não sobrescreve decisões de roteamento definidas por UDR. Se o objetivo é forçar o tráfego pela Azure Firewall com um IP de saída previsível, o SNAT deve ser configurado na própria Firewall.
O erro conceitual desse distrator está em assumir que o NAT Gateway, por ser um serviço de saída, teria autoridade sobre o plano de roteamento. Na prática, roteamento e tradução de endereços são camadas distintas, e a UDR é avaliada antes que o NAT Gateway entre em cena.