Por padrão, o App Service só enxerga a internet — nada de banco em VM privada, Redis com endpoint privado ou API atrás de um firewall interno. A VNet Integration Regional resolve exatamente isso: conecta o app a uma subnet dedicada da sua rede virtual, sem precisar do App Service Environment (ASE) nem de nenhuma infraestrutura extra.
Neste guia rápido você vai preparar a subnet, ativar a integração via Azure CLI e entender a diferença entre integração padrão (só tráfego privado) e roteamento total do tráfego de saída pela VNet.
Sumário
- O que a VNet Integration Regional faz (e o que não faz)
- Pré-requisitos
- Passo 1 — Preparar a subnet dedicada
- Passo 2 — Ativar a integração
- Passo 3 — Rotear todo o tráfego de saída (opcional)
- Passo 4 — Validar a conectividade
- Troubleshooting comum
- Conclusão
- Referências oficiais
O que a VNet Integration Regional faz (e o que não faz)
É fácil confundir com Private Endpoint, mas são coisas complementares: a VNet Integration Regional dá saída — o app passa a alcançar recursos dentro da VNet, redes peered e, via VPN/ExpressRoute, até o datacenter on-premises. Ela não dá acesso privado de entrada ao próprio app (isso é papel do Private Endpoint) e não muda o endereço público que os visitantes usam pra chegar na aplicação.
Pré-requisitos
O recurso exige plano Standard, Premium ou Elastic Premium — não funciona no Free, Shared ou Basic. A VNet precisa estar na mesma região do App Service (dá pra alcançar outras regiões depois via peering, mas a integração em si é sempre regional).
Passo 1 — Preparar a subnet dedicada
A integração precisa de uma subnet só pra ela — sem outros recursos usando os IPs, e delegada ao serviço Microsoft.Web/serverFarms. O tamanho mínimo é /28, mas em produção vale reservar /26 ou /27 pra ter espaço de escala:
az network vnet subnet create \
--resource-group rg-appservice-lab \
--vnet-name vnet-appservice \
--name snet-integration \
--address-prefixes 10.0.1.0/27 \
--delegations Microsoft.Web/serverFarmsPasso 2 — Ativar a integração
az webapp vnet-integration add \
--name meuapp-prod \
--resource-group rg-appservice-lab \
--vnet vnet-appservice \
--subnet snet-integration
az webapp vnet-integration list \
--name meuapp-prod \
--resource-group rg-appservice-lab \
-o tableEm PowerShell, o mesmo resultado sai apontando o ID da subnet direto no app:
$subnet = Get-AzVirtualNetworkSubnetConfig -Name snet-integration `
-VirtualNetwork (Get-AzVirtualNetwork -Name vnet-appservice -ResourceGroupName rg-appservice-lab)
Set-AzWebApp -ResourceGroupName rg-appservice-lab -Name meuapp-prod `
-VirtualNetworkSubnetId $subnet.IdPasso 3 — Rotear todo o tráfego de saída (opcional)
Por padrão, só o tráfego pra endereços privados (RFC 1918) passa pela VNet — chamadas pra internet continuam saindo direto. Se você tem um firewall central (Azure Firewall, NVA) e quer que todo o tráfego de saída passe por ele, habilite o roteamento total:
az webapp config set \
--name meuapp-prod \
--resource-group rg-appservice-lab \
--generic-configurations '{"vnetRouteAllEnabled": true}'Com isso ativo, uma UDR (User Defined Route) na subnet de integração apontando pro firewall passa a valer também pro tráfego de internet do app — inclusive chamadas a APIs públicas, então vale revisar as regras do firewall antes de ativar, ou a aplicação perde acesso à internet de uma hora pra outra.
Passo 4 — Validar a conectividade
O jeito mais direto de confirmar que a integração está funcionando é testar a partir de dentro da aplicação, via Kudu/SSH do App Service, alcançando um recurso que só existe na rede privada (por exemplo, uma VM ou um banco com firewall fechado pra internet):
# Dentro do console SSH do Kudu (https://meuapp-prod.scm.azurewebsites.net/webssh/host)
curl -m 5 -v telnet://10.0.2.4:1433Uma conexão recusada ou aceita já confirma que o pacote chegou até o destino privado — um timeout, por outro lado, geralmente aponta pra NSG bloqueando ou rota errada.
Vale rodar esse teste logo depois de ativar a VNet Integration Regional, antes de assumir que a aplicação em si tem algum problema — muita investigação de “bug na aplicação” na verdade é rede ainda não propagada ou NSG bloqueando, coisas que esse curl resolve em segundos.
Troubleshooting comum
| Sintoma | Causa | Solução |
|---|---|---|
Subnet is not empty ou already delegated | Subnet com outros recursos ou delegada a outro serviço | Usar uma subnet nova e vazia, dedicada só à integração |
| App não alcança recurso privado | NSG na subnet de integração bloqueando saída | Revisar regras outbound da NSG associada à subnet |
| App perde acesso à internet depois do route-all | UDR aponta pro firewall, mas a regra de saída pra internet não existe lá | Adicionar regra de rede/aplicação liberando os destinos necessários no firewall |
Integração “presa” em Failed | VNet em região diferente do App Service | Confirmar que VNet e App Service estão na mesma região |
| DNS privado não resolve dentro do app | VNet sem os DNS servers customizados/privados configurados | Apontar o DNS da VNet pro Azure DNS Private Resolver ou pro servidor DNS correto |
Conclusão
A VNet Integration Regional é o caminho mais simples pra tirar o App Service do isolamento e conectá-lo à sua rede privada — sem ASE, sem custo extra de plano, só uma subnet dedicada e um comando. Combinada com Key Vault References pros segredos, dá pra chegar bem perto de um ambiente enterprise sem sair do plano Standard.
Referências oficiais
- VNet Integration Regional no App Service (Microsoft Learn)
- Habilitar VNet Integration (Microsoft Learn)
- az webapp vnet-integration — referência da CLI (Microsoft Learn)
Interessado em saber mais sobre artigos relacionados a Microsoft Azure CLIQUE AQUI
🚀 Vamos nos conectar?
Não perca nenhuma oportunidade! Cadastre-se nas minhas redes e no canal do YouTube para receber conteúdos de TI, Cloud, Azure, AWS, Kubernetes e DevOps em primeira mão.
Dica: no Facebook, todos os artigos do blog são publicados automaticamente. Vale a pena curtir!
💬 Dúvidas ou problemas?
Com o intuito de ajudar a comunidade, caso você tenha dúvidas ou encontre problemas na execução dos comandos deste artigo, deixe um comentário abaixo. Responderei o mais breve possível!
Muito obrigado pela visita e até o próximo post!
Jefferson Castilho Especialista em Cloud & DevOps.Este guia técnico é exclusivo do Blog do Castilho. Explore mais conteúdos sobre Cloud e DevOps.