App Service plans

App Service plans identify the hardware computing resources made available to the App Service to run the required web, API, and mobile apps. Depending on what plan you select, computing resources are dedicated solely to your organization or shared among customers. The App Service plan also defines the specifications of the back-end VM series that is allocated. This, in turn, affects the number of applications that can be hosted using those resources.

When you create an App Service plan, you must define certain parameters for that plan. These include the following:

• The pricing tier (Free, Shared, Dedicated, Isolated, etc.)

• The region in which the apps will run (Central US, West Europe, East Asia, etc.)

• The size of the VM instances required (small, medium, large)

• The total number of VM instances required

Once the preceding parameters are defined, the resources identified in the plan are created in the selected region. Thereafter, the resources are made available for the hosting of the required apps.

Choosing the right pricing tier is key. Table 3-1 reviews the four pricing tiers.

Azure App Service Environments

Earlier, I mentioned that the Isolated pricing tier deploys apps in an App Service Environments (ASE). An ASE is a dedicated, fully isolated environment provisioned to run apps with high levels of security and scalability. An ASE can host Windows or Linux web apps, mobile apps, function apps, and Docker containers.

Although all application workloads can be hosted in an ASE, considering the cost implications, there are certain workload types that are more appropriate for ASEs than others. When deciding if an ASE is the best choice for an app, consider these factors:

• Does the app require complete isolation and secure access to on-premises resources?

• Does the app have high memory requirements that are not met by the Dedicated tier?

• Does the app require a very high level of scalability?

If the answer to all or most of these questions is yes, then an ASE might be the appropriate choice.

Here is a list of some examples of functionality that is only possible when using an ASE:

• Hosting apps in a single-tenant environment

• Using private or internal Certificate Authority certificates

• Publishing a dedicated outbound IP address for all the apps hosted in the ASE

• Publishing and accessing apps only on a private internal IP address

• Providing the highest level of scaling possible across all App Service plans

• Securing outbound network traffic with additional network controls available with integrations that are not part of the app

An ASE is assigned exclusive access to a dedicated set of compute and network resources and is accessible only from a single subscription. Each subscription supports the deployment of 100 App Service plan instances. These can be deployed in one of three ways:

• A single App Service plan with 100 instances

• 100 App Service plans with single instances in each plan

• A combination of the two

An ASE is composed of two components:

• Front ends Front ends provide HTTP and HTTPS endpoints for ingress termination and load-balancing. Front ends are added automatically as scaling operations take place to handle the additional load.

• Workers Workers host the apps deployed by a customer. You specify the size of the workers when you select your App Service plan tier.

Both components are managed services and are deployed or removed automatically as the App Service plans are sized. Because of this design, the charges associated with an ASE are fixed every month based on the plan that is selected. Additionally, every vCPU in the plan has an associated cost, which will be levied when resources are consumed.

There are two different ways to provision network access for an ASE, depending on its public access requirements:

• External ASE An internet-facing ASE is deployed with a public IP address so the apps hosted on the ASE can be accessed externally.

• Internal ASE An internal ASE is deployed using an internal load balancer (ILB) IP address so it is accessible only on internal networks. This would include any networks connected over VPN or ExpressRoute.

The public virtual IP (VIP) or the ILB IP serve as the endpoints for the termination of the different protocols for client connectivity. Because there is no direct access to the VMs running in the ASE, you can create network security groups (NSGs) to manage the network traffic within the subnet where the ASE is housed. If a site-to-site VPN or ExpressRoute connection to the on-premises environment is in place, the apps hosted in the ASE can communicate with on-premises resources.

App Service walkthrough

The following sections step you through the process of creating a basic web app using the Azure Portal, Azure PowerShell, and Azure CLI. You will use sample GitHub code provided by Microsoft to create a static HTML website, which you will use later to create a Hello World web app.

