Hi there, let's continue our discussion of VNet integrations by starting with an overview of the VNet integration with an Azure App Service: what the capabilities are, what the features are, and what things you can't do with respect to App Service VNet integration.

As an overview, the VNet integration gives you access to services within your VNet from your App Service. For example, if you want to maybe make your database more tightly locked down than leveraging a PaaS service, you can place a virtual machine inside of your virtual network and then make your App Service leverage that database, rather than something that has a public endpoint.

The App Service VNet integration does not provide access to your App Service from services inside of your virtual network.

The App Service will still accept public endpoint access, and if you do need to talk to the App Service from within your virtual network, you will need to use that public routing to get there.

Now from a feature and requirements perspective, when you deploy your App Service you will need to take advantage of one of the following tiers of your App Service Plan:

• Standard Tier
• One of the versions of Premium Tier
• Elastic Premium Tier.

You'll notice that neither one of the shared tiers are listed: the free or the basic tiers. In addition, the isolated tier is not listed either, because that one is associated with App Service Environments, which we will talk about in a later video.

The VNet integration supports both TCP and UDP traffic when connecting to your virtual network and it works with both standard App Services, whether they be code-based or container-based as well as Function-based App Services for your service connectivity.

I can tell you from my own personal experience that I've leveraged the Function app VNet integration, and I've done it across ExpressRoute connections to an On-premises network.

A single App Service can connect up to five separate VNets and have them all be integrated at the same time, thereby allowing you to take advantage of services that are in different VNets within the same region as well as in other regions.

With that being a starting point, there are two different kinds of VNet integration. There's regional, which refers to the App Service and the virtual network being in the same region. Then there is global, where they are in different regions.

Regional requires a dedicated unused subnet. The subnet can't even have service endpoints associated with it. It has to be completely empty.

For global VNet integration, there is going to be a requirement for a virtual network gateway to be attached to the virtual network that you want to connect to that is in the different region.

What kind of resources can you integrate with or can you access from your App Service? 

• You can access any resource that is sitting in the virtual network itself.
• You can access any service endpoint or private endpoint secured service
• You can access any resource that is in a peered virtual network, meaning any virtual network that is automatically connected via virtual network peering to the one that the App Service is integrated with.
• You can access resources across Azure ExpressRoute connections where the ExpressRoute is connected to the virtual network that the App Service is integrated with

Keep in mind, in both the Peering scenario as well as the ExpressRoute scenario, you will need to make sure that the traffic does flow in both directions. This is represented by a check box when you set up the peering or is managed by your VPN routing.

Now let's take a look at what all of this means, how you would actually set up these configurations inside of the Azure portal, and we'll do that by looking at App Services first in the next video.