This article describes reliability support in Azure Functions, and covers both intra-regional resiliency with availability zones and cross-region recovery and business continuity. For a more detailed overview of reliability principles in Azure, see Azure reliability.
Availability zones support for Azure Functions depends on your Functions hosting plan:
Availability zones are physically separate groups of datacenters within each Azure region. When one zone fails, services can fail over to one of the remaining zones.
Azure Functions supports a zone-redundant deployment.
Availability zones supportImportant
Support for availability zones when hosting your app in a Flex Consumption plan is currently in preview.
When you configure Flex Consumption plan apps as zone redundant, the platform automatically spreads instances of your function app across the zones in the selected region, with different rules for always-ready versus on-demand instances.
When zone redundancy is enabled in a Flex Consumption plan, instance spreading is determined inside the following rules:
When you configure Elastic Premium function app plans as zone redundant, the platform automatically spreads the function app instances across the zones in the selected region.
Instance spreading with a zone-redundant deployment is determined inside the following rules, even as the app scales in and out:
Important
Azure Functions can run on the Azure App Service platform. In the App Service platform, plans that host Premium plan function apps are referred to as Elastic Premium plans, with SKU names like EP1. If you choose to run your function app on a Premium plan, make sure to create a plan with an SKU name that starts with E, such as EP1. App Service plan SKU names that start with P, such as P1V2 (Premium V2 Small plan), are Dedicated hosting plans. Because they're Dedicated and not Elastic Premium, plans with SKU names starting with P don't scale dynamically and can increase your costs.
Currently, not all regions support zone redundancy for Flex Consumption plans. You can use the Azure CLI to view the regions that do support it:
If you haven't done so already, install and sign in to Azure using the Azure CLI:
az login
The az login command signs you into your Azure account.
Use this az functionapp list-flexconsumption-locations command with the --zone-redundant=true option to return a list of regions that currently support zone-redundant Flex Consumption plans:
az functionapp list-flexconsumption-locations --zone-redundant=true --query "sort_by(@, &name)[].{Region:name}" -o table
When you create a Flex Consumption app in the Azure portal, the Zone redundancy section of the Basics page is enabled when your chosen region supports it.
Zone-redundant Premium plans are available in these regions:
Americas Europe Middle East Africa Asia Pacific Brazil South France Central Israel Central South Africa North Australia East Canada Central Germany West Central Qatar Central Central India Central US Italy North UAE North China North 3 East US North Europe East Asia East US 2 Norway East Japan East South Central US Sweden Central Southeast Asia West US 2 Switzerland North West US 3 UK South West Europe PrerequisitesAvailability zone support is a property of the Premium plan. Here are current considerations for availability zones:
There's no separate meter associated with enabling availability zones. Pricing for instances used for a zone-redundant Flex Consumption app is the same as a single zone Flex Consumption app. To learn more, see Billing.
When you enable availability zones in an app with always-ready instance configuration of fewer than two instances for each per-function scaling function or group, the platform automatically creates two instances of the always-ready type for each per-function scaling function or group. These new instances are also billed as always-ready instances.
There's no extra cost associated with enabling availability zones. Pricing for a zone-redundant Premium App Service plan is the same as a single zone Premium plan. For each App Service plan you use, you're charged based on the SKU you choose, the capacity you specify, and any instances you scale to based on your autoscale criteria. If you enable availability zones on a plan with fewer than two instances, the platform enforces a minimum instance count of two for that App Service plan, and you're charged for both instances.
Create a function app in a zone-redundant planThere are currently multiple ways to deploy a zone-redundant Flex Consumption app.
In the Azure portal, go to the Create Function App page. For more information about creating a function app in the portal, see Create a function app.
Select Flex Consumption and then select the Select button.
On the Create Function App (Flex Consumption) page, on the Basics tab, enter the settings for your function app. Pay special attention to the settings in the following table (also highlighted in the following screenshot), which have specific requirements for zone redundancy.
Setting Suggested value Notes for zone redundancy Region Your preferred supported region The region in which your Flex Consumption plan is created. You must select a region that supports availability zones. See the region availability list. Zone redundancy Enabled This setting specifies whether your app is zone redundant. You can only selectEnabled when you've chosen a region that supports zone redundancy.
On the Storage tab, enter the settings for your function app storage account. Pay special attention to the setting in the following table, which has specific requirements for zone redundancy.
Setting Suggested value Notes for zone redundancy Storage account A zone-redundant storage account As described in the prerequisites section, we strongly recommend using a zone-redundant storage account for your zone-redundant function app.For the rest of the function app creation process, create your function app as normal. There are no settings in the rest of the creation process that affect zone redundancy.
When creating the storage account for the function app, choose a zone redundant SKU, like Standard_ZRS. For example:
az storage account create --name <STORAGE_NAME> --location <REGION> --resource-group <RESOURCE_GROUP> --sku Standard_ZRS --allow-blob-public-access false
When creating the Flex Consumption plan, add the --zone-redundant true parameter:
az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime <RUNTIME> --runtime-version <RUNTIME_VERSION> --zone-redundant true
You can use a Bicep template to deploy to a zone-redundant Flex Consumption plan. To learn how to deploy function apps to a Flex Consumption, see Automate resource deployment in Azure Functions.
The only properties to be aware of while creating a zone-redundant hosting plan are the zoneRedundant property. The zoneRedundant property must be set to true.
Following is a Bicep template snippet for a zone-redundant, Flex Consumption plan. It shows the zoneRedundant field specification.
resource flexFuncPlan 'Microsoft.Web/serverfarms@2024-04-01' = {
name: <YOUR_PLAN_NAME>
location: <YOUR_REGION_NAME>
kind: 'functionapp'
sku: {
tier: 'FlexConsumption'
name: 'FC1'
}
properties: {
reserved: true
zoneRedundant: true
}
}
To learn more about these templates, see Automate resource deployment in Azure Functions.
You can use an ARM template to deploy to a zone-redundant Flex Consumption plan. To learn how to deploy function apps to a Flex Consumption plan, see Automate resource deployment in Azure Functions.
The only properties to be aware of while creating a zone-redundant hosting plan are the zoneRedundant property. The zoneRedundant property must be set to true.
Following is an ARM template snippet for a zone-redundant, Flex Consumption plan. It shows the zoneRedundant field specification.
"resources": [
{
"type": "Microsoft.Web/serverfarms",
"apiVersion": "2024-04-01",
"name": "<YOUR_PLAN_NAME>",
"location": "<YOUR_REGION_NAME>",
"kind": "functionapp",
"sku": {
"tier": "FlexConsumption",
"name": "FC1"
},
"properties": {
"reserved": true,
"zoneRedundant": true
}
}
]
To learn more about these templates, see Automate resource deployment in Azure Functions.
After the zone-redundant plan is created and deployed, the Flex Consumption function app hosted on your new plan is considered zone-redundant.
Update a Flex Consumption plan to be zone-redundantChanging the zone redundancy of your app requires a restart, which causes downtime in your app.
Before updating your Flex Consumption plan to be zone-redundant, you should update the default host storage account to also be zone redundant. If you use a separate storage account for the app's deployment container, you should update it to be zone redundant as well.
Use these steps to prepare your storage accounts for the change:
AzureWebJobsStorage, to reference the zone redundant storage account. See Work with application settings.After the storage accounts used by your app are updated, you can update the Flex Consumption plan to be zone-redundant using Bicep or ARM templates. The Azure portal currently doesn't support making zone redundancy updates to the plan.
Not currently supported.
Not currently supported.
You can use this Bicep file to add the zoneRedundant property to true in an existing plan definition:
resource existingServerFarm 'Microsoft.Web/serverfarms@2024-04-01' existing = {
name: '<YOUR_PLAN_NAME>'
scope: resourceGroup()
}
resource updatedServerFarm 'Microsoft.Web/serverfarms@2024-04-01' = {
name: existingServerFarm.name
location: '<YOUR_REGION_NAME>'
kind: 'functionapp'
sku: {
tier: 'FlexConsumption'
name: 'FC1'
}
properties: {
reserved: true
zoneRedundant: true // Enables zone redundancy
}
}
In this file, replace <YOUR_PLAN_NAME> and <YOUR_REGION_NAME> with the name of your plan and region, respectively. To learn how to deploy a Bicep file, see Deploy your template.
You can use this ARM template fragment to set the zoneRedundant property to true in an existing plan definition:
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"type": "Microsoft.Web/serverfarms",
"apiVersion": "2024-04-01",
"name": "<YOUR_PLAN_NAME>",
"location": "<YOUR_REGION_NAME>",
"kind": "functionapp",
"sku": {
"tier": "FlexConsumption",
"name": "FC1"
},
"properties": {
"reserved": true,
"zoneRedundant": true
}
}
]
}
In this template, replace <YOUR_PLAN_NAME> and <YOUR_REGION_NAME> with the name of your plan and region, respectively. To learn how to deploy an ARM template, see Deploy your template.
There are currently two ways to deploy a zone-redundant Premium plan and function app. You can use either the Azure portal or an ARM template.
In the Azure portal, go to the Create Function App page. For more information about creating a function app in the portal, see Create a function app.
Select Functions Premium and then select the Select button.
On the Create Function App (Functions Premium) page, on the Basics tab, enter the settings for your function app. Pay special attention to the settings in the following table (also highlighted in the following screenshot), which have specific requirements for zone redundancy.
Setting Suggested value Notes for zone redundancy Region Your preferred supported region The region in which your Elastic Premium plan is created. You must pick a region that supports availability zones. See the region availability list. Pricing plan One of the Elastic Premium plans. For more information, see Available instance SKUs. This article describes how to create a zone redundant app in a Premium plan. Zone redundancy isn't currently available in Consumption plans. For information on zone redundancy on App Service plans, see Reliability in Azure App Service. Zone redundancy Enabled This setting specifies whether your app is zone redundant. You won't be able to selectEnabled unless you have chosen a region that supports zone redundancy, as described previously.
On the Storage tab, enter the settings for your function app storage account. Pay special attention to the setting in the following table, which has specific requirements for zone redundancy.
Setting Suggested value Notes for zone redundancy Storage account A zone-redundant storage account As described in the prerequisites section, we strongly recommend using a zone-redundant storage account for your zone-redundant function app.For the rest of the function app creation process, create your function app as normal. There are no settings in the rest of the creation process that affect zone redundancy.
When creating the storage account for the function app, choose a zone redundant SKU, like Standard_ZRS. For example:
az storage account create --name <STORAGE_NAME> --location <REGION> --resource-group <RESOURCE_GROUP> --sku Standard_ZRS --allow-blob-public-access false
When creating the Premium plan, add the --zone-redundant true parameter:
az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --SKU EP1 --zone-redundant true
You can use a Bicep template to deploy to a zone-redundant Premium plan. To learn how to deploy function apps to a Premium plan, see Automate resource deployment in Azure Functions.
The only properties to be aware of while creating a zone-redundant hosting plan are the zoneRedundant property and the plan's instance count (capacity) fields. The zoneRedundant property must be set to true and the capacity property should be set based on the workload requirement, but not less than 3. Choosing the right capacity varies based on several factors and high availability / fault tolerance strategies. A good rule of thumb is to specify sufficient instances for the application to ensure that losing one zone instance leaves sufficient capacity to handle expected load.
Important
Azure Functions apps hosted on an Elastic Premium, zone-redundant plan must have a minimum always ready instance count of 3. This minimum ensures that a zone-redundant function app always has enough instances to satisfy at least one worker per zone.
Following is a Bicep template snippet for a zone-redundant, Premium plan. It shows the zoneRedundant field and the capacity specification.
resource flexFuncPlan 'Microsoft.Web/serverfarms@2021-01-15' = {
name: '<YOUR_PLAN_NAME>'
location: '<YOUR_REGION_NAME>'
sku: {
name: 'EP1'
tier: 'ElasticPremium'
size: 'EP1'
family: 'EP'
capacity: 3
}
kind: 'elastic'
properties: {
perSiteScaling: false
elasticScaleEnabled: true
maximumElasticWorkerCount: 20
isSpot: false
reserved: false
isXenon: false
hyperV: false
targetWorkerCount: 0
targetWorkerSizeId: 0
zoneRedundant: true
}
}
To learn more about these templates, see Automate resource deployment in Azure Functions.
You can use an ARM template to deploy to a zone-redundant Premium plan. To learn how to deploy function apps to a Premium plan, see Automate resource deployment in Azure Functions.
The only properties to be aware of while creating a zone-redundant hosting plan are the zoneRedundant property and the plan's instance count (capacity) fields. The zoneRedundant property must be set to true and the capacity property should be set based on the workload requirement, but not less than 3. Choosing the right capacity varies based on several factors and high availability / fault tolerance strategies. A good rule of thumb is to specify sufficient instances for the application to ensure that losing one zone instance leaves sufficient capacity to handle expected load.
Important
Azure Functions apps hosted on an Elastic Premium, zone-redundant plan must have a minimum always ready instance count of 3. This minimum ensures that a zone-redundant function app always has enough instances to satisfy at least one worker per zone.
Following is an ARM template snippet for a zone-redundant, Premium plan. It shows the zoneRedundant field and the capacity specification.
"resources": [
{
"type": "Microsoft.Web/serverfarms",
"apiVersion": "2021-01-15",
"name": "<YOUR_PLAN_NAME>",
"location": "<YOUR_REGION_NAME>",
"sku": {
"name": "EP1",
"tier": "ElasticPremium",
"size": "EP1",
"family": "EP",
"capacity": 3
},
"kind": "elastic",
"properties": {
"perSiteScaling": false,
"elasticScaleEnabled": true,
"maximumElasticWorkerCount": 20,
"isSpot": false,
"reserved": false,
"isXenon": false,
"hyperV": false,
"targetWorkerCount": 0,
"targetWorkerSizeId": 0,
"zoneRedundant": true
}
}
]
To learn more about these templates, see Automate resource deployment in Azure Functions.
After the zone-redundant plan is created and deployed, any function app hosted on your new plan is considered zone-redundant.
Availability zone migrationYou can't currently change the availability zone support of an Elastic Premium plan for an existing function app. For information on how to migrate the public multitenant Premium plan from nonavailability zone to availability zone support, see Migrate App Service to availability zone support.
Zone down experienceAll available function app instances of zone-redundant Flex Consumption plan apps are enabled and processing events. Flex Consumption apps continue to run even when other zones in the same region suffer an outage. However, it's possible that nonruntime behaviors might be impacted as a result of an outage in other availability zones. Standard function app behaviors that can affect availability include:
Zone redundancy for Flex Consumption plans only guarantees continued uptime for deployed applications that are running.
When a zone goes down, Functions detects lost instances and automatically attempts to locate or create replacement instances, as needed, in the available zones. During zonal outage, the platform tries to restore balance on the available zones remaining.
All available function app instances of zone-redundant function apps are enabled and processing events. When a zone goes down, Functions detect lost instances and automatically attempts to find new replacement instances if needed. Elastic scale behavior still applies. However, in a zone-down scenario there's no guarantee that requests for more instances can succeed, since back-filling lost instances occurs on a best-effort basis. Applications that are deployed in an availability zone enabled Premium plan continue to run even when other zones in the same region suffer an outage. However, it's possible that nonruntime behaviors could still be impacted from an outage in other availability zones. These impacted behaviors can include Premium plan scaling, application creation, application configuration, and application publishing. Zone redundancy for Premium plans only guarantees continued uptime for deployed applications.
When Functions allocates instances to a zone redundant Premium plan, it uses best effort zone balancing offered by the underlying Azure Virtual Machine Scale Sets. A Premium plan is considered balanced when each zone has either the same number of virtual machines in all of the other zones used by the Premium plan, plus-or-minus one virtual machine.
Cross-region disaster recovery and business continuityDisaster recovery (DR) refers to practices that organizations use to recover from high-impact events, such as natural disasters or failed deployments that result in downtime and data loss. Regardless of the cause, the best remedy for a disaster is a well-defined and tested DR plan and an application design that actively supports DR. Before you start creating your disaster recovery plan, see Recommendations for designing a disaster recovery strategy.
For DR, Microsoft uses the shared responsibility model. In this model, Microsoft ensures that the baseline infrastructure and platform services are available. However, many Azure services don't automatically replicate data or fall back from a failed region to cross-replicate to another enabled region. For those services, you're responsible for setting up a disaster recovery plan that works for your workload. Most services that run on Azure platform as a service (PaaS) offerings provide features and guidance to support DR. You can use service-specific features to support fast recovery to help develop your DR plan.
This section explains some of the strategies that you can use to deploy a function app to allow for disaster recovery.
For disaster recovery for Durable Functions, see Disaster recovery and geo-distribution in Azure Durable Functions.
Multi-region disaster recoveryBecause there's no built-in redundancy available, functions run in a function app in a specific Azure region. To avoid loss of execution during outages, you can redundantly deploy the same functions to function apps in multiple regions. To learn more about multi-region deployments, see the guidance in Highly available multi-region web application.
When you run the same function code in multiple regions, there are two patterns to consider, active-active and active-passive.
Active-active pattern for HTTP trigger functionsWith an active-active pattern, functions in both regions are actively running and processing events, either in a duplicate manner or in rotation. You should use an active-active pattern in combination with Azure Front Door for your critical HTTP triggered functions, which can route and round-robin HTTP requests between functions running in multiple regions. Front door can also periodically check the health of each endpoint. When a function in one region stops responding to health checks, Azure Front Door takes it out of rotation, and only forwards traffic to the remaining healthy functions.
For an example, see the sample on how to implement the geode pattern by deploying the API to geodes in distributed Azure regions..
Active-passive pattern for non-HTTPS trigger functionsIt's recommended that you use active-passive pattern for your event-driven, non-HTTP triggered functions, such as Service Bus and Event Hubs triggered functions.
To create redundancy for non-HTTP trigger functions, use an active-passive pattern. With an active-passive pattern, functions run actively in the region that's receiving events; while the same functions in a second region remain idle. The active-passive pattern provides a way for only a single function to process each message while providing a mechanism to fail over to the secondary region in a disaster. Function apps work with the failover behaviors of the partner services, such as Azure Service Bus geo-recovery and Azure Event Hubs geo-recovery.
Consider an example topology using an Azure Event Hubs trigger. In this case, the active/passive pattern requires involve the following components:
Before failover, publishers sending to the shared alias route to the primary event hub. The primary function app is listening exclusively to the primary event hub. The secondary function app is passive and idle. As soon as failover is initiated, publishers sending to the shared alias are routed to the secondary event hub. The secondary function app now becomes active and starts triggering automatically. Effective failover to a secondary region can be driven entirely from the event hub, with the functions becoming active only when the respective event hub is active.
Read more on information and considerations for failover with Service Bus and Event Hubs.
Active-active pattern for non-HTTPS trigger functionsWhile you're encouraged to use the active-passive pattern for non-HTTPS trigger functions, you can still create active-active deployments for non-HTTP triggered functions. Before you implement this pattern, you must consider how the two active regions interact or coordinate with one another.
For example, consider having the same Service Bus triggered function code deployed to two regions but triggering on the same Service Bus queue. In this case, both functions act as competing consumers on dequeueing the single queue. While each message can only be processed by one of the two app instances, it also means there's still a single point of failure, which is the single Service Bus instance.
You might instead deploy two Service Bus queues, with one in a primary region, one in a secondary region. In this case, you could have two function apps, with each pointed to the Service Bus queue active in their region. The challenge with this topology is how the queue messages are distributed between the two regions. Often, this means that each publisher attempts to publish a message to both regions, and each message is processed by both active function apps. While this creates the desired active/active pattern, it also creates other challenges around duplication of compute and when or how data is consolidated.
Next stepsRetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4