# Set the public GitHub repository URL, AppName and Location variables.
$githubrepo="https://github.com/Azure-Samples/html-docs-hello-world.git"
$appname="MBSPWebApp01"
$location="East US"
$resourcegroup="AppServiceRG01"
# Create a resource group to host the App Service.
New-AzResourceGroup -Name $resourcegroup -Location $location
# Create an App Service plan in Free tier.
New-AzAppServicePlan -Name $appname -Location $location -ResourceGroupName $resourcegroup -Tier Free
# Create a web app using the App Service Plan.
New-AzWebApp -Name $appname -Location $location -AppServicePlan $appname -ResourceGroupName $resourcegroup
# Configure GitHub deployment from your GitHub repo and deploy once.
$PropertiesObject = @{
    repoUrl = "$githubrepo";
    branch = "master";
    isManualIntegration = "true";
}
Set-AzResource -Properties $PropertiesObject -ResourceGroupName $resourcegroup
-ResourceType Microsoft.Web/sites/sourcecontrols -ResourceName $appname/web
-ApiVersion 2015-08-01 -Force

#!/bin/bash
# Set the public GitHub repository URL, AppName and Location variables.
githubrepo=https://github.com/Azure-Samples/html-docs-hello-world.git
appname=MBSPWebApp01
location=EastUS
resourcegroup=AppServiceRG01
# Create a resource group to host the App Service.
az group create --location $location --name $resourcegroup
# Create an App Service plan in Free tier.
az appservice plan create --name $appname --resource-group $resourcegroup --sku FREE
# Create a web app using the App Service Plan.
az webapp create --name $appname --resource-group $resourcegroup --plan $appname
# Configure GitHub deployment from your GitHub repo and deploy once.
az webapp deployment source config --name $appname --resource-group $resourcegroup
--repo-url $githubrepo --branch master --manual-integration

Select an appropriate deployment source

One of the first steps in the deployment process is to identify the location where the application code will reside during the development, test, and production phases. There are two main options for this:

• A single centralized source for all phases This approach involves using a centralized source such as GitHub, Azure Repos, or Bitbucket, where all the code can reside for deployments as needed.

• A hybrid approach This approach involves using a combination of sources: a centralized source for testing and production and a local source on the developer’s local storage for development.

The recommended approach for any enterprise environment is to identify a centralized source so that all the code repository structures can be built and maintained centrally, and code backups can be performed on a regular basis. For example, App Service has built-in integration with GitHub, which can be easily set up when the GitHub environment is online.

Deployment source walkthrough

The following sections step you through the process of setting up a different deployment source for the static web app you created earlier using the Azure Portal, Azure PowerShell, and Azure CLI. If you are following along, then make sure to adjust the web app name and variables as needed for each deployment.

#Set the Webapp and GitHub variables
$githubrepository="{URL-of-required-GitHub-repo}" 
$githubtoken="{GitHub-access-token}"
$webappname="{Name-Of-WebApp}"
$webapplocation="{WebApp-Azure-Region}"
# Setup GitHub token
$PropertyObject = @{token = $githubtoken;}
Set-AzResource -PropertyObject $PropertyObject -ResourceId /providers/Microsoft.Web/sourcecontrols/GitHub -ApiVersion 2015-08-01 -Force
# Configure GitHub deployment from the required GitHub repo
$PropertyObject = @{
    repoUrl = "$githubrepository";
    branch = "master";
}
# Set the Webapp with the GitHub configuration
Set-AzResource -PropertyObject $PropertyObject -ResourceGroupName {resource-group-name}
-ResourceType Microsoft.Web/sites/sourcecontrols -ResourceName $webappname/web
-ApiVersion 2015-08-01 -Force

#Set the Webapp and GitHub variables
githubrepos={URL-Of-GitHub-Repository} 
githubtoken={GitHub-Access-Token}
WebApp={WebAppName}
ResourceGroup={ResourceGroupName}
# Configure continuous deployment from GitHub. 
az webapp deployment source config --name $WebApp --resource-group $ResourceGroup
--repo-url $githubrepos --branch master --git-token $githubtoken

Build pipelines

A build pipeline helps automate the process of compiling, testing, and packaging source code for deployment. The pipeline reads the source code data from the deployment source and performs a series of predefined steps to prepare it for deployment.

The programming language used for the app build will determine the commands employed during the build process. This process can be executed using Azure Pipelines, a third-party solution, or locally.

Deployment mechanism

After an application package has been built, it is deployed into the web app. This action is called the deployment mechanism. App Service supports multiple deployment mechanisms:

