Hi there. In this video, we're going to be focusing on the VNet and the configurations that are required the VNet and the configurations that are required in order for an App Service to integrate with it and we'll take a look at both a regional version as well as a global version. But before we do that, let's take a look at some specific features that are allowed inside of your virtual network that you can actually use from a networking perspective.

So, for example, once your network has been integrated with your App Service, you absolutely can prevent or allow traffic using network security group rules for that App Service for what services, VMs, what have you, it can actually talk to successfully once that traffic has entered in. Any kind of routing that you would want to implement. Maybe you want to make sure that traffic that comes from that App Service runs through intrusion detection/intrusion prevention, maybe you want it to run through a web application firewall.

There are any number of different possibilities for how you might want to route that traffic in order for you to make sure that traffic is correct, you can absolutely implement user-defined routing, whether that be application routing or network routing. You can absolutely use Azure Private DNS Zones.

So, once that integration has been implemented, if you want to allow access to a service inside of that virtual network from the App Service, there is absolutely no reason why you can't define the name of that service in your virtual network using Azure Private DNS Zones and the App Service because the integration has been implemented or connected, we'll be able to see where that service exists and be able to resolve it correctly.

Let's go ahead and jump on into the Azure portal and let's take a look at both of the virtual networks that I have deployed and the integrations or configurations that I have set within them. The first one that we'll take a look at is the South Central or the regional virtual network that's in the same region as our App Service and this is just the overview page. The key configuration here is within the subnets. Once we look in the subnets, the primary requirement, as I talked about at the beginning, is to make sure that you have a dedicated subnet just for the App Service. And you can actually see that here under Delegated 2, there is a Microsoft.Web/ServerFarms. That corresponds to the resource provider for App Services. That corresponds to the resource provider for App Services. Don't get worried about that name. That name has been around for an extremely long time, and it is extremely difficult to change those names, hence why it is still in existence. But you can absolutely see that your App Service has been integrated with this particular subnet.

Now, remember I talked about the ability to leverage other types of PaaS services to leverage other types of PaaS services that have been connected to your virtual network. So, if we were to actually go to our subnet endpoints, for example, I absolutely-- and I absolutely have one here configured for a service endpoint for Microsoft.SQL. I could very easily add KeyVault, Event Hub, Cognitive Services. Any of those that you want to take advantage of and access from your App Service, you can do that by creating the necessary service endpoints and allow the traffic to flow through your virtual network, maybe for those reasons that I talked about earlier where you want your traffic to be routed through intrusion detection prevention, web application firewalls, things like that. That would be a reason for routing that traffic through to virtual network to a service endpointed-based service. And Microsoft has been over the years adding more and more services, PaaS-based services, to this list.

Now, you can also route your traffic or connect to private endpoint-based services. Those actually don't show up here. The private endpoints are associated directly with the individual, say Microsoft.SQL or Azure.PostGreSQL or Azure.MySQL when you create those private endpoints and those private endpoints have been connected to the virtual network, then you'll be able to connect to those CNAME records associated with those services appropriately.

Now, on the global virtual network side, I have a separate virtual network that is sitting in North Central US and the big key thing here, right here on the overview page to see, is that I have a connected device called my VNet gateway. This is the required piece that needs to be in place in order for a global App Service VNet integration to exist in order for a global App Service VNet integration to exist because you're actually going to connect to the VNet gateway first before the App Services traffic can actually make it into the virtual network.

When you create your virtual network gateway, you will define which virtual network you're going to connect to. If you do not already have a gateway subnet created, it will create one for you and create the necessary IP range associated with it and then the network gateway will be attached. The Virtual Network Gateway does have some requirements with respect to how it is configured in order to allow for the App Service VNet integration to work, so let's take a quick look at that.

The big key thing here is the VPN type. It needs to be a route-based VPN and then, of course, it needs to be connected to the virtual network. A public IP address will be created automatically unless you already have one existing, of course, and it will be that public IP address that the App Service actually connects to in order to access the virtual network. In addition, there is one other set of configurations and that's the point to site configurations. In here you need to define an address pool that can be given to any client that connects to the virtual network gateway and it needs to be an address pool that is not going to overlap with the gateway subnet's address pool.

So, the address pool for the virtual network is in the 10. range. We needed to do something that was not in the 10. range, so I chose 192.168. In addition, you need a tunnel type to be of SSTP and the authentication type should be Azure certificate. But according to the documentation, you do not actually need to upload a cert, you just need to specify that as the authentication type. Once you've done those things, you should be able to connect to your virtual network via the VNet integration section that we showed in the last video for your App Service configurations. That should do it.

App Service VNet integration is not very difficult. It works extremely well, as I mentioned. I've implemented it with some of my customers in the past and I definitely recommend it. In the next set of videos, we're gonna start to take a look at Azure Kubernetes service and how to integrate it within the scope of a virtual network in order to privatize that deployment.