问题
Why do we have to create a new subnet or add the app service to an empty subnet in our vnet? I don't understand the reasoning since I'm trying to use my app service (function app) as a reverse proxy to access the resources in the vnet.
回答1:
By default, the Azure function is a PaaS as the other Azure Platform-as-a-Services that have inbound and outbound traffic over the Internet. We can host our applications without the need to worry about the maintenance of the servers and their operating systems.
To use Azure Functions to connect to resources in an Azure virtual network, we can use the VNet integration feature. To use this feature, we need to create a subnet in the virtual network for your function app to use. VNet Integration must be configured to use an empty subnet. It doesn't matter that your functions use a different subnet than your VM. The virtual network automatically routes traffic between the two subnets. Read Connect your function app to the virtual network
The extra empty subnet is used to hosting your app instance. To let the app instance outbound traffic work like from a VNet, Azure mounts NICs with assigned private IP addresses in that subnet. With VNet integration, your function app is connected to both the internet and your virtual network.
For more information, you may read How regional VNet Integration works and How gateway-required VNet Integration works
回答2:
For an app to access resources in a Virtual Network, it needs to be either part of that network, or use a VPN gateway, which in turn can be used access resources inside the Virtual Network.
App Services provides 2 methods to communicate with resources in the Virtual Network:
- Regional VNet Integration
- Gateway-Required VNet Integration
With Regional VNet Integration, the infrastructure allocates a private IP interface on the VM that is hosting your Web App. This interface is allocated an IP address from the integrated subnets address prefix. This interface is later used to communicate with the VNet hosted resources. This is in a way similar to how IaaS VM work, however the limitation of this interface is that it can be only used for making outbound connections.
This way, if the ASP is configured to scale out to multiple VM's then each VM is allocated a corresponding private IP interface. However, the allocation of these IP address is limited to the subnets Address prefix. Nancy has already included this in her post. App Services have overlapped recycling so during scale up/maintenance, the App Service Plan may run on twice the number of VM's to ensure minimal downtime. However this also means, that the Integrated Subnet should have sufficient addresses available, so that these allocations can happen.
The IP Address of this interface is exposed via the environment variable WEBSITE_PRIVATE_IP. Here is a screenshot of my Kudu Console
If your site is running on multiple instances, then you can use the Instance menu to toggle through the instances.
With Gateway-required VNet Integration, there is a pre-requisite of provisioning a Virtual Network route-based gateway configured with an SSTP point-to-site VPN. In this case, the VM's hosting the Web App download the VPN package on the respective VM's to setup a VPN, and this is used to connect to the resources in the Virtual Network.
Even here, you can use the WEBSITE_PRIVATE_IP environment variable to see the IP Address used by the VPN client on the App Service VM.
HTH, Kaushal
来源：https://stackoverflow.com/questions/66058440/why-extra-subnet-for-vnet-integration-for-app-services