• Kudu This open-source engine handles continuous deployments, provides HTTP endpoints, and manages all Git deployments in Azure App Service.

• FTP You can use this protocol to upload files from a source website directly to the web app.

• WebDeploy This client-server tool, designed by Microsoft, syncs application content and configuration to web apps.

After the selected deployment mechanism copies the code to the web app, every VM instance running the app receives a notification regarding the availability of the new files. Each instance syncs the new files from the shared location in the web app’s /wwwroot directory.

Best practices

Following are several best practices that relate to deployment.

Deployment slots

Deployment slots provide an easy way to deploy and manage code rollouts. A deployment slot creates a live App Service inside the App Service plan. You can use this to load code for testing; then, when testing is complete, you can swap the slot so the code moves to staging or production.

In the back end, the deployment slot is already live on worker instances, ready to receive connections. After the swap is performed, all settings applied to the staging or production slot will be applied to the code in the test slot (depending on which slot is selected). This makes it important to use App Service settings and connection strings to store all the required database and unique app settings required for staging or production. If this configuration is stored in the application code, the staging or production application will write to the test database instances.

It is highly recommended to use deployment slots when deploying new code to staging or production because it makes it easier to swap the previous version of the code in case of any issues. This can reduce downtime while also automating the entire DevOps pipeline workflow to build, test, and validate new code before rolling it out into production.

Deployment slots are not supported on the Free, Shared, or Basic tier plans; they are supported, however, on all plans from the Standard plan onward. For enterprise environments in which DevOps processes are in place, this would generally be the minimum plan selected. Each deployment slot has its own unique URL, which you can use to access the code in that slot for testing at no additional cost.

Along with the codebase is a group of settings that get swapped, as follows:

• General application settings, such as the framework version, web sockets, and so on

• Connection strings (you can configure these to remain with the slot)

• App settings (you can configure these to remain with the slot)

• Public certificates

• WebJobs content

• Handler mappings

There are also settings that are not transferred during a swap. You should take these into consideration and manage the code accordingly to ensure that the right settings are applied at the time of the swap. Following is a list of some of these settings:

• Publishing endpoints

• Custom domain names

• Non-public certificates and TLS/SSL settings

• Scale settings

• WebJobs schedulers

• IP restrictions

• The Always On setting

• Diagnostic settings

Deployment slots walkthrough

The following sections step you through the process of setting up deployment slots for your web app using the Azure Portal, Azure PowerShell, and the Azure CLI.

$ResourceGroup = “AppServiceRG01”
$WebApp = “MBSPWebApp01”
New-AzWebAppSlot -ResourceGroupName $ResourceGroup -name $WebApp -slot dev

az webapp deployment slot create --name MBSPWebapp01 --resource-group AppServiceRG01
--slot Dev

Deploy code continuously only in staging or testing

You should set up the continuous deployment of code only for staging or testing slots. Setting up continuous deployment for production slots can result in code going live without proper controls.

You should also set up production branch integrations against a dummy slot in the App Service. After the code is deployed in the slot, performing a swap to make the code live is a better approach, as it provides more control over the deployment and allows easy rollback in case of issues.

Use Azure DevOps

Azure DevOps can help with the automated continuous deployment of containers to the App Service. Similarly, you can use the Deployment Center for the continuous delivery of containers to the App Service. After the integration is performed, new commits to the branch will result in the automated building, tagging, and deployment of the updated container.

GitHub Actions

GitHub Actions makes it easy to build, test, and deploy code directly from GitHub to App Service. You should employ GitHub Actions if you are using GitHub as a deployment source to help automate code deployments with proper controls and change tracking.

Multiple instances for production applications

For production applications, it is highly recommended that when you design and code the app, you keep in mind that multiple instances of the application will need to run simultaneously. This might require you to code the app to handle multiple VM instances running the app without sync issues when reading or writing data.

Running a production app with one VM instance creates a single point-of-failure. Instead, you should try to run the application with at least two or three instances, splitting your resource requirements across them, instead of one large instance. This will also help you when any upgrades are performed on the underlying VM instances, because the load will be redirected to the other available instances, preventing any downtime. Fortunately, you can easily achieve this by using the scale-out services provided by your App Service plan. (See Figure 3-34.) It is recommended that you set up automated scaling when handling increased resource or load requirements; setting up a minimum number of instances for the app up front can help mitigate a lot of basic issues.

