Vous avez un service d'application Windows en Europe de l'Ouest qui doit accéder à deux réseaux back-end : (A) un point de terminaison privé Azure SQL Database dans un VNet également en Europe de l'Ouest, et (B) un serveur d'applications dans un VNet situé en Europe du Nord qui n'est accessible que via la passerelle VPN de ce VNet. L'application ne doit pas nécessiter de connectivité entrante depuis ces VNets. Quelle approche d'intégration de VNet devriez-vous utiliser pour chaque back-end ?

Pour le backend A (Azure SQL Database en Europe de l'Ouest), l'intégration VNet régionale est la solution appropriée. Elle permet à l'App Service d'accéder aux ressources au sein du même VNet ou des VNets appairés dans la même région, y compris les points de terminaison privés. L'intégration régionale est simple et ne nécessite pas de passerelle VPN. Pour le backend B (serveur d'applications en Europe du Nord accessible via une passerelle VPN), l'intégration VNet nécessitant une passerelle est requise. Cela permet à l'App Service de se connecter à des ressources situées dans d'autres régions ou sur site via une passerelle VPN ou ExpressRoute. L'App Service utilise la passerelle VPN du VNet intégré pour acheminer le trafic vers le VNet distant. Les autres options sont incorrectes car : Un Private Endpoint sur l'App Service n'est pas une fonctionnalité standard. ExpressRoute FastPath est une fonctionnalité d'ExpressRoute, non directement applicable à l'intégration VNet de l'App Service dans ce scénario. L'intégration VNet régionale ne peut pas traverser les régions sans passerelle. Les points de terminaison de service sont pour l'accès aux services Azure PaaS, pas pour l'intégration VNet complète. Azure Firewall pour NAT ne résout pas le problème de connectivité VNet inter-régions via une passerelle.