Você tem um Serviço de Aplicativo Windows na Europa Ocidental que deve acessar duas redes de back-end: (A) um endpoint privado do Banco de Dados SQL do Azure em uma VNet também na Europa Ocidental e (B) um servidor de aplicativos em uma VNet localizada na Europa do Norte que pode ser alcançado apenas através do gateway VPN dessa VNet. O aplicativo não deve exigir conectividade de entrada dessas VNets. Qual abordagem de integração de VNet você deve usar para cada back-end?

Para A, a Integração de VNet regional é a solução correta. Ela permite que o App Service acesse recursos em uma VNet na mesma região (Europa Ocidental) através de uma sub-rede delegada, como o Private Endpoint do SQL Database. Para B, a Integração de VNet que exige gateway é necessária. Como o servidor de aplicativos está em uma VNet diferente (Europa do Norte) e o acesso é via gateway VPN, essa integração permite que o App Service se conecte à VNet remota através do gateway VPN. As outras opções estão incorretas porque: Usar um Private Endpoint no App Service não é uma integração de VNet para acessar outros recursos. ExpressRoute FastPath não é uma opção de integração de VNet para App Services. Usar integração que exige gateway para A é desnecessário, pois a integração regional é mais simples para a mesma região. Integração regional para B não funcionaria para acesso via gateway VPN em outra região. O emparelhamento de VNet não é uma integração de VNet para o App Service; ele conecta VNets, mas o App Service ainda precisa de integração para acessá-las. Service Endpoints habilitam o acesso de VNet a serviços PaaS, não o contrário. Azure Firewall não é uma solução de integração de VNet para o App Service.