Collocation

It is a good practice to host all interconnected workloads in the same region—in other words, to collocate them. This helps reduce the following:

• Latency between workloads

• Costs incurred due to data transfer between regions

• Complexity in design and high-availability builds

Enable Always On

Always On is an App Service feature that ensures that VM instances are kept alive, even if there are no ingress requests or traffic to the VM instances for more than 20 minutes. This can help prevent the instance from going offline due to an idle timeout, thereby creating a cold-start situation that leads to delayed response times. Always On is disabled by default, but you easily enable it using the Azure Portal (see Figure 3-35), Azure PowerShell, or Azure CLI.

Disable ARR Affinity

When a client session is unexpectedly disconnected from an app, the general practice is to reconnect the user to the same app instance so the previous session can be continued. One way to do this is to enable the Application Request Routing (ARR) Affinity setting. However, when ARR Affinity is enabled, the app uses affinity cookies, which cause some VM instances to become overloaded with sessions and create load-balancing issues.

To avoid this scenario, it is recommended that you either build a stateless application or store the state information in a back-end service like a database or cache. Once that is in place, you can disable the ARR Affinity setting (see Figure 3-36), which should improve app performance.

Production hardware for production apps

As discussed, there are various App Service tiers available for deployment, and each tier offers specific hardware SKUs to meet different requirements. If the App Service plan is being used for a production application deployment, it is advisable to select hardware in the Production tier. (See Figure 3-37.) This ensures that the hardware resources available to the application are consistent and can be scaled automatically as required.

Define Health Check parameters

App Service has a Health Check feature that monitors the health status of running instances and automatically removes unhealthy instances from the load balancer to avoid disruption in service. This feature is disabled by default; however, it is recommended that you enable it. After you do, define the path that the service should poll on a regular basis to identify unhealthy instances. Be sure the path you select is available on all instances and is critical for the functioning of the application. This will help determine the accurate status of the application. (See Figure 3-38.)

Application Initialization

Application Initialization is a great feature to warm up a new application instance before it is made available to users. You can query a single URL path or multiple URL paths in the application to warm them up or trigger a script to preload cache. If not set, it can result in application instances being put into service at the time of any restart or scale-out operation, without being ready to service clients.

In such cases, the recommended approach is to set App Initialization in the web.config file to define the different custom URL paths that need to be queried to confirm that the application is completely online before the instance is put into service. If multiple URL paths are defined, App Service will wait for all the paths to confirm their status (success or failure) before the instance is made live.

Auto-Heal

Auto-Heal is an App Service feature that enables you to trigger custom actions based on high memory usage, high CPU usage, and so on. The custom actions currently supported include the following:

• Email alerts to admins or stakeholders

• Automated worker process recycling

• Memory dump collection for investigation

This is a great feature, and you can configure it using the web.config tool, the Azure Portal, Azure PowerShell, or the Azure CLI.

Auto-Heal walkthrough

The following section steps you through the process of setting up Auto-Heal using the Azure Portal.

Monitor disk space usage

The Azure Portal has an option to monitor App Service quotas, which you can use to monitor an app’s file system usage. For example, you might monitor this to ensure that the web folder has a minimum of 1 GB of free disk space for faster application restarts and scale-outs. (See Figure 3-42 and Figure 3-43.)

Enable Application Insights

Application Insights is an Azure Monitor feature to detect and analyze performance anomalies, debug code errors, and provide a better understanding of user behavior when using the app.

App Insights includes a feature called the Profiler. This feature enables you to capture the performance of the application and obtain detailed traces to identify hot code paths. (A hot code path is the one that take the longest to respond when handling a web request.) This can help you identify bottlenecks within an app and any dependencies. It also allows you to target development or troubleshooting efforts more appropriately.

Configure monitoring and alerts

Set up monitoring for important parameters and define alerts based on appropriate thresholds. These alerts can be defined on the App Service or the App Service Plan level. There are a few recommendations for monitoring and alerting that can be configured as follows:

• Average Working Memory Set This helps identify the average amount of memory in MiBs used by the app. It’s recommended to set this value based on the expected average memory requirements so that any breach is alerted.

