Azure App Service

Networking considerations

As discussed, you must consider numerous deployment and operational issues when deciding on the most appropriate strategy to set up a new App Service in Azure. Similarly, you need to consider various networking solutions. The following sections cover the different networking services that are supported for integration with Azure App Service and some best practices associated with each.

By default, App Service allows all hosted apps to be accessible over the public internet. Although that might be appropriate for a large number of customer-facing apps, numerous internal or protected applications require more granular control over inbound and outbound traffic. You can set up numerous Azure services and App Service features to provide the required level of protection. Each service can help in addressing the requirements in different ways; thus, it is important to understand how each one works to design the right strategy for App Service networking.

Service endpoints and private endpoints

Azure App Service offers two types of deployment scenarios:

• Free, Shared, Basic, Standard, Premium, PremiumV2, and PremiumV3 pricing SKUs Apps are hosted on a multi-tenant infrastructure.

• Isolated SKU App Service plan A single-tenant ASE hosts all the apps directly in the client’s Azure virtual network.

In a multi-tenant scenario, service endpoints enable you to define inbound traffic restrictions, allowing traffic only from a set of trusted subnets to connect to the web app. In this way, you can restrict traffic to only required resources such as VMs, other ASEs, or even other apps that use VNet Integration.

Private endpoints are available only in the PremiumV2 and PremiumV3 tier App Service plans. They allow apps hosted on the multi-tenant infrastructure to be securely connected to the customer’s virtual private network. So, all inbound traffic to the web app from the customer’s virtual network flows over a secure and private connection. (See Figure 3-47.)

Some key benefits of using a private endpoint include the following:

• You can restrict inbound app access to resources in a specific virtual network.

• Users and resources within the connected virtual network can access apps using an internal private IP.

• You can use a web application firewall (WAF) used along with a private endpoint for enhanced protection.

• Data leakage and data theft are difficult, as the app is accessible only on a protected network.

Some limitations when using private endpoints include the following:

• A web app can support only 100 private endpoints.

• Remote debugging is not supported.

• FTP access to the web app is not allowed.

FIGURE 3-47 Private endpoint connections.

VNet integration

VNet integration helps multi-tenant apps access resources in other Azure VNet and interconnected networks. It provides outbound access from the app to the VNet and connected networks. This makes it possible for the app to access any resource located inside those networks.

This feature has two variations:

• Regional integration This is when the integration is with a VNet within the same Azure region as the app. Regional integration requires a dedicated subnet in the VNet for integration.

• Gateway-required integration This is when the integration is with a VNet in another Azure region or with a classic VNet in the same region. Here, an Azure virtual network gateway is provisioned in the destination VNet for the integration.

Regional VNet integration

As mentioned, regional VNet integration is when the App Service is integrated with a VNet in the same Azure region as the app. This enables apps to access resources located within:

• The same region as the app

• Any VNet peered with the integrated VNet

• Any networks connected via ExpressRoute to the integrated VNet

• Service-endpoint secured services

• Private endpoint resources

Some restrictions with regional VNet integration include the following:

• The integration subnet must be unused and dedicated to only one App Service plan.

• The integration subnet must be /28 or larger.

• Classic VNet is not supported.

• Only one regional VNet is supported per App Service plan.

Gateway-required VNet integration

Gateway-required VNet integration is useful when an app requires access to resources located in:

• An Azure VNet in a region different from the app

• An Azure classic virtual network in the same or different region

This requires an Azure Virtual Network gateway configured with an SSTP point-to-site VPN for the integration. Once integrated, the apps can get access to resources located within:

• Any VNet peered with the integrated VNet

• Any networks connected via VPN to the integrated VNet

Some restrictions with gateway-required VNet integration include the following:

• No support for Azure ExpressRoute connections.

• Only one VNet at a time can be connected.

• An App Service Plan supports a maximum of five VNet integrations.

Traffic Manager and Azure Front Door

You can use Traffic Manager and Azure Front Door to control and distribute requests from web clients across App Service endpoints. These endpoints, which are geographically dispersed, are set to Active or Passive; based on the routing logic applied, traffic is redirected, taking into account the availability and load on the App Service endpoint.

Azure Traffic Manager is a global DNS-based load-balancing service that distributes traffic among back-end application nodes based on a load-balancing algorithm you select. It provides a public endpoint that diverts incoming client requests to the available application node hosted in Azure or in another external service.

Azure Front Door is great for application acceleration and global HTTP(S) load balancing. It provides more features than Traffic Manager and is highly recommended for use with App Service. It supports SSL offloading, Application layer processing, AnyCast routing, and content caching for faster performance and security against DDoS attacks.

Three primary routing algorithms overlap between Traffic Manager and Front Door:

• Latency/performance The closest app is selected based on the lowest network latency to the back ends.

• Priority Priority is given to the primary app defined in the configuration. Other locations hosting the same app are set up as backups so that traffic can be failed over if the primary is unavailable.

• Weighted Traffic is distributed across a set of apps evenly or based on a weight assigned to each app.

In addition to these three, Traffic Manager provides one additional routing algorithm:

• Performance Users are redirected to the closest app region based on their network latency to the app location.

Similarly, Azure Front Door provides one additional routing algorithm:

• Geographic Users are redirected to apps that are closest to their geographic location.

Hybrid Connections

The Hybrid Connections feature helps connect an app to on-premises resources over a secure port. It does this by setting up a relay agent, called Hybrid Connection Manager (HCM), that requires access to both the on-premises endpoint and App Service over port 443. Once the relay agent is operational, the app hosted in Azure can access resources on any TCP-enabled host endpoint on any port or application protocol. The connection is secured using TLS 1.2; in addition, shared access signature (SAS) keys authenticate and authorize resource access.

Some of the main benefits of using Hybrid Connections are as follows:

• Secure access to on-premises resources over private or public networks.

• Service-based provisioning, making it fast to set up and configure.

• Works on port 443, making it easier to handle across most firewalls.

• Multiple networks can be accessed using the same relay agent.

• No dependency on application protocol, language, or port requirements, as long as TCP support is available.

However, Hybrid Connections has a few limitations:

• It only supports TCP. It does not support the UDP protocol.

• It cannot be used to mount network-enabled drives remotely to the app.

• It uses dynamic port mapping for app access.

Network security groups

You can use network security groups (NSGs) to block both ingress and egress traffic to all resources in a VNet. For apps that use the regional VNet integration feature:

• Egress traffic can be managed using NSGs.

• Ingress traffic management requires the use of the Access Restrictions feature.

Route tables

Route tables help to set up custom routes required to enforce a specific routing configuration. You can use route tables to route outbound traffic as needed.

Azure DNS private zones

Once an app is integrated into a VNet, the DNS server configured for the VNet is applied to the app as well. If the VNet is set to use Azure DNS private zones, this would cause issues for the app, because by default, it does not support private DNS zones. However, you can enable this support configuring application settings to force all outbound traffic from the app via the VNet and require the use of the Azure DNS private zone.