Je hebt een Windows App Service in West-Europa die toegang moet hebben tot twee back-end netwerken: (A) een Azure SQL Database private endpoint in een VNet, eveneens in West-Europa, en (B) een applicatieserver in een VNet in Noord-Europa die alleen bereikbaar is via de VPN-gateway van dat VNet. De app mag geen inkomende connectiviteit van die VNets vereisen. Welke VNet-integratieaanpak moet je voor elke back-end gebruiken?

Voor A is regionale VNet-integratie de juiste keuze omdat de App Service en het VNet zich in dezelfde regio bevinden. Dit maakt directe toegang tot het private endpoint van de Azure SQL Database mogelijk. Voor B is gateway-vereiste VNet-integratie nodig omdat het back-end VNet zich in een andere regio bevindt en alleen toegankelijk is via een VPN-gateway. De App Service kan dan de gateway gebruiken om de applicatieserver in Noord-Europa te bereiken. De andere opties zijn onjuist: Private Endpoints op de App Service zijn voor inkomende connectiviteit, niet voor uitgaande toegang tot back-ends. ExpressRoute FastPath is geen VNet-integratieoplossing. Gateway-vereiste VNet-integratie voor A is onnodig omdat het VNet in dezelfde regio is. Regionale VNet-integratie voor B werkt niet omdat het VNet in een andere regio is en toegang via een gateway vereist. Regionale VNet-integratie werkt niet cross-region zonder een gateway. VNet-peering is een aanvullende configuratie, geen vervanging voor de juiste VNet-integratiemethode. Service-endpoints zijn voor het beveiligen van verkeer naar Azure-services, niet voor toegang tot private endpoints van SQL Database. Azure Firewall NAT'en lost het probleem van cross-regionale VNet-toegang via een gateway niet op.