• Average CPU Percentage This helps identify the average CPU used across all the app instances. It’s recommended to set this value high enough that alerts can help either scaling or remediation actions to be taken before any service interruptions.

• HTTP Server Errors This helps to monitor specific HTTP status codes to identify errors or issues being encountered in web requests. It’s recommended to set the value to monitor and alert for high instances of HTTP status codes greater than or equal to 400 and less than 500.

• Average Response Time This helps to monitor app responsiveness. If this value is too high, then it might indicate ongoing or imminent problems with the app. It’s recommended to set this value for alerting based on stress testing to identify appropriate thresholds for the hosted app.

• Average Memory Percentage This helps to monitor the average memory used in all the instances of the app. It’s recommended to set this value high enough that alerts can help either scaling or remediation actions to be taken before any service interruptions.

Deploy in multiple regions

One of the best ways to achieve high availability and ensure disaster recovery for an app is to deploy it across multiple regions. Doing so can help ensure that any regional outage does not impact app availability. This will require various other considerations as we’ve covered in the Disaster Recovery section later in this chapter.

However, if possible, incorporate this into the application design at the earliest stage possible.

A multi-region design can also help in routing requests to the closest datacenter based on the user’s region. This can be achieved using Azure Front Door or Azure Traffic Manager to manage all the ingress traffic and route it appropriately. This can also help load-balance traffic between multiple geographies providing global load-balancing.

Plan new app deployments in existing plans

Generally, when a new workload is deployed, there is a temporary spike in resource requirements while the workload is completely online and servicing requests, at which point things stabilize and return to earlier levels until user traffic hits the new workload. If you are deploying a new workload using an existing App Service plan, you should check the CPU and memory usage to make sure there is enough spare capacity to handle this deployment spike.

If CPU or memory utilization reaches or exceeds 90%, you should bring additional VM instances online so the overall load goes down. Then you can deploy the new workload. After deployment, the App Service plan can be scaled down based on the new average resource requirements.

Scaling

Scaling is critical for applications using App Service. It can provide both performance benefits and cost savings—which can be maximized if the scaling occurs automatically.

You can achieve scaling (up or down) by changing your App Service plan tier. Be aware, however, that while a lower-tier plan will reduce your costs, it could have an impact on performance and feature availability. Therefore, it is important to identify which features you need in order to meet your application performance requirements and use this information when selecting your plan. For example:

• Dev and test phase Use the Free tier so no compute charges are levied.

• General testing/pre-production release Use the Shared tier to leverage additional features such as custom DNS and various resources.

• Production release Use the Basic Dedicated tier to use SSL/TLS with more resources for scaling.

Scaling up or down by changing plans occurs almost immediately and requires no changes to the code or application configuration. All apps in the App Service plan are affected when scaling occurs; if you update to a higher-tier plan, each app in the plan will be able to use the new features that become available. Generally, scaling up provides access to features including (but not limited to) the following:

• More CPU, memory, and disk space

• Autoscaling

• Custom domains and SSL/TLS certificates

• Deployment slots

In contrast, scaling down by changing plans removes or reduces the feature set, depending on which plan you choose.

In addition to scaling up or down, you can also scale out or in. Scaling out increases the number of VM instances allocated to run your app(s). For example, in the Dedicated tier, with the Premium V2 and V3 plans, you can deploy 30 VM instances, whereas in the Isolated tier, you can scale out to 100 VM instances. Scaling in is the reverse of these scenarios; you might scale in to reduce costs or unused capacity.

All scaling operations can be performed manually or automatically—if your App Service plan tier supports this. Autoscaling is available only in the Standard and Premium plans on the Dedicated tier and the ASE hosted on the Isolated tier. You can perform automatic scaling based on schedules and/or metric-based rules that trigger the scaling operation.

Scaling walkthrough

The following sections step you through the process of setting up scaling for your web app using the Azure Portal, Azure PowerShell, and Azure CLI.

#Define the variables for your environment
$ResourceGroup = “{ResourceGroupName}”
$AppServicePlan = “{Name-Of-AppServicePlan}”
$Location = “{AzureRegionName}”
#Set scaling config during plan creation
New-AzAppServicePlan -ResourceGroupName $ResourceGroup -Name $AppServicePlan
-Location $Location -Tier Standard -WorkerSize Small -NumberofWorkers 3
-PerSiteScaling $true

