App Service Plan

The presented resiliency recommendations in this guidance include App Service Plan and associated settings.

Summary of Recommendations

Recommendations Details

ASP-1 - Migrate App Service to availability Zone Support

Category: Availability

Impact: High

Guidance

Deploying your App Service plans and App Service Environments across availability zones (AZ) is a feature provided by Azure to enhance the resiliency and reliability of your business-critical workloads. By distributing your applications across multiple availability zones, you can ensure their continued operation even in the event of a datacenter-level failure. This approach offers excellent redundancy without the need for deploying your applications in different Azure regions. Availability zones provide a higher level of fault tolerance, helping to safeguard your applications and minimize downtime. This enables your business to maintain continuity and deliver uninterrupted services to your customers.

Resources

Resource Graph Query

// Azure Resource Graph Query
// The query filters the qualified App Service Plans that do not have Zone Redundancy enabled.
// Its important to check regions that support availability zones for Azure App Services running on multi-tenant and App Service Environments https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service?tabs=graph%2Ccli#:~:text=The%20following%20regions%20support%20Azure%20App%20Services%20running%20on%20multi%2Dtenant%20environments%3A

resources
| where type =~ 'microsoft.web/serverfarms'
| extend zoneRedundant = tobool(properties.zoneRedundant)
| extend sku_tier = tostring(sku.tier)
| where (tolower(sku_tier) contains "isolated" or tolower(sku_tier) contains "premium") and zoneRedundant == false
| project recommendationid="asp-1", name, id, tags, param1=sku_tier, param2="Not Zone Redundant"



ASP-2 - Use Standard or Premium tier

Category: Availability

Impact: High

Guidance

The use of the Standard or Premium tier for Azure App Service Plan is crucial for highly resilient applications, as it provides advanced scaling, high availability, traffic management, enhanced performance, networking features, and multiple deployment slots, ensuring uninterrupted operation and robustness in the face of potential failures or increased demands.

Resources

Resource Graph Query

// Azure Resource Graph Query
// Provides a list of Azure App Service Plans that are not in the "Standard", "Premium", or "IsolatedV2" SKU tiers.

resources
| where type =~ 'microsoft.web/serverfarms'
| extend sku_tier = tostring(sku.tier)
| where tolower(sku_tier) !contains "standard" and
        tolower(sku_tier) !contains "premium" and
        tolower(sku_tier) !contains "isolatedv2"
| project recommendationid="asp-2", name, id, tags, param1= strcat("SKU=",sku_tier)



ASP-3 - Avoid scaling up or down

Category: System Efficiency

Impact: Medium

Guidance

It is recommended to avoid scaling up or down your Azure App Service instances frequently. Instead, choose an appropriate tier and instance size that can handle your typical workload, and scale out the instances to accommodate changes in traffic volume. Scaling up or down can potentially trigger an application restart, which may result in service disruptions.

Resources

Resource Graph Query

// Azure Resource Graph Query
// Provides a list of Azure App Service Plans and the number of changes that was made to the pricing tier, if the count is higher that 3 it means you need to avoid scaling up and down that often

resourcechanges
| extend changeTime = todatetime(properties.changeAttributes.timestamp), targetResourceId = tostring(properties.targetResourceId),
changeType = tostring(properties.changeType), correlationId = properties.changeAttributes.correlationId,
changedProperties = properties.changes, changeCount = properties.changeAttributes.changesCount
| where changeTime > ago(14d)
| join kind=inner (resources | project resources_Name = name, resources_Type = type, resources_Subscription= subscriptionId, resources_ResourceGroup= resourceGroup, id) on $left.targetResourceId == $right.id
| where resources_Type contains "microsoft.web/serverfarms"
| where changedProperties['sku.name'].propertyChangeType == 'Update' or changedProperties['sku.tier'].propertyChangeType == 'Update'
| summarize count() by targetResourceId, resources_Name  ,tostring(changedProperties['sku.name'].previousValue), tostring(changedProperties['sku.tier'].newValue)
| project recommendationid="asp-3", name=resources_Name, id=targetResourceId, tags="", param1=['changedProperties_sku.name_previousValue'], param2=['changedProperties_sku.tier_newValue'], param3=count_



ASP-4 - Create separate App Service plans for production and test

Category: Governance

Impact: High

Guidance

It is strongly recommended to create separate App Service plans for production and test environments. Avoid using slots within your production deployment for testing purposes. When apps within the same App Service plan share VM instances, combining production and test deployments can have adverse effects on the production environment. For instance, load tests conducted on the test deployment may degrade the live production site. By isolating test deployments in a separate plan, you ensure the separation and protection of the production version.

Resources

Resource Graph Query

// cannot-be-validated-with-arg



ASP-5 - Enable Autoscale/Automatic scaling to ensure adequate resources are available to service requests

Category: System Efficiency

Impact: Medium

Guidance

It is highly recommended to enable Autoscale/Automatic Scaling for your Azure App Service to ensure that sufficient resources are available to handle incoming requests. Autoscaling is rule based scaling while Automatic Scaling newer platform feature that performs automatic scale out and in based on HTTP traffic.

Resources

Resource Graph Query

// under-development