In this last video, we're going to cover App Service environments and specifically how your clients will access them. 

App Service environments are slightly different from a standard public-facing App Service which we talked about in the first few videos. Let's start by really asking what actually is an application service environment or an ASE is.

First of all, it is still an App Service, and it has all of the same capabilities and features that a standard App Service does, meaning that it is a PaaS service and Microsoft is in fact going to be managing it. However, it gets deployed into an Isolated Tier based App Plan and as such when it does get created, Microsoft is going to ask you for a Virtual Network that it can be placed into and it exists solely within that virtual network.

All of the other features and capabilities of the App Service still apply, but now instead of it having a public IP address and a public name, it is going to exist inside of your virtual network, and it will have a CNAME that Microsoft applies, but it will only be accessible from within that Virtual Network until you define otherwise. It can have both internal and external endpoints, but most customers that I have worked with have used it strictly for internal purposes or they have created a public endpoint using another device such as a network virtual appliance, Azure Application Gateway or the like and it can allow for both inbound and outbound traffic.

Now, if you'll remember correctly from the App Service VNet integration we talked about in the first few videos, the App Service only had the ability to talk into services inside of the virtual network, not the reverse. Services inside of the virtual network could not talk to the App Service or could not instigate traffic with the App Service. Only the App Service could instigate traffic with services in the VNet. 

With an Application Service Environment, the traffic can be instigated in both ways. Both internal services and the Application Service Environment can see one another.

From a client access perspective, you're going to access the application service environment in much the same way that you do with any infrastructure as a service-based solution. 

You can allow for port forwarding from a jump box or Azure Bastion for example.

You can allow for traffic through an internal or external load balancer. Remember, App Services have a load balancer attached to them by default to allow for scalability. You can define whether that load balancer will have a private endpoint or a public endpoint, and Microsoft does supply different CNAMEs for each specific solution. 

You can use User Defined Routes for any traffic coming in and out of that App Service. So if you want the traffic to go through an intrusion detection/prevention device or a web application firewall, you can absolutely force that. 

The one key factor that a lot of my customers have done over the years is they have created these App Services to reduce the amount of administration overhead and allowed their internal users on their internal networks On-Premises to be able to access these App Services via an ExpressRoute.

So, there's any number of different options for accessing the App Service, but the key factor here is that the App Service is still in App Service. It's just now isolated, and network secured like an infrastructure as a service-based solution would be.

With that, we'll wrap up the course with a conclusion video. Hope you've enjoyed this and I hope to see you soon.