У вас есть служба приложений Windows (Windows App Service) в регионе West Europe, которая должна получить доступ к двум внутренним сетям: (A) приватной конечной точке Azure SQL Database в виртуальной сети (VNet) также в регионе West Europe, и (B) серверу приложений в виртуальной сети, расположенной в регионе North Europe, доступ к которому возможен только через VPN-шлюз этой виртуальной сети. Приложение не должно требовать входящего подключения из этих виртуальных сетей. Какой подход к интеграции с виртуальной сетью следует использовать для каждого бэкенда?

Для A: региональная интеграция VNet позволяет службе приложений получать доступ к ресурсам в той же виртуальной сети или пиринговых сетях в том же регионе, что идеально подходит для приватной конечной точки Azure SQL Database в West Europe. Для B: интеграция VNet, требующая шлюза, необходима, когда служба приложений должна подключаться к ресурсам в другом регионе через VPN-шлюз. Это позволяет приложению в West Europe достигать сервера приложений в North Europe через VPN-шлюз. Остальные варианты не подходят, потому что: Private Endpoint в App Service используется для входящего трафика, а не исходящего. ExpressRoute FastPath не является методом интеграции VNet для App Service. Использование интеграции, требующей шлюза, для A излишне, так как ресурс находится в том же регионе. Региональная интеграция VNet не может напрямую подключаться к ресурсам в другом регионе без шлюза, даже с пирингом VNet, если требуется доступ через VPN-шлюз. Конечные точки службы используются для защиты доступа к службам Azure, а не для исходящего подключения к частным ресурсам в VNet. Azure Firewall не является методом интеграции VNet для App Service.