Page 42 - MSDN Magazine, April 2017

Azure Virtual Network App Service
Environment
Front Ends ILB
Workers subnet
HTTP/HTTPS FTP
Azure Virtual Network
App Service Environment
Front Ends
Workers subnet
HTTP/HTTPS FTP
Figure 1 App Service Environment High-Level Networking Model
address for the apps in the ASE. The nature of the multi-tenant app service is that the inbound and outbound addresses are shared by multiple tenants. While it is possible to set up IP SSL for an app and get an IP address assigned to that app, there is no way to lock down the outbound address.
The nature of the multi-tenant app service is that the inbound and outbound addresses are shared by multiple tenants.
Hosting the ASE in a VNet is a great first start, but it still didn’t completely solve the isolation problem when the ASE was first released. The ASE still needed a public virtual IP (VIP) for HTTP/S and publishing access. It also deployed only in classic VNets, which was a problem for many customers.
(WAF)-fronted applications and two-tier applications. For WAF-fronted ASE appli- cations, a customer could use a WAF virtual device to act as the Internet endpoint for its ILB ASE-hosted apps, which adds an additional security layer for Internet- accessible apps. In a two-tier application, the Web-acces- sible app could be hosted in either the multi-tenant app service or from another ASE, and the back-end- secured API apps could then
be hosted in the ILB ASE. If you used the multi-tenant App Service for such a purpose, you’d then use the VNet Integration feature to securely access your API apps.
When the ASE was originally designed and planned, the assump- tion was that it would cater to IT professionals who’d want to control this personal deployment of the App Service as if it was a system they ran in their own datacenters. With that in mind, ASE was designed to be flexible. An ASE has two role types to manage: the front ends that act as the HTTP endpoints for applications and the workers that host the apps. You can scale out the quantity of either, as well as change the size of the virtual machine (VM) used for that role type.
There were certain consequences to thinking this way—the ASE roles were treated as resources that system administrators would independently manage, but it turned out that customers didn’t want to be or have system administrators for their cloud services. They wanted the ASE to remain as easy to use as the multi-tenant App Service. Having to manage the resource pools and their apps was too confusing and affected feature adoption.
VIP
To solve those problems, sup- port was added in June 2016 for Resource Manager VNets and also for internal load balancers (ILBs), as shown in Figure 2.
The addition of ILB support meant that customers could now host intranet sites in the cloud. You could take an LOB application that you didn’t want to be Internet- accessible and deploy it into your ILB-enabled ASE. The ILB sits on one of the VNet IP addresses, so it’s accessible only from within the VNet or from hosts that have access to the VNet over a VPN.
The ILB-enabled ASE opened the door to other possibilities, such as Web application firewall
Figure 3 Creating an App Service Plan in ASEv1
30 msdn magazine
Microsoft Azure
Figure 2 App Service Environment High-Level Networking with an Internal Load Balancer