Hai un Servizio App Windows in Europa Occidentale che deve accedere a due reti di back-end: (A) un endpoint privato di Azure SQL Database in una VNet anch'essa in Europa Occidentale, e (B) un server applicazioni in una VNet situata in Europa Settentrionale raggiungibile solo tramite il gateway VPN di quella VNet. L'app non dovrebbe richiedere connettività in ingresso da quelle VNet. Quale approccio di integrazione VNet dovresti usare per ogni back-end?

Per A, l'integrazione VNet regionale è la soluzione più efficiente per connettersi a un endpoint privato nella stessa regione. Questa integrazione consente all'App Service di accedere alle risorse all'interno della VNet senza passare per un gateway VPN, riducendo la latenza. Per B, poiché il server applicativo si trova in una VNet in una regione diversa e accessibile solo tramite il suo gateway VPN, l'integrazione VNet con gateway richiesto è necessaria. Questa opzione instrada il traffico dell'App Service attraverso il gateway VPN della VNet remota, consentendo l'accesso interregionale. Le altre opzioni sono errate perché: un Private Endpoint sull'App Service non è un meccanismo di integrazione VNet; ExpressRoute FastPath non è un metodo di integrazione VNet diretto per App Service; l'integrazione VNet con gateway richiesto non è necessaria per risorse nella stessa VNet; l'integrazione VNet regionale non può attraversare un gateway VPN per connettersi a una VNet remota senza un gateway esplicito; gli endpoint di servizio non sono l'opzione migliore per endpoint privati e Azure Firewall non è un meccanismo di integrazione VNet per App Service.