#Set the web app variables
WebappName="AppService$random"
Location="EastUS"
ResourceGroup = “ResourceGroup01”
# Set scaling config during plan creation
az appservice plan create --name $WebAppName --resource-group $ResourceGroup
--location $Location --sku S1 --number-of-workers 3 --per-site-scaling

Migrate to Azure App Service

One of the key questions in any environment is how best to migrate an existing on-premises app to App Service. To aid with this, Azure provides a free service called App Service Migration Assistant. (See Figure 3-46.) You can use this service to quickly scan and assess an existing web app to determine if it is suitable for migration. If the Migration Assistant service determines that the app is suitable for migration, you can use it to migrate the app to App Service. It is highly recommended that you use this free service to speed up and streamline app migrations.

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.

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.

Backup walkthrough

The following sections step you through the process of setting up backups for your web app using the Azure Portal, Azure PowerShell, and the Azure CLI.

#Set variables
$resourcegroup="AppServiceRG01"
$appname="mywebapp$(Get-Random -Minimum 100000 -Maximum 999999)"
$storageaccountname="backupsstorage"
$storagecontainer="backups"
$location="East US 2"
$backupname="BackupOnce"
# Generate an SAS token for the storage container, valid for one month.
$sastokenUrl = New-AzStorageContainerSASToken -Name $storagecontainer -Permission rwdl -Context $storageaccountname.Context -ExpiryTime (Get-Date).AddMonths(1) -FullUri
# Create a one-time backup
New-AzWebAppBackup -ResourceGroupName $resourcegroup -Name $appname -StorageAccountUrl
$sastokenUrl -BackupName $backupname

#Set variables
$resourcegroup="AppServiceRG01"
$appname="MSBPAPP01"
$storageaccountname="backupsstorage"
$storagecontainer="backups"
$location="East US 2"
# Generate an SAS token for the storage container, valid for 1 year.
$sastokenUrl = New-AzStorageContainerSASToken -Name $storagecontainer -Permission rwdl -Context $storageaccountname.Context -ExpiryTime (Get-Date).AddYears(1) -FullUri
# Schedule a backup every day, beginning in two hours, and retain for 30 days
Edit-AzWebAppBackupConfiguration -ResourceGroupName $resourcegroup -Name $appname
-StorageAccountUrl $sastokenUrl -FrequencyInterval 1 -FrequencyUnit Day
-KeepAtLeastOneBackup -StartTime (Get-Date).AddHours(2) -RetentionPeriodInDays 30

#!/bin/bash
#Set variables
resourcegroupname="AppServiceRG01"
appname=MSBP-APP01
storagename=backupsstorage
location="EastUS2"
backupcontainer="backups"
backupname="backuponce"
expirydate=$(date -I -d "$(date) + 2 months")
# Generates an SAS token for the storage container, valid for one month.
sastoken=$(az storage container generate-sas --account-name $storagename --name $backupcontainer --expiry $expirydate --permissions rwdl --output tsv)
# Construct the SAS URL for the container
sastokenurl=https://$storagename.blob.core.windows.net/$backupcontainer?$sastoken
# Create a one-time backup
az webapp config backup create --resource-group $resourcegroupname --webapp-name
$appname --backup-name $backupname --container-url $sastokenurl

#!/bin/bash
#Set variables
resourcegroupname="AppServiceRG01"
appname=MSBP-APP01
storagename=backupsstorage
location="EastUS2"
backupcontainer="appbackup"
expirydate=$(date -I -d "$(date) + 1 month")
# Generate an SAS token for the storage container, valid for one month.
sastoken=$(az storage container generate-sas --account-name $storagename --name $backupcontainer --expiry $expirydate --permissions rwdl --output tsv)
# Construct the SAS URL for the container
sastokenurl=https://$storagename.blob.core.windows.net/$backupcontainer?$sastoken
# Schedule a backup every day and retain for 10 days
az webapp config backup update --resource-group $resourcegroupname --webapp-name
$appname --container-url $sastokenurl --frequency 1d --retain-one true --retention 10