+# Enable API analysis in your API center - self-managed

+This article explains how to enable API analysis in [Azure API Center](overview.md) by manually setting up a linting engine and triggers. API analysis offers linting capabilities to analyze API definitions in your organization's API center. Linting ensures your API definitions adhere to organizational style rules, generating both individual and summary reports. Use API analysis to identify and correct common errors and inconsistencies in your API definitions.

+> [!NOTE]

+> In preview, Azure API Center can also automatically set up a linting engine and any required dependencies and triggers. [Learn more](enable-managed-api-analysis-linting.md).

+In this scenario, you analyze API definitions in your API center by using the [Spectral](https://github.com/stoplightio/spectral) open source linting engine. An Azure Functions app runs the linting engine in response to events in your API center. Spectral checks that the APIs defined in a JSON or YAML specification document conform to the rules in a customizable API style guide. An analysis report is generated that you can view in your API center.

+ :::image type="content" source="media/enable-api-analysis-linting/api-analysis-summary.png" alt-text="Screenshot of the API analysis summary in the portal." lightbox="media/enable-api-analysis-linting/api-analysis-summary.png":::

+* [Enable API analysis in your API center - Microsoft managed](enable-managed-api-analysis-linting.md)

+ Title: Managed API linting and analysis - Azure API Center

+description: Enable managed linting of API definitions in your API center to analyze compliance of APIs with the organization's API style guide.

+# Customer intent: As an API developer or API program manager, I want to analyze the API definitions in my organization's API center for compliance with my organization's API style guide.

+# Enable API analysis in your API center - Microsoft managed

+This article explains how to enable API analysis in [Azure API Center](overview.md) without having to manage it yourself (preview). API analysis offers linting capabilities to analyze API definitions in your organization's API center. Linting ensures your API definitions adhere to organizational style rules, generating both individual and summary reports. Use API analysis to identify and correct common errors and inconsistencies in your API definitions.

+> [!NOTE]

+> With managed linting and analysis, API Center sets up a linting engine and any required dependencies and triggers. You can also enable linting and analysis [manually](enable-api-analysis-linting.md).

+In this scenario:

+1. Add a linting ruleset (API style guide) in your API center using the Visual Studio Code extension for Azure API Center.

+1. Azure API Center automatically runs linting when you add or update an API definition. It's also triggered for all API definitions when you deploy a ruleset to your API center.

+1. Review API analysis reports in the Azure portal to see how your API definitions conform to the style guide.

+1. Optionally customize the ruleset for your organization's APIs. Test the custom ruleset locally before deploying it to your API center.

+## Limitations

+* Currently, only OpenAPI specification documents in JSON or YAML format are analyzed.

+* By default, you enable analysis with the [`spectral:oas` ruleset](https://docs.stoplight.io/docs/spectral/4dec24461f3af-open-api-rules). To learn more about the built-in rules, see the [Spectral GitHub repo](https://github.com/stoplightio/spectral/blob/develop/docs/reference/openapi-rules.md).

+* Currently, you configure a single ruleset, and it's applied to all OpenAPI definitions in your API center.

+## Prerequisites

+* An API center in your Azure subscription. If you haven't created one already, see [Quickstart: Create your API center](set-up-api-center.md).

+* [Visual Studio Code](https://code.visualstudio.com/)

+* The following Visual Studio Code extensions:

+ * [Azure API Center extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=apidev.azure-api-center)

+ > [!IMPORTANT]

+ > Enable managed API analysis using the API Center extension's pre-release version. When installing the extension, choose the pre-release version. Switch between release and pre-release versions any time via the extension's **Manage** button in the Extensions view.

+ * [Spectral extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=stoplight.spectral)

+

+## Enable API analysis using Visual Studio Code

+To enable API analysis using the default linting ruleset:

+1. In Visual Studio Code, open a folder that you'll use to manage rulesets for Azure API Center.

+1. Select the Azure API Center icon from the Activity Bar.

+1. In the API Center pane, expand the API center resource in which to enable API analysis.

+1. Right-click **Rules** and select **Enable API Analysis**.

+ :::image type="content" source="media/enable-managed-api-analysis-linting/enable-analysis-visual-studio-code.png" alt-text="Screenshot of enabling API linting and analysis in Visual Studio Code.":::

+A message notifies you after API analysis is successfully enabled. A folder for your API center is created in `.api-center-rules`, at the root of your working folder. The folder for your API center contains:

+

+* A `ruleset.yml` file that defines the default API style guide used by the linting engine.

+* A `functions` folder with an example custom function that you can use to extend the ruleset.

+With analysis enabled, the linting engine analyzes API definitions in your API center based on the default ruleset and generates API analysis reports.

+## View API analysis reports

+View an analysis summary and the analysis reports for your API definitions in the Azure portal. After API definitions are analyzed, the reports list errors, warnings, and information based on the configured API style guide.

+To view an analysis summary in your API center:

+1. In the portal, navigate to your API center.

+1. In the left-hand menu, under **Governance**, select **API Analysis**. The summary appears.

+ :::image type="content" source="media/enable-api-analysis-linting/api-analysis-summary.png" alt-text="Screenshot of the API analysis summary in the portal." lightbox="media/enable-api-analysis-linting/api-analysis-summary.png":::

+1. Optionally select the API Analysis Report icon for an API definition. The definition's API analysis report appears, as shown in the following screenshot.

+ :::image type="content" source="media/enable-api-analysis-linting/api-analysis-report.png" alt-text="Screenshot of an API analysis report in the portal." lightbox="media/enable-api-analysis-linting/api-analysis-report.png":::

+ > [!TIP]

+ > You can also view the API analysis report by selecting **Analysis** from the API definition's menu bar.

+## Customize ruleset

+You can customize the default ruleset or replace it as your organization's API style guide. For example, you can [extend the ruleset](https://docs.stoplight.io/docs/spectral/83527ef2dd8c0-extending-rulesets) or add [custom functions](https://docs.stoplight.io/docs/spectral/a781e290eb9f9-custom-functions).

+To customize or replace the ruleset:

+1. In Visual Studio Code, open the `.api-center-rules` folder at the root of your working folder.

+1. In the folder for the API center resource, open the `ruleset.yml` file.

+1. Modify or replace the content as needed.

+1. Save your changes to `ruleset.yml`.

+### Test ruleset locally

+Before deploying the custom ruleset to your API center, validate it locally. The Azure API Center extension for Visual Studio Code provides integrated support for API specification linting with Spectral.

+1. In Visual Studio Code, use the **Ctrl+Shift+P** keyboard shortcut to open the Command Palette.

+1. Type **Azure API Center: Set active API Style Guide** and hit **Enter**.

+1. Choose **Select Local File** and specify the `ruleset.yml` file that you customized. Hit **Enter**.

+ This step makes the custom ruleset the active API style guide for linting.

+Now, when you open an OpenAPI-based API definition file, a local linting operation is automatically triggered in Visual Studio Code. Results are displayed inline in the editor and in the **Problems** window (**View > Problems** or **Ctrl+Shift+M**).

+Review the linting results. Make any necessary adjustments to the ruleset and continue to test it locally until it performs the way you want.

+### Deploy ruleset to your API center

+To deploy the custom ruleset to your API center:

+1. In Visual Studio Code, select the Azure API Center icon from the Activity Bar.

+1. In the API Center pane, expand the API center resource in which you customized the ruleset.

+1. Right-click **Rules** and select **Deploy Rules to API Center**.

+A message notifies you after the rules are successfully deployed to your API center. The linting engine uses the updated ruleset to analyze API definitions.

+To see the results of linting with the updated ruleset, view the API analysis reports in the portal.

+## Related content

+* [Enable API analysis in your API center - self-managed](enable-api-analysis-linting.md)

+Each variant has two properties: a name and a configuration. The name is used to refer to a specific variant, and the configuration is the value of that variant. The configuration can be set using `configuration_value` property. `configuration_value` is an inline configuration that can be a string, number, boolean, or configuration object. If `configuration_value` is not specified, the returned variant's `Configuration` property will be null.

+ "configuration_value": {

+ "Size": 500

+ }

+ "configuration_value": "500px"

+* Australia SouthEast

+> - Log Analytics Agent will continue to function but not be able to connect Log Analytics workspaces.

+> - Log Analytics Agent can coexist with Azure Monitor Agent. Expect to see duplicate data if both agents are collecting the same data.

+ 

+|appName|string|\(removed)||

+|itemId|string|\(removed)||

+|appName|string|\(removed)||

+|itemId|string|\(removed)||

+|appName|string|\(removed)||

+|itemId|string|\(removed)||

+|appName|string|\(removed)||

+|itemId|string|\(removed)||

+|appName|string|\(removed)||

+|itemId|string|\(removed)||

+|valueMax|real|Max|real|

+|valueMin|real|Min|real|

+|valueSum|real|Sum|real|

+|valueStdDev|real|(removed)||

+|appName|string|\(removed)||

+|itemId|string|\(removed)||

+|appName|string|\(removed)||

+|itemId|string|\(removed)||

+|appName|string|\(removed)||

+|itemId|string|\(removed)||

+|appName|string|\(removed)||

+|itemId|string|\(removed)||

+|appName|string|\(removed)||

+|itemId|string|\(removed)||

+1. Search for and select *Azure Monitor* using the search bar at the top of the page.

+ - **Not configured**: Autoscale isn't set up yet for this resource.

+ - **Enabled**: Autoscale is enabled for this resource.

+ - **Disabled**: Autoscale is disabled for this resource.

+1. The default rule scales your resource by one instance if the `Percentage CPU` metric is greater than 70 percent.

+ Keep the default values and select **Add**.

+1. You've created your first scale-out rule. Best practice is to have at least one scale-in rule. To add another rule, select **Add a rule**.

+ You have configured a scale setting that scales out and scales in based on CPU usage, but you're still limited to a maximum of one instance. Change the instance limits to allow for more instances.

+1. Select **Repeat specific days**.

+1. Select **Specify start/end dates**

+You have now defined a scale condition for a specific day. When CPU usage is greater than 70%, an additional instance is added, up to a maximum of 10 instances to handle anticipated load. When CPU usage is below 20%, an instance is removed up to a minimum of 1 instance. By default, autoscale scales to 3 instances when this scale condition becomes active.

+### Predictive autoscale

+Predictive autoscale uses machine learning to help manage and scale Azure Virtual Machine Scale Sets with cyclical workload patterns. It forecasts the overall CPU load to your virtual machine scale set, based on your historical CPU usage patterns. It predicts the overall CPU load by observing and learning from historical usage. This process ensures that scale-out occurs in time to meet the demand. For more information, see [Predictive autoscale](autoscale-predictive.md).

+### Scale-in policy

+When scaling a Virtual machine Scale Set, the scale-in policy determines which virtual machines are selected for removal when a scale-in event occurs. The scale-in policy can be set to either **Default**, **NewestVM**, or **OldestVM**. For more information, see [Use custom scale-in policies with Azure Virtual Machine Scale Sets](/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-scale-in-policy?WT.mc_id=Portal-Microsoft_Azure_Monitoring).

+### Notify

+You can configure notifications to be sent when a scale event occurs. Notifications can be sent to an email address or to a webhook. For more information, see [Autoscale notifications](autoscale-webhook-email.md).

+Flapping refers to a loop condition that causes a series of opposing scale events. Flapping happens when one scale event triggers an opposite scale event. For example, scaling in reduces the number of instances causing the CPU to rise in the remaining instances. This in turn triggers a scale-out event, which causes CPU usage to drop, repeating the process. For more information, see [Flapping in Autoscale](autoscale-flapping.md) and [Troubleshooting autoscale](autoscale-troubleshoot.md)

+Use [REST API](/rest/api/monitor/autoscalesettings/createorupdate) to create an autoscale setting in the new environment. The autoscale setting created in the destination region is a copy of the autoscale setting in the source region.

+- [Use autoscale actions to send email and webhook alert notifications in Azure Monitor ](autoscale-webhook-email.md)

+> [!NOTE]

+> Azure Monitor Agent (AMA) collects monitoring data from the guest operating system of Azure and hybrid virtual machines and delivers it to Azure Monitor for use by features, insights, and other services such as [Microsoft Sentinel](../../sentintel/../sentinel/overview.md) and [Microsoft Defender for Cloud](/azure/defender-for-cloud/defender-for-cloud-introduction).

+>

+>We recommend using the Azure Monitor Agent to collet logs and metrics from Virtual Machines. For more information, see [Azure Monitor Agent overview](../agents/azure-monitor-agent-overview.md).

+> [!NOTE]

+> Azure Monitor Agent (AMA) collects monitoring data from the guest operating system of Azure and hybrid virtual machines and Virtual Machine Scale Sets and delivers it to Azure Monitor for use by features, insights, and other services such as [Microsoft Sentinel](../../sentintel/../sentinel/overview.md) and [Microsoft Defender for Cloud](/azure/defender-for-cloud/defender-for-cloud-introduction).

+>

+>We recommend using the Azure Monitor Agent to collet logs and metrics from Virtual Machine Scale Sets. For more information, see [Azure Monitor Agent overview](../agents/azure-monitor-agent-overview.md).

+View your application's availability by region to identify which geographic locations are having problems. This chart shows the Application Insights availability metric. The chart shows that the monitored application has no problem with availability from the East US data center, but it's experiencing a partial availability problem from West US, and East Asia.

+1. Turn on [Application Insights availability](/previous-versions/azure/azure-monitor/app/monitor-web-app-availability) monitoring for your website.

+Your storage account resource is experiencing an excess volume of failed transactions. Use the transactions metric to identify which API is responsible for the excess failure. Notice that the following chart is configured with the same dimension (API name) in splitting and filtered by failed response type:

+1. In the scope dropdown, select your Storage Account

+ azuread:

+ cloud: 'AzurePublic'

+ managed_identity:

+ client_id: "<client-id of the managed identity>"

+ oauth:

+ client_id: "<client-id from the Entra app>"

+ client_secret: "<client secret from the Entra app>"

+ tenant_id: "<Azure subscription tenant Id>"

+To create a diagnostic setting for an Azure resource, add a resource of type `<resource namespace>/providers/diagnosticSettings` to the template. This article provides examples for some resource types, but the same pattern can be applied to other resource types. The collection of allowed logs and metrics varies for each resource type.

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/MyResourceGroup/providers/microsoft.operationalinsights/workspaces/MyWorkspace"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.EventHub/namespaces/MyNameSpace/authorizationrules/RootManageSharedAccessKey"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/MyResourceGroup/providers/microsoft.operationalinsights/workspaces/MyWorkspace"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.EventHub/namespaces/MyNameSpace/authorizationrules/RootManageSharedAccessKey"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/MyResourceGroup/providers/microsoft.operationalinsights/workspaces/MyWorkspace"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.EventHub/namespaces/MyNameSpace/authorizationrules/RootManageSharedAccessKey"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/MyResourceGroup/providers/microsoft.operationalinsights/workspaces/MyWorkspace"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.EventHub/namespaces/MyNameSpace/authorizationrules/RootManageSharedAccessKey"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/MyResourceGroup/providers/microsoft.operationalinsights/workspaces/MyWorkspace"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.EventHub/namespaces/MyNameSpace/authorizationrules/RootManageSharedAccessKey"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/MyResourceGroup/providers/microsoft.operationalinsights/workspaces/MyWorkspace"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.EventHub/namespaces/MyNameSpace/authorizationrules/RootManageSharedAccessKey"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/MyResourceGroup/providers/microsoft.operationalinsights/workspaces/MyWorkspace"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.EventHub/namespaces/MyNameSpace/authorizationrules/RootManageSharedAccessKey"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/MyResourceGroup/providers/microsoft.operationalinsights/workspaces/MyWorkspace"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.EventHub/namespaces/MyNameSpace/authorizationrules/RootManageSharedAccessKey"

+ "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/MyResourceGroup/providers/microsoft.operationalinsights/workspaces/MyWorkspace"

+1. Follow [Screenshot of the the Certification Authority.](/windows-server/networking/core-network-guide/cncg/server-certs/install-the-certification-authority) to install and configure AD DS Certificate Authority.

+2. Follow [Screenshot of the view certificates with the MMC snap-in.](/dotnet/framework/wcf/feature-details/how-to-view-certificates-with-the-mmc-snap-in) to use the MMC snap-in and the Certificate Manager tool.

+ Root CA certificates can be exported from the Personal or Trusted Root Certification Authorities directory. The following image shows the Personal Root Certification Authority directory:

+ .

+ 

+ * In cross-region or cross-zone replication configuration, you can enable cool access exclusively for destination volumes to enhance data protection and create cost savings without affecting latency in source volumes.

+## Documenting chaos experiments

+There are several methods for documenting chaos engineering. One approach is to use work items in Azure DevOps Boards or in GitHub Projects. By creating dedicated work items for each experiment, you can track the details, progress, and outcomes of your experiments in a structured manner. This documentation can include information such as the purpose of the experiment, the expected outcomes, the steps followed, the resources involved, and any observations or learnings from the experiment.

+| Aspect | Details | Description |

+|-|-|--|

+| Hypothesis | Define the objective and expected outcomes of the experiment | |

+| Attack Layer | Identify which part of the system will be subjected to chaos experiments (e.g., network, database, application layer). | |

+| Duration | Specify the time frame for the chaos experiment. | |

+| Target | Determine the specific targets or components within the system. | |

+| Environment | Define whether the experiment will be conducted in a production, staging, or development environment. | |

+| Observations | Record any data or behavior observed during the experiment. | |

+| Results | Summarize the findings and outcomes of the experiment. | |

+| Action Items | List any action items or steps to be taken based on the results. | |

+| | | |

+The hypothesis is a crucial aspect of a chaos experiment as it defines the objective and expected outcomes of the experiment. It helps in testing the system's ability to handle unexpected disruptions effectively. By formulating a clear hypothesis, you can focus your experiment on specific areas of the system and gather meaningful data to evaluate its resilience.

+By leveraging the features of Azure DevOps Boards or GitHub Projects, you can collaborate with your team, assign tasks, set due dates, and track the overall progress of your chaos engineering initiatives. This documentation serves as a reference for future analysis, sharing knowledge, and improving the resilience of your systems.

+| **Consumption** | Multitenant Azure Logic Apps | Managed connector, which appears in the connector gallery under **Runtime** > **Shared**. <br><br>**Note**: Service Bus managed connector triggers follow the [*long polling trigger* pattern](#service-bus-managed-triggers), which means that the trigger periodically checks for messages in the queue or topic subscription. For more information, review the following documentation: <br><br>- [Service Bus managed connector reference](/connectors/servicebus/) <br>- [Managed connectors in Azure Logic Apps](managed.md) |

+| **Standard** | Single-tenant Azure Logic Apps and App Service Environment v3 (Windows plans only) | Managed connector (Azure-hosted), which appears in the connector gallery under **Runtime** > **Shared**, and built-in connector, which appears in the connector gallery under **Runtime** > **In App** and is [service provider based](../logic-apps/custom-connector-overview.md#service-provider-interface-implementation). <br><br>The Service Bus managed connector triggers follow the [*long polling trigger* pattern](#service-bus-managed-triggers), which means that the trigger periodically checks for messages in the queue or topic subscription. <br><br>The Service Bus built-in connector triggers follow the [*push trigger* pattern](introduction.md#triggers) and usually provides better performance, capabilities, pricing, and so on. <br><br>For more information, review the following documentation: <br><br>- [Service Bus managed connector reference](/connectors/servicebus/) <br>- [Service Bus built-in connector operations](/azure/logic-apps/connectors/built-in/reference/servicebus) <br>- [Built-in connectors in Azure Logic Apps](built-in.md) |

+<a name="service-bus-managed-triggers"></a>

+For the Service Bus built-in connector, all triggers follow the [*push trigger* pattern](introduction.md#triggers). Currently, configuration settings for the Service Bus built-in trigger are shared between the [Azure Functions host extension](../azure-functions/functions-bindings-service-bus.md#hostjson-settings), which is defined in your logic app's [**host.json** file](../logic-apps/edit-app-settings-host-settings.md), and the trigger settings defined in your logic app's workflow, which you can set up either through the designer or code view. This section covers both settings locations.

+By default, the Service Bus built-in connector is a stateless connector. To run this connector's operations in stateful mode, see [Enable stateful mode for stateless built-in connectors](enable-stateful-affinity-built-in-connectors.md). Also, Service Bus built-in triggers follow the [*push trigger* pattern](introduction.md#triggers).

+Service Bus managed triggers follow the [*long polling trigger* pattern](#service-bus-managed-triggers).

+* [What are connectors in Azure Logic Apps](introduction.md)

+## Reactivation process time

+It can take up to 24 hours for your subscription to get reactivated after you pay your balance.

+Data Box Disk self-encrypting drives are generally available in the US, EU, and Japan.

+|2| 450-AKMP | Dual, Hot-Plug, Redundant Power Supply (1+1), 600W MM **for US**<br> Dual, Hot-Plug, Redundant Power Supply (1+1), 700W MM HLAC (Only for 200-240Vac) titanium **for Europe** |

+$AdvFilter1=@{operatorType="StringIn"; key="Data.color"; values=@('blue', 'red', 'green')}

+In this example, we are making a change to an Azure Firewall using classic rules. We must first get context to our previously created Azure Firewall instance.

+| X-Azure-FDID | `X-Azure-FDID: a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1` <br/> A reference string that identifies the request came from a specific Front Door resource. The value can be seen in the Azure portal or retrieved using the management API. You can use this header in combination with IP ACLs to lock down your endpoint to only accept requests from a specific Front Door resource. See the FAQ for [more detail](front-door-faq.yml#what-are-the-steps-to-restrict-the-access-to-my-backend-to-only-azure-front-door-) |

+|[System updates should be installed on your machines (powered by Update Center)](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff85bf3e0-d513-442e-89c3-1784ad63382b) |Your machines are missing system, security, and critical updates. Software updates often include critical patches to security holes. Such holes are frequently exploited in malware attacks so it's vital to keep your software updated. To install all outstanding patches and secure your machines, follow the remediation steps. |AuditIfNotExists, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Security%20Center/ASC_MissingSystemUpdatesV2_Audit.json) |

+|[System updates should be installed on your machines (powered by Update Center)](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff85bf3e0-d513-442e-89c3-1784ad63382b) |Your machines are missing system, security, and critical updates. Software updates often include critical patches to security holes. Such holes are frequently exploited in malware attacks so it's vital to keep your software updated. To install all outstanding patches and secure your machines, follow the remediation steps. |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Security%20Center/ASC_MissingSystemUpdatesV2_Audit.json) |

+|[Set file integrity rules in your organization](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F9e1a2a94-cf7e-47de-b28e-d445ecc63902) |CMA_M1000 - Set file integrity rules in your organization |Manual, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Regulatory%20Compliance/CMA_M1000.json) |

+|[Set file integrity rules in your organization](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F9e1a2a94-cf7e-47de-b28e-d445ecc63902) |CMA_M1000 - Set file integrity rules in your organization |Manual, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Regulatory%20Compliance/CMA_M1000.json) |

+|[Configure Azure Kubernetes Service clusters to enable Defender profile](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F64def556-fbad-4622-930e-72d1d5589bf5) |Microsoft Defender for Containers provides cloud-native Kubernetes security capabilities including environment hardening, workload protection, and run-time protection. When you enable the SecurityProfile.Defender on your Azure Kubernetes Service cluster, an agent is deployed to your cluster to collect security event data. Learn more about Microsoft Defender for Containers: [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-introduction?tabs=defender-for-container-arch-aks](/azure/defender-for-cloud/defender-for-containers-introduction). |DeployIfNotExists, Disabled |[4.3.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_AKS_SecurityProfile_DINE.json) |

+Authenticating access by using Microsoft Entra ID and controlling permissions by using Azure RBAC provides improved security and ease of use over security tokens. To minimize potential security issues inherent in security tokens, we recommend that you [enforce Microsoft Entra authentication](#enforce-azure-ad-authentication) whenever possible.

+*Authentication* is the process of proving that you are who you say you are. Authentication verifies the identity of a user or device to IoT Hub. It's sometimes shortened to *AuthN*.

+*Authorization* is the process of confirming permissions for an authenticated user or device on IoT Hub. It specifies what resources and commands you're allowed to access, and what you can do with those resources and commands. Authorization is sometimes shortened to *AuthZ*.

+When a Microsoft Entra security principal requests access to an IoT Hub service API, the principal's identity is first *authenticated*. For authentication, the request needs to contain an OAuth 2.0 access token at runtime. The resource name for requesting the token is `https://iothubs.azure.net`. If the application runs in an Azure resource like an Azure VM, Azure Functions app, or Azure App Service app, it can be represented as a [managed identity](/entra/identity/managed-identities-azure-resources/how-managed-identities-work-vm).

+With Microsoft Entra ID and RBAC, IoT Hub requires that the principal requesting the API have the appropriate level of permission for authorization. To give the principal the permission, give it a role assignment.

+- If the principal is a managed identity, follow the guidance in [Assign a managed identity access to a resource](/entra/identity/managed-identities-azure-resources/how-to-assign-access-azure-resource).

+| Role | Description |

+| - | -- |

+- **The IoT hub.** At this scope, a role assignment applies to the IoT hub. There's no scope smaller than an individual IoT hub. Role assignment at smaller scopes, like individual device identity, isn't supported.

+| `Microsoft.Devices/IotHubs/devices/write` | Create or update any device or module identity. |

+| `Microsoft.Devices/IotHubs/cloudToDeviceMessages/send/action` | Send a cloud-to-device message to any device. |

+| `Microsoft.Devices/IotHubs/cloudToDeviceMessages/queue/purge/action` | Delete all the pending commands for a device. |

+>

+> To get data from IoT Hub by using Microsoft Entra ID, [set up routing to a custom Event Hubs endpoint](iot-hub-devguide-messages-d2c.md). To access the [the built-in Event Hubs compatible endpoint](iot-hub-devguide-messages-read-builtin.md), use the connection string (shared access key) method as before.

+By default, IoT Hub supports service API access through both Microsoft Entra ID and [shared access policies and security tokens](authenticate-authorize-sas.md). To minimize potential security vulnerabilities inherent in security tokens, you can disable access with shared access policies.

+> [!WARNING]

+>

+> By denying connections using shared access policies, all users and services that connect using this method lose access immediately. Notably, since Device Provisioning Service (DPS) only supports linking IoT hubs using shared access policies, all device provisioning flows will fail with "unauthorized" error. Proceed carefully and plan to replace access with Microsoft Entra role based access.

+>

+> **Do not proceed if you use Device Provisioning Service**.

+1. Select **Save**.

+- For more information on the advantages of using Microsoft Entra ID in your application, see [Integrating with the Microsoft identity platform](/entra/identity-platform/how-to-integrate).

+- To learn how access tokens, refresh tokens, and ID tokens are used in authorization and authentication, see [Security tokens](/entra/identity-platform/security-tokens).

+Managed identities provide Azure services with an automatically managed identity in Microsoft Entra ID in a secure manner. This eliminates the need for developers having to manage credentials by providing an identity. There are two types of managed identities: system-assigned and user-assigned. IoT Hub supports both.

+In IoT Hub, managed identities can be used to connect IoT Hub to other Azure services for features such as [message routing](iot-hub-devguide-messages-d2c.md), [file upload](iot-hub-devguide-file-upload.md), and [bulk device import/export](iot-hub-bulk-identity-mgmt.md). In this article, you learn how to use system-assigned and user-assigned managed identities in your IoT hub for different functionalities.

+- Understand the differences between *system-assigned* and *user-assigned* managed identity in [What are managed identities for Azure resources?](/entra/identity/managed-identities-azure-resources/overview)

+### [Azure portal](#tab/portal)

+You can enable or disable system-assigned managed identity in Azure portal

+### [Azure Resource Manager](#tab/arm)

+You can enable system-assigned managed identity at hub creation time using ARM template

+You can retrieve the system-assigned managed identity assigned to your hub using the Azure CLI:

+### [Azure portal](#tab/portal)

+1. First you need to create a user-assigned managed identity as a standalone resource. To do so, you can follow the instructions in [Manage user-assigned managed identities](/entra/identity/managed-identities-azure-resources/how-manage-user-assigned-managed-identities).

+3. Under **User-Assigned** tab, click **Associate a user-assigned managed identity**. Choose the user-assigned managed identity you want to add to your hub and then click **Select**.

+4. You can remove a user-assigned identity from an IoT hub. Choose the user-assigned identity you want to remove, and click **Remove** button. Note you are only removing it from IoT hub, and this removal does not delete the user-assigned identity as a resource. To delete the user-assigned identity as a resource, follow the instructions in [Manage user-assigned managed identities](/entra/identity/managed-identities-azure-resources/how-manage-user-assigned-managed-identities).

+ :::image type="content" source="./media/iot-hub-managed-identity/user-assigned.png" alt-text="Screenshot showing how to add user-assigned managed identity for an IoT hub." lightbox="./media/iot-hub-managed-identity/user-assigned.png":::

+### [Azure Resource Manager](#tab/arm)

+Managed identities can be used for egress connectivity from IoT Hub to other Azure services. You can choose which managed identity to use for each IoT Hub egress connectivity to customer-owned endpoints including storage accounts, event hubs, and service bus endpoints.

+ For more information about role assignments, see [Assign Azure roles using the Azure portal](../role-based-access-control/role-assignments-portal.yml).

+ For more information about role assignments, see [Assign Azure roles using the Azure portal](../role-based-access-control/role-assignments-portal.yml).

+1. On your IoT hub's resource page, navigate to **File upload** tab.

+1. On the page that shows up, select the container that you intend to use in your blob storage, configure the **File notification settings, SAS TTL, Default TTL, and Maximum delivery count** as desired. Choose the preferred authentication type, and click **Save**. If you get an error at this step, temporarily set your storage account to allow access from **All networks**, then try again. You can configure firewall on the storage account once the File upload configuration is complete.

+IoT Hub supports the functionality to [import/export device information in bulk](iot-hub-bulk-identity-mgmt.md) from or to a customer-provided storage blob. This functionality requires connectivity from IoT Hub to the storage account.

+>

+- [Message routing](./iot-hub-devguide-messages-d2c.md)

+- [File upload](./iot-hub-devguide-file-upload.md)

+- [Bulk device import/export](./iot-hub-bulk-identity-mgmt.md)

+There are various Microsoft solutions that you might consider as a direct replacement for Azure Lab Services. Each of these Microsoft solutions offers browser-based web access. While these solutions aren't necessarily education-specific, they support a wide range of education and training scenarios.

+[Azure Virtual Desktop](https://azure.microsoft.com/products/virtual-desktop/) is a comprehensive desktop and app virtualization service running in the cloud, offering secure, and scalable virtual desktop experiences with usage-based pricing. It's ideal for providing full desktop and app delivery scenarios for Windows 10/11 with maximum control to any device from a flexible cloud virtual desktop infrastructure (VDI) platform on your Azure infrastructure and by using Microsoft Entra ID for user identities. Azure Virtual Desktop supports CPU/GPU-based Microsoft Entra ID joined virtual machines, content filtering, image management from Azure Marketplace or Azure compute gallery, centralized end-to-end management with Intune, and multi-session capabilities.

+[Azure DevTest Labs](https://azure.microsoft.com/products/devtest-lab/) simplifies creation, usage, and management of infrastructure-as-a-service (IaaS) virtual machines within a lab context with usage-based pricing. It's ideal for computer programming related courses and those users familiar with the Azure portal. Azure DevTest Labs supports Linux and Windows CPU/GPU-based virtual machines, student admin access, network isolated labs, nested virtualization, and image management from Azure Marketplace or Azure compute gallery.

+For more guidance on transitioning from Azure Lab Services to Azure DevTest Labs, see the [Azure Lab Services to Azure DevTest Labs Transition Guide](/azure/lab-services/transition-devtest-labs-guidance).

+[Microsoft Dev Box](https://azure.microsoft.com/products/dev-box/) offers cloud-based workstations preconfigured with tools and environments for developer workflow-specific tasks with usage-based pricing. It's ideal for facilitating hands-on learning where training leaders can use Dev Box supported images to create identical virtual machines for trainees. Dev Box virtual machines are Microsoft Entra ID joined and support centralized end-to-end management with Microsoft Intune.

+After June 28, 2027, Azure Lab Services won't be supported, and you won't have access to your lab accounts, lab plans, or labs. You will, however, have access to your Azure compute gallery and any images you might have saved there.

+If you have questions about how to transition to one of the partner's solutions, refer to the following resources for each partner (listed alphabetically).

+Partners might provide migration tooling to automatically migrate labs from Azure Lab Services. However, early customer pilots show that it's often more efficient to recreate new labs using the optimizations offered by Microsoft and partner solutions, such as multi-session, dynamic virtual machine creation, and changing the storage type to a lower tier when a virtual machine is shut down. In certain situations, reusing custom images exported from your labs to an Azure compute gallery might be beneficial. Microsoft and partner solutions all support the use of or migration of images from your Azure compute gallery. We recommend evaluating whether existing lab images should be recreated when you're:

+## Related content

+- [Azure Lab Services to Azure DevTest Labs Transition Guide](/azure/lab-services/transition-devtest-labs-guidance)

+ Title: Transition from Azure Lab Services to Azure DevTest Labs

+description: Learn how to transition from Azure Lab Services to Azure DevTest Labs.

+# customer intent: As an Azure Lab Services customer, I want to understand the Azure Lab Services retirement schedule and what Microsoft and partners services I can transition to.

+# Azure Lab Services to Azure DevTest Labs Transition Guide

+When you transition away from Azure Lab Services, DevTest Labs (DTL) is a first party option that can be considered. This document outlines when to and not to consider transitioning to use DevTest Labs. An outline of steps to follow is also included.

+## Scenario guidance

+### What are the target scenarios for DevTest Labs?

+DevTest Labs is targeted at enterprise customers. The primary scenario for which DevTest Labs is designed is the test box scenario, where a professional developer needs temporary access to a virtual machine (VM) that has a prereleased version of the software they need to test. A secondary scenario is professional developer training, when a developer needs temporary access to a VM for internal training.

+### When should a customer consider using DevTest Labs?

+- Customer needs access to Linux VMs - DevTest Labs is the only first party service that provides access to Linux. Cloud PC, Azure Virtual Desktop, Microsoft Dev Box don't provide access to native Linux VMs.

+- Customer needs to use an image with nested virtualization - DevTest Labs works well with images that use nested virtualization because it provides a dedicated VM for each student. Nested virtualization isn't well-suited for multi-user session VMs because there's no concept of isolation between user sessions.

+- Technical Computer Programming classes - DevTest Labs resources are available using the Azure portal. Only students comfortable with the Azure portal should use DTL. DTL APIs can be used if you want to create a custom portal to access DTL VMs outside of the Azure portal.

+### When should a customer not use DevTest Labs?

+- Customer requires extensive cost controls, including user quota and limits on the number of VMs a user can have. DevTest Labs doesn't have any ability to restrict access to a VM based on a quota granted per student.

+- Customer requires complex start and stop schedules. DevTest Labs is designed for enterprise developers; it supports daily start and stop schedules.

+- Customer requires flexible login methods. DevTest Labs requires that the user exists in the Microsoft Entra ID tenant for the subscription in which the lab is hosted. RBAC permissions are used to control who has access to labs and VMs.

+## Frequently Asked Questions

+**What is the cost model?**

+There are no costs for using the service; it's free to use. Customers are charged for resources used by the DevTest Labs service. This cost includes, but isn't limited to, the cost of storage, networking, and running time for any VMs in a lab.

+**Does DevTest Labs provide cost reporting?**

+DevTest Labs is integrated into [Microsoft Cost Management](/azure/cost-management-billing/costs/overview-cost-management) for cost budgeting and analysis. [Allow tag inheritance and add tags to lab resource](/azure/devtest-labs/devtest-lab-configure-cost-management) to track per-lab costs.

+**Does DevTest Labs support nested virtualization?**

+Yes.

+

+**Does DevTest Labs support custom images?**

+Yes. We recommend [connecting your DevTest Labs to a Shared Image Gallery](/azure/devtest-labs/configure-shared-image-gallery). The Shared Image Gallery can be the same one that is connected to your Azure Lab Services lab account or lab plan.

+

+We recommend using a Shared Image Gallery over the DTL [custom images feature](/azure/devtest-labs/devtest-lab-create-custom-image-from-vm-using-portal) and [formulas](/azure/devtest-labs/devtest-lab-manage-formulas) features as Shared Image Galleries are compatible with several other Azure services and can be used in multiple labs.

+**Does DevTest Labs support multi-VM environments?**

+[Azure Deployment Environments](https://azure.microsoft.com/products/deployment-environments/) is recommended for multi-VM environments.

+**Does DevTest Labs support schedules?**

+DevTest Labs supports an optional daily start and/or stop schedule.

+**Does DevTest Labs support web access?**

+Yes, if the VM is created in a Bastion-enabled virtual network. See [Enable browser connection to DevTest Labs VMs with Azure Bastion](/azure/devtest-labs/enable-browser-connection-lab-virtual-machines) for details.

+## Transition steps

+1. **Verify [compute quota limits](/azure/quotas/view-quotas)** - DevTest Labs uses quota assigned to Compute when creating VMs. Increase [compute quota](/azure/quotas/regional-quota-requests), if needed.

+1. **Configure Lab settings**

+ 1. **Images**

+ 1. [Restrict Marketplace images](/azure/devtest-labs/devtest-lab-enable-licensed-images) students can use. You can prevent students from using Marketplace images in totality.

+ 1. Enable custom images as applicable by [connecting your DevTest Labs to a Shared Image Gallery](/azure/devtest-labs/configure-shared-image-gallery). The gallery can be the same gallery you used with Azure Lab Services.

+ 1. DTL also supports creating VMs from [uploaded VHD](/azure/devtest-labs/devtest-lab-upload-vhd-using-storage-explorer) files.

+ 1. **SKU selection** - Consider enabling VM sizes equivalent to Azure Labs SKUs. See [Azure Lab Services VM Sizes](/azure/lab-services/administrator-guide#default-vm-sizes) for mappings to make sure to choose sizes that supported the [*shared ip* configuration option](/azure/devtest-labs/devtest-lab-shared-ip).

+ 1. **VM Limitations** - Set [max number of VMs per user to 1](/azure/devtest-labs/devtest-lab-set-lab-policy#set-virtual-machines-per-user).

+ 1. **Shutdown policies**

+ 1. Set [autoshutdown time](/azure/devtest-labs/devtest-lab-set-lab-policy#set-auto-shutdown) to ensure VMs are automatically turned off every day.

+ 1. Set [autoshutdown policy](/azure/devtest-labs/devtest-lab-set-lab-policy#set-auto-shutdown-policy) to 'User has no control over the schedule set by lab administrator.' If students are in multiple time zones, choose 'User sets a schedule and can't opt out' instead.

+ 1. [Turn off autostart](/azure/devtest-labs/devtest-lab-set-lab-policy#set-autostart) for the lab.

+ 1. **Virtual Network**. If your lab needs access to a license server, [add a virtual network in Azure DevTest Labs](/azure/devtest-labs/devtest-lab-configure-vnet).

+ 1. **Web browser access** - Optionally, enable [browser connection to DevTest Labs VMs with Azure Bastion](/azure/devtest-labs/enable-browser-connection-lab-virtual-machines).

+1. **Create lab** - [Quickstart: Create a lab in the Azure portal - Azure DevTest Labs](/azure/devtest-labs/devtest-lab-create-lab).

+1. **Cost Tracking** - Use custom tags for cost tracking in Microsoft Cost Management as it allows more nuanced cost analysis of underlying resources. [Allow tag inheritance and add tags to lab resource](/azure/devtest-labs/devtest-lab-configure-cost-management).

+1. **Claimable VMs** - Optionally, precreate claimable VMs to ensure VMs are created with expected settings.

+ 1. Using advanced settings, multiple identical VMs can be created at once.

+ 1. Using advanced settings, set the expiration date for [claimable VMs](/azure/devtest-labs/devtest-lab-use-claim-capabilities). VMs will automatically be deleted after their expiration date and avoid unnecessary storage charges.

+1. **Add Users** - [Add lab owners, contributors, and users in Azure DevTest Labs](/azure/devtest-labs/devtest-lab-add-devtest-user).

+ - If there are claimable VMs, students can use the 'claim any' command to assign a precreated VM to themselves.

+1. **Configure Dashboard** - Optionally, [create a dashboard in the Azure portal](/azure/azure-portal/azure-portal-dashboards) to allow students to find their labs more easily.

+> [!Important]

+> If using a Linux VM that only supports access using SSH, follow detailed instructions at [Connect to a Linux VM in your lab (Azure DevTest Labs)](/azure/devtest-labs/connect-linux-virtual-machine).

+## Related content

+- [Azure Lab Services Retirement Guide](/azure/lab-services/retirement-guide)

+With Gateway Load Balancer, you can easily add or remove advanced network functionality without extra management overhead. It provides the bump-in-the-wire technology you need to ensure all traffic to and from a public endpoint is first sent to the appliance before your application. In scenarios with NVAs, it's especially important that flows are symmetrical. Gateway Load Balancer maintains flow stickiness to a specific instance in the backend pool along with flow symmetry. As a result, a consistent route to your network virtual appliance is ensured ΓÇô without further manual configuration. As a result, packets traverse the same network path in both directions and appliances that need this key capability are able to function seamlessly.

+* Chain applications across tenants and subscriptions

+## Configuration and supported scenarios

+A Standard Public Load balancer or a Standard IP configuration of a virtual machine can be chained to a Gateway Load Balancer. "Chaining" refers to the load balancer frontend or NIC IP configuration containing a reference to a Gateway Load Balancer frontend IP configuration. Once the Gateway Load Balancer is chained to a consumer resource, no additional configuration such as UDRs are needed to ensure traffic to and from the application endpoint is sent to the Gateway Load Balancer.

+Gateway Load Balancer supports both inbound and outbound traffic inspection. For inserting NVAs in the path of outbound traffic with Standard Load Balancer, Gateway Load Balancer must be chained to the frontend IP configurations selected in the configured outbound rules.

+## Data path diagram

+With Gateway Load Balancer, traffic intended for the consumer application through a Standard Load Balancer will be encapsulated with VXLAN headers and forwarded first to the Gateway Load Balancer and its configured NVAs in the backend pool. The traffic then returns to the consumer resource (in this case a Standard Load Balancer) and arrives at the consumer application virtual machines with its source IP preserved. The consumer virtual network and provider virtual network can be in different subscriptions or tenants, reducing management overhead.

+- Learn how to use [Gateway Load Balancer for outbound connectivity scenarios](tutorial-gateway-outbound-connectivity.md).

+The interval value determines how frequently the health probe checks for a response from your backend pool instances. If the health probe fails, your backend pool instances are immediately marked as unhealthy. If the health probe succeeds on the next healthy probe up, Azure Load Balancer marks your backend pool instances as healthy. The health probe attempts to check the configured health probe port every 5 seconds by default in the Azure portal, but can be explicitly set to another value.

+For HTTP/S probes, if the configured interval is longer than the above timeout period, the health probe will timeout and fail if no response is received during the timeout period. For example, if an HTTP health probe is configured with a probe interval of 120 seconds (every 2 minutes), and no probe response is received within the first 30 seconds, the probe will have reached its timeout period and fail. When the configured interval is shorter than the above timeout period, the health probe will fail if no response is received before the configured interval period completes and the next probe will be sent immediately.

+ Get-AzLoadBalancer -ResourceGroupName <loadBalancerResourceGroupName> -Name <LoadBalancerName> | Start-AzNATPoolMigration

+| CentOS Stream | Y | Y | Y |

+- CentOS Stream (Azure Linux VM agent is also installed automatically during migration)

+[Azure Static Web Apps](./relocation-static-web-apps.md) | ✅ |❌ | ❌ |

+ Title: Relocate Azure Static Web Apps to another region

+description: Learn how to relocate Azure Static Web Apps to another region

+ - subject-relocation

+#Customer intent: As an Azure service administrator, I want to move my Azure Static Web Apps resources to another Azure region.

+# Relocate Azure Static Web Apps to another region

+This article describes how to relocate [Azure Static Web Apps](../static-web-apps/overview.md) resources to another Azure region.

+## Prerequisites

+Review the following prerequisites before you prepare for the relocation.

+- [Validate that Azure Static Web Apps is available in the target region](https://azure.microsoft.com/explore/global-infrastructure/products-by-region/).

+- Make sure that you have permission to create Static Web App resources in the target region.

+- Find out if there any Azure Policy region restrictions applied to your organization.

+- If using integrated API support provided by Azure Functions:

+ - Determine the availability of Azure Functions in the target region.

+ - Determine if Function API Keys are being used. For example, are you using Key Vault or do you deploy them as part of your application configuration files?

+ - Determine the deployment model for API support in the target region: [Distributed managed functions](../static-web-apps/distributed-functions.md) or [Bring Your own functions](../static-web-apps/functions-bring-your-own.md). Understand the differences between the two models.

+- Ensure that the Standard Hosting Plan is used to host the Static Web App. For more information about hosting plans, see [Azure Static Web Apps hosting plans](../static-web-apps/plans.md).

+- Determine the permissible downtime for relocation.

+- Depending on your Azure Static Web App deployment, the following dependent resources may need to be deployed and configured in the target region *prior* to relocation:

+

+ - [Azure Functions](./relocation-functions.md).

+ - [Azure Virtual Network](./relocation-virtual-network.md)

+ - [Azure Front Door](../frontdoor/front-door-overview.md)

+ - [Network Security Group](./relocation-virtual-network-nsg.md)

+ - [Azure Private Link Service](./relocation-private-link.md)

+ - [Azure Key Vault](./relocation-key-vault.md)

+ - [Azure Storage Account](./relocation-storage-account.md)

+ - [Azure Application Gateway](./relocation-app-gateway.md)

+## Downtime

+The relocation of an Azure Static Web site introduces downtime to your application. The downtime is affected by which high availability pattern you have implemented for your Azure Static Web site. General patterns are:

+- **Cold standby**: Workload data is backed up regularly based on its requirements. In case of a disaster, the workload is redeployed in a new Azure region and data is restored.

+- **Warm standby**: The workload is deployed in the business continuity and disaster recovery (BCDR) region, and data is replicated asynchronously or synchronously. In the event of a disaster, the deployment in the disaster recovery (DR) region is scaled up and out.

+- **Multi-region**: The workload is [deployed in both regions](/azure/architecture/web-apps/app-service/architectures/multi-region) and data is replicated synchronously. Both regions have a writable copy of the data. The implementation can be active/passive or active/active.

+## Prepare

+### Deployments with private endpoints

+If your Static Web Apps are deployed with private endpoints, make sure to:

+- Update host name for connection endpoint.

+- Update host name on DNS private zone or custom DNS server (only applicable to Private Link).

+For more information, see [Configure private endpoint in Azure Static Web Apps](../static-web-apps/private-endpoint.md).

+### All other deployments

+For all other deployment types, make sure to:

+- If applicable, retrieve the new Function API keys from Azure Functions in the new region.

+- If the Azure Function has a dependency on a database, ensure that the `DATABASE_CONNECTION_STRING` is updated. This database may not be in scope of regional migration.

+- Update the custom domain to point to the new hostname of the static web app.

+- If using Key Vault, provision a new Key Vault in target region. Update the Function API Keys in Key Vault if applicable. Any other sensitive data not to be stored in code or config files should be stored in this Key Vault

+### Export the template

+To export the Resource Manager template that contains settings that describe your static web app:

+

+1. Sign in to the [Azure portal](https://portal.azure.com).

+1. Go to your static web app.

+1. From the left menu, under *Automation*, select **Export template**.

+ The template may take a moment to generate.

+1. Select **Download**.

+1. Locate the downloaded `.zip` file, and open it into a folder of your choice.

+ This file contains the `.json` files that include the template and scripts to deploy the template.

+1. Make the necessary changes to the template, such as updating the location with target region.

+## Relocate

+Use the following steps to relocate your static web app to another region.

+1. If you are relocating with Private Endpoint, follow the guidelines in [Relocate Azure Private Link Service to another region](./relocation-private-link.md).

+1. If you've provided an existing Azure Functions to your static web app, follow the relocation procedure for [Azure Functions](./relocation-functions.md).

+1. Redeploy you static web app using the [template that you exported and configured in the previous section](#export-the-template).

+ >[!IMPORTANT]

+ > If you're not using a custom domain, your application's URL changes in the target region. In this scenario, ensure that users know about the URL change.

+1. If you're using an Integrated API, create a new Integrated API that's supported by Azure Functions.

+1. Reconfigure your repository (GitHub or Azure DevOps) to deploy into the newly deployed static web app in the target region. Initiate the deployment of the application using GitHub actions or Azure Pipelines.

+1. With a *cold standby* deployment, make sure you inform clients about the new URL. If you're using a custom DNS domain, simply change the DNS entry to point to the target region. With a *warm standby* deployment, a load balancer, such as Front Door or Traffic manager handle migration of the static web app in the source region to the target region.

+| East US | Norway East | | | *Japan West |

+| West US 2 | Sweden Central | | |Korea Central |

+## View Manage identity under VIS

+You can view and create/delete the manage identity under the VIS.

+ :::image type="content" source="media/configure-virtual-instance/delete-vis-button.png" lightbox="media/configure-virtual-instance/delete-vis-button.png" alt-text="Screenshot of VIS resource in the Azure portal, showing delete button in the overview page's menu.":::

+The following is an example of a DCR creation request. For each data source stream&mdash;you can have several in one DCR&mdash;add a new subsection under `"syslog"` in the `"dataSources"` section and set the value of the `"streams"` field according to the source of the messages you want to ingest:

+| Log source | `"streams"` field value |

+See the example of multiple streams sections in the following code sample:

+- **[Triggers](#triggers)** that define what kind of incident event causes the rule to run, subject to **conditions**.

+- **[Conditions](#conditions)** that determine the exact circumstances under which the rule runs and performs **actions**.

+- **[Actions](#actions)** to change the incident in some way or call a [playbook](automate-responses-with-playbooks.md), which performs more complex actions and interacts with other services.

+The following table shows the different possible scenarios that cause an automation rule to run.

+When an automation rule is triggered, it checks the triggering incident or alert against the conditions defined in the rule. For incidents, the property-based conditions are evaluated according to **the current state** of the property at the moment the evaluation occurs, or according to **changes in the state** of the property (see below for details). Since a single incident creation or update event could trigger several automation rules, the **order** in which they run (see below) makes a difference in determining the outcome of the conditions' evaluation. The **actions** defined in the rule are executed only if all the conditions are satisfied.

+In *Incident 2*, the outcome is the same, regardless of which type of condition is defined.

+Currently the only condition that can be configured for the alert creation trigger is the set of analytics rules for which the automation rule is run.

+Also, you can define an action to [**run a playbook**](tutorial-respond-threats-playbook.md), in order to take more complex response actions, including any that involve external systems. The playbooks available to be used in an automation rule depend on the [**trigger**](automate-responses-with-playbooks.md#azure-logic-apps-basic-concepts) on which the playbooks *and* the automation rule are based: Only incident-trigger playbooks can be run from incident-trigger automation rules, and only alert-trigger playbooks can be run from alert-trigger automation rules. You can define multiple actions that call playbooks, or combinations of playbooks and other actions. Actions are executed in the order in which they are listed in the rule.

+Playbooks using [either version of Azure Logic Apps (Standard or Consumption)](automate-responses-with-playbooks.md#logic-app-types) are available to run from automation rules.

+You can define an expiration date on an automation rule. The rule is disabled after that date passes. This is useful for handling (that is, closing) "noise" incidents caused by planned, time-limited activities such as penetration testing.

+You can define the order in which automation rules are run. Later automation rules evaluate the conditions of the incident according to its state after being acted on by previous automation rules.

+For example, if "First Automation Rule" changed an incident's severity from Medium to Low, and "Second Automation Rule" is defined to run only on incidents with Medium or higher severity, it doesn't run on that incident.

+The order of automation rules that add [incident tasks](incident-tasks.md) determines the order in which the tasks appear in a given incident.

+Rules based on the update trigger have their own separate order queue. If such rules are triggered to run on a just-created incident (by a change made by another automation rule), they run only after all the applicable rules based on the create trigger are finished running.

+- For rules created in the Azure portal, the **order** field is automatically populated with the number following the highest number used by existing rules of the same trigger type.

+- For rules of the same trigger type with the same order number, the execution engine randomly selects which rules run in which order.

+- For rules of different *incident trigger* types, all applicable rules with the *incident creation* trigger type run first (according to their order numbers), and only then the rules with the *incident update* trigger type (according to *their* order numbers).

+Automation rules allow you to standardize and formalize the steps required for the triaging, investigation, and remediation of incidents, by [creating tasks](incident-tasks.md) that can be applied to a single incident, across groups of incidents, or to all incidents, according to the conditions you set in the automation rule and the threat detection logic in the underlying analytics rules. Tasks applied to an incident appear in the incident's page, so your analysts have the entire list of actions they need to take, right in front of them, and don't miss any critical steps.

+Notify your various teams and other personnel when changes are made to incidents, so they don't miss any critical updates. Escalate incidents by assigning them to new owners and informing the new owners of their assignments. Control when and how incidents are reopened.

+If you've used playbooks to create tickets in external systems when incidents are created, you can use an update-trigger automation rule to call a playbook that updates those tickets.

+In order for an automation rule to run a playbook, this account must be granted explicit permissions to the resource group where the playbook resides. At that point, any automation rule can run any playbook in that resource group.

+When you're configuring an automation rule and adding a **run playbook** action, a drop-down list of playbooks appears. Playbooks to which Microsoft Sentinel does not have permissions display as unavailable ("grayed out"). You can grant Microsoft Sentinel permission to the playbooks' resource groups on the spot by selecting the **Manage playbook permissions** link. To grant those permissions, you need **Owner** permissions on those resource groups. [See the full permissions requirements](tutorial-respond-threats-playbook.md#respond-to-incidents).

+ This approach is normally used to protect intellectual property in the playbook. Nothing special is required for this scenario to work. When defining a playbook action in your automation rule, and you get to the stage where you grant Microsoft Sentinel permissions on the relevant resource group where the playbook is located (using the **Manage playbook permissions** panel), you can see the resource groups belonging to the service provider tenant among those you can choose from. [See the whole process outlined here](tutorial-respond-threats-playbook.md#respond-to-incidents).

+ When you need an automation rule that applies to incidents from Microsoft Defender XDR, or from many analytics rules in Microsoft Sentinel, create it directly in the **Automation** page.

+ When you create an automation rule from here, the **Create new automation rule** panel shows the **analytics rule** condition as unavailable, because this rule is already set to apply only to the analytics rule you're editing in the wizard. All the other configuration options are still available to you.

+ When you create an automation rule from here, the **Create new automation rule** panel populates all the fields with values from the incident. It names the rule the same name as the incident, applies it to the analytics rule that generated the incident, and uses all the available entities in the incident as conditions of the rule. It also suggests a suppression (closing) action by default, and suggests an expiration date for the rule. You can add or remove conditions and actions, and change the expiration date, as you wish.

+### Export and import automation rules (Preview)

+Export your automation rules to Azure Resource Manager (ARM) template files, and import rules from these files, as part of managing and controlling your Microsoft Sentinel deployments as code. The export action creates a JSON file in your browser's downloads location, that you can then rename, move, and otherwise handle like any other file.

+The exported JSON file is workspace-independent, so it can be imported to other workspaces and even other tenants. As code, it can also be version-controlled, updated, and deployed in a managed CI/CD framework.

+The file includes all the parameters defined in the automation rule. Rules of any trigger type can be exported to a JSON file.

+For instructions on exporting and importing automation rules, see [Export and import Microsoft Sentinel automation rules](import-export-automation-rules.md).

+## Custom Logs via AMA connector

+Filter and ingest logs in text-file format from network or security applications installed on Windows or Linux machines by using the **Custom Logs via AMA connector** in Microsoft Sentinel. For more information, see the following articles:

+- [Collect logs from text files with the Azure Monitor Agent and ingest to Microsoft Sentinel](/azure/sentinel/connect-custom-logs-ama?tabs=portal)

+- [Custom Logs via AMA data connector - Configure data ingestion to Microsoft Sentinel from specific applications](/azure/sentinel/unified-connector-custom-device)

+ :::image type="content" source="./media/import-export-analytics-rules/export-analytics-rule.png" alt-text="Export analytics rule" lightbox="./media/import-export-analytics-rules/export-analytics-rule.png":::

+ :::image type="content" source="./media/import-export-analytics-rules/import-analytics-rule.png" alt-text="Import analytics rule" lightbox="./media/import-export-analytics-rules/import-analytics-rule.png":::

+ Title: Import and export Microsoft Sentinel automation rules | Microsoft Docs

+description: Export and import automation rules to and from ARM templates to aid deployment

+appliesto:

+ - Microsoft Sentinel in the Azure portal

+ - Microsoft Sentinel in the Microsoft Defender portal

+# Export and import automation rules to and from ARM templates

+Manage your Microsoft Sentinel automation rules as code! You can now export your automation rules to Azure Resource Manager (ARM) template files, and import rules from these files, as part of your program to manage and control your Microsoft Sentinel deployments as code. The export action creates a JSON file in your browser's downloads location, that you can then rename, move, and otherwise handle like any other file.

+The exported JSON file is workspace-independent, so it can be imported to other workspaces and even other tenants. As code, it can also be version-controlled, updated, and deployed in a managed CI/CD framework.

+The file includes all the parameters defined in the automation rule. Rules of any trigger type can be exported to a JSON file.

+This article shows you how to export and import automation rules.

+> [!IMPORTANT]

+>

+> - Exporting and importing rules is in **PREVIEW**. See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

+>

+> - [!INCLUDE [unified-soc-preview](includes/unified-soc-preview-without-alert.md)]

+## Export rules

+1. From the Microsoft Sentinel navigation menu, select **Automation**.

+1. Select the rule (or rules&mdash;see note) you want to export, and select **Export** from the bar at the top of the screen.

+ :::image type="content" source="./media/import-export-automation-rules/export-automation-rule.png" alt-text="Screenshot showing how to export an automation rule." lightbox="./media/import-export-automation-rules/export-automation-rule.png":::

+ Find the exported file in your Downloads folder. It has the same name as the automation rule, with a .json extension.

+ > [!NOTE]

+ > - You can select multiple automation rules at once for export by marking the check boxes next to the rules and selecting **Export** at the end.

+ >

+ > - You can export all the rules on a single page of the display grid at once, by marking the check box in the header row before clicking **Export**. You can't export more than one page's worth of rules at a time, though.

+ >

+ > - In this scenario, a single file (named *Azure_Sentinel_automation_rules.json*) is created, and contains JSON code for all the exported rules.

+## Import rules

+1. Have an automation rule ARM template JSON file ready.

+1. From the Microsoft Sentinel navigation menu, select **Automation**.

+1. Select **Import** from the bar at the top of the screen. In the resulting dialog box, navigate to and select the JSON file representing the rule you want to import, and select **Open**.

+ :::image type="content" source="./media/import-export-automation-rules/import-automation-rule.png" alt-text="Screenshot showing how to import an automation rule." lightbox="./media/import-export-automation-rules/import-automation-rule.png":::

+ > [!NOTE]

+ > You can import **up to 50** automation rules from a single ARM template file.

+## Troubleshooting

+If you have any issues importing an exported automation rule, consult the following table.

+| Behavior (with *error*) | Reason | Suggested action |

+| -- | | - |

+| **Imported automation rule is disabled**<br>-*and*-<br>**The rule's *analytics rule* condition displays "Unknown rule"** | The rule contains a condition that refers to an analytics rule that doesn't exist in the target workspace. | <ol><li>Export the referenced analytics rule from the original workspace and import it to the target one.<li>Edit the automation rule in the target workspace, choosing the now-present analytics rule from the drop-down.<li>Enable the automation rule.</ol> |

+| **Imported automation rule is disabled**<br>-*and*-<br>**The rule's *custom details key* condition displays "Unknown custom details key"** | The rule contains a condition that refers to a [custom details key](surface-custom-details-in-alerts.md) that isn't defined in any analytics rules in the target workspace. | <ol><li>Export the referenced analytics rule from the original workspace and import it to the target one.<li>Edit the automation rule in the target workspace, choosing the now-present analytics rule from the drop-down.<li>Enable the automation rule. |

+| **Deployment failed in target workspace, with error message: "*Automation rules failed to deploy.*"**<br>Deployment details contain the reasons listed in the next column for failure. | The playbook was moved.<br>-*or*-<br>The playbook was deleted.<br>-*or*-<br>The target workspace doesn't have access to the playbook. | Make sure the playbook exists, and that the target workspace has the right access to the resource group that contains the playbook. |

+| **Deployment failed in target workspace, with error message: "*Automation rules failed to deploy.*"**<br>Deployment details contain the reasons listed in the next column for failure . | The automation rule was past its defined expiration date when you imported it. | **If you want the rule to remain expired in its original workspace:**<ol><li>Edit the JSON file that represents the exported automation rule.<li>Find the expiration date (that appears immediately after the string `"expirationTimeUtc":`) and replace it with a new expiration date (in the future).<li>Save the file and re-import it into the target workspace.</ol>**If you want the rule to return to active status in its original workspace:**<ol><li>Edit the automation rule in the original workspace and change its expiration date to a date in the future.<li>Export the rule again from the original workspace.<li>Import the newly exported version into the target workspace.</ol> |

+| **Deployment failed in target workspace, with error message:<br>"*The JSON file you attempted to import has an invalid format. Please check the file and try again.*"** | The imported file isn't a valid JSON file. | Check the file for problems and try again. For best results, export the original rule again to a new file, then try the import again. |

+| **Deployment failed in target workspace, with error message:<br>"*No resources found in the file. Please ensure the file contains deployment resources and try again.*"** | The list of resources under the "resources" key in the JSON file is empty. | Check the file for problems and try again. For best results, export the original rule again to a new file, then try the import again. |

+## Next steps

+In this document, you learned how to export and import automation rules to and from ARM templates.

+- Learn more about [automation rules](automate-incident-handling-with-automation-rules.md) and [how to create and work with them](create-manage-use-automation-rules.md).

+- Learn more about [ARM templates](../azure-resource-manager/templates/overview.md).

+- [Export and import automation rules (Preview)](#export-and-import-automation-rules-preview)

+### Export and import automation rules (Preview)

+Manage your Microsoft Sentinel automation rules as code! You can now export your automation rules to Azure Resource Manager (ARM) template files, and import rules from these files, as part of your program to manage and control your Microsoft Sentinel deployments as code. The export action will create a JSON file in your browser's downloads location, that you can then rename, move, and otherwise handle like any other file.

+The exported JSON file is workspace-independent, so it can be imported to other workspaces and even other tenants. As code, it can also be version-controlled, updated, and deployed in a managed CI/CD framework.

+The file includes all the parameters defined in the automation rule. Rules of any trigger type can be exported to a JSON file.

+Learn more about [exporting and importing automation rules](import-export-automation-rules.md).

+- For partitioned premium namespaces, the message size is limited to 1 MB when the messages are sent individually, and the batch size is limited to 1 MB when the messages are sent in a batch. If [Large message support](/azure/service-bus-messaging/service-bus-premium-messaging) is enabled the size limit can be up to 100MB.

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to create a container. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Contributor** or higher. To learn more, see the authorization guidance for [Create Container (REST API)](/rest/api/storageservices/create-container#authorization).

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to delete or restore a container. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Contributor** or higher. To learn more, see the authorization guidance for [Delete Container (REST API)](/rest/api/storageservices/delete-container#authorization) and [Restore Container (REST API)](/rest/api/storageservices/restore-container#authorization).

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to work with a container lease. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Contributor** or higher. To learn more, see the authorization guidance for [Lease Container (REST API)](/rest/api/storageservices/lease-container#authorization).

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to work with container properties or metadata. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Reader** or higher for the *get* operations, and **Storage Blob Data Contributor** or higher for the *set* operations. To learn more, see the authorization guidance for [Get Container Properties (REST API)](/rest/api/storageservices/get-container-properties#authorization), [Set Container Metadata (REST API)](/rest/api/storageservices/set-container-metadata#authorization), or [Get Container Metadata (REST API)](/rest/api/storageservices/get-container-metadata#authorization).

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to list blob containers. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Contributor** or higher. To learn more, see the authorization guidance for [List Containers (REST API)](/rest/api/storageservices/list-containers2#authorization).

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to perform a copy operation, or to abort a pending copy. For authorization with Microsoft Entra ID (recommended), the least privileged Azure RBAC built-in role varies based on several factors. To learn more, see the authorization guidance for [Copy Blob (REST API)](/rest/api/storageservices/copy-blob#authorization) or [Abort Copy Blob (REST API)](/rest/api/storageservices/abort-copy-blob#authorization).

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to perform a copy operation. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Contributor** or higher. To learn more, see the authorization guidance for [Put Blob From URL (REST API)](/rest/api/storageservices/put-blob-from-url#authorization) or [Put Block From URL (REST API)](/rest/api/storageservices/put-block-from-url#authorization).

+### Code samples

+- [View code samples from this article (GitHub)](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/Java/blob-devguide/blob-devguide-blobs/src/main/java/com/blobs/devguide/blobs/BlobCopyPutFromURL.java)

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to delete a blob, or to restore a soft-deleted blob. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Contributor** or higher. To learn more, see the authorization guidance for [Delete Blob (REST API)](/rest/api/storageservices/delete-blob#authorization) and [Undelete Blob (REST API)](/rest/api/storageservices/undelete-blob#authorization).

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to perform a download operation. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Reader** or higher. To learn more, see the authorization guidance for [Get Blob (REST API)](/rest/api/storageservices/get-blob#authorization).

+The following example uses [BlobServiceClientBuilder](/java/api/com.azure.storage.blob.blobserviceclientbuilder) to build a `BlobServiceClient` object using `DefaultAzureCredential`, and shows how to create container and blob clients, if needed:

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to work with a blob lease. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Contributor** or higher. To learn more, see the authorization guidance for [Lease Blob (REST API)](/rest/api/storageservices/lease-blob#authorization).

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to work with container properties or metadata. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Reader** or higher for the *get* operations, and **Storage Blob Data Contributor** or higher for the *set* operations. To learn more, see the authorization guidance for [Set Blob Properties (REST API)](/rest/api/storageservices/set-blob-properties#authorization), [Get Blob Properties (REST API)](/rest/api/storageservices/get-blob-properties#authorization), [Set Blob Metadata (REST API)](/rest/api/storageservices/set-blob-metadata#authorization), or [Get Blob Metadata (REST API)](/rest/api/storageservices/get-blob-metadata#authorization).

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to work with blob index tags. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Owner** or higher. To learn more, see the authorization guidance for [Get Blob Tags (REST API)](/rest/api/storageservices/get-blob-tags#authorization), [Set Blob Tags (REST API)](/rest/api/storageservices/set-blob-tags#authorization), or [Find Blobs by Tags (REST API)](/rest/api/storageservices/find-blobs-by-tags#authorization).

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to upload a blob. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Contributor** or higher. To learn more, see the authorization guidance for [Put Blob (REST API)](/rest/api/storageservices/put-blob#authorization) and [Put Block (REST API)](/rest/api/storageservices/put-block#authorization).

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to set a blob's access tier. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Contributor** or higher. To learn more, see the authorization guidance for [Set Blob Tier](/rest/api/storageservices/set-blob-tier#authorization).

+## Set up your environment

+#### Add import statements

+Add the following `import` statements:

+#### Authorization

+The authorization mechanism must have the necessary permissions to list a blob. For authorization with Microsoft Entra ID (recommended), you need Azure RBAC built-in role **Storage Blob Data Reader** or higher. To learn more, see the authorization guidance for [List Blobs (REST API)](/rest/api/storageservices/list-blobs#authorization).

+ Title: Change redundancy configuration for Azure Files

+description: Learn how to change how Azure Files data in an existing storage account is replicated.

+# Change how Azure Files data is replicated

+Azure always stores multiple copies of your data to protect it in the face of both planned and unplanned events. These events include transient hardware failures, network or power outages, and natural disasters. Data redundancy ensures that your storage account meets the [Service-Level Agreement (SLA) for Azure Storage](https://azure.microsoft.com/support/legal/sla/storage/), even in the face of failures.

+This article describes the process of changing replication settings for an existing storage account.

+## Options for changing the replication type

+When deciding which redundancy configuration is best for your scenario, consider the tradeoffs between lower costs and higher availability. The factors that help determine which redundancy configuration you should choose include:

+- **How your data is replicated within the primary region.** Data in the primary region can be replicated locally using [locally redundant storage (LRS)](files-redundancy.md#locally-redundant-storage), or across Azure availability zones using [zone-redundant storage (ZRS)](files-redundancy.md#zone-redundant-storage).

+- **Whether your data requires geo-redundancy.** Geo-redundancy provides protection against regional disasters by replicating your data to a second region that is geographically distant to the primary region. Azure Files supports both [geo-redundant storage (GRS)](files-redundancy.md#geo-redundant-storage) and [geo-zone-redundant storage (GZRS)](files-redundancy.md#geo-zone-redundant-storage).

+> [!IMPORTANT]

+> Azure Files doesn't support read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS). If a storage account is configured to use RA-GRS or RA-GZRS, the file shares will be configured and billed as GRS or GZRS.

+For a detailed overview of all of the redundancy options for Azure Files, see [Azure Files redundancy](files-redundancy.md).

+You can change your storage account's redundancy configurations as needed, though some configurations are subject to [limitations](#limitations-for-changing-replication-types) and [downtime requirements](#downtime-requirements). Reviewing these limitations and requirements before making any changes within your environment helps avoid conflicts with your own timeframe and uptime requirements.

+There are three ways to change the replication settings:

+- [Add or remove geo-redundancy or read access](#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli) to the secondary region.

+- [Add or remove zone-redundancy](#perform-a-conversion) by performing a conversion.

+- [Perform a manual migration](#manual-migration) in scenarios where the first two options aren't supported, or to ensure the change is completed within a specific timeframe.

+Geo-redundancy and read-access can be changed at the same time. However, any change that also involves zone-redundancy requires a conversion and must be performed separately using a two-step process. These two steps can be performed in any order.

+### Changing redundancy configuration

+The following table provides an overview of how to switch between replication types.

+> [!NOTE]

+> Manual migration is an option for any scenario in which you want to change the replication setting within the [limitations for changing replication types](#limitations-for-changing-replication-types). The manual migration option is excluded from the following table for simplification.

+| Switching | ΓǪto LRS | ΓǪto GRS ⁶ | ΓǪto ZRS | ΓǪto GZRS ^2,6 |

+|--|-||-||

+| **ΓǪfrom LRS** | **N/A** | Use [Azure portal](files-change-redundancy-configuration.md?tabs=portal#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), [PowerShell](files-change-redundancy-configuration.md?tabs=powershell#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), or [CLI](files-change-redundancy-configuration.md?tabs=azure-cli#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli) ^1,2 | [Perform a conversion](#perform-a-conversion)^2,3,4,5 | First, use the [Portal](files-change-redundancy-configuration.md?tabs=portal#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), [PowerShell](files-change-redundancy-configuration.md?tabs=powershell#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), or [CLI](files-change-redundancy-configuration.md?tabs=azure-cli#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli) to switch to GRS ¹, then [perform a conversion](#perform-a-conversion) to GZRS ^3,4,5 |

+| **…from GRS** | Use [Azure portal](files-change-redundancy-configuration.md?tabs=portal#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), [PowerShell](files-change-redundancy-configuration.md?tabs=powershell#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), or [CLI](files-change-redundancy-configuration.md?tabs=azure-cli#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli) | **N/A** | First, use the [Portal](files-change-redundancy-configuration.md?tabs=portal#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), [PowerShell](files-change-redundancy-configuration.md?tabs=powershell#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), or [CLI](files-change-redundancy-configuration.md?tabs=azure-cli#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli) to switch to LRS, then [perform a conversion](#perform-a-conversion) to ZRS ^3,5 | [Perform a conversion](#perform-a-conversion)^3,5 |

+| **ΓǪfrom ZRS** | [Perform a conversion](#perform-a-conversion)³ | First, use the [Portal](files-change-redundancy-configuration.md?tabs=portal#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), [PowerShell](files-change-redundancy-configuration.md?tabs=powershell#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), or [CLI](files-change-redundancy-configuration.md?tabs=azure-cli#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli) to switch to GZRS, then [perform a conversion](#perform-a-conversion) to GRS³ | **N/A** | Use [Azure portal](files-change-redundancy-configuration.md?tabs=portal#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), [PowerShell](files-change-redundancy-configuration.md?tabs=powershell#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), or [CLI](files-change-redundancy-configuration.md?tabs=azure-cli#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli) ¹ |

+| **ΓǪfrom GZRS** | First, use the [Portal](files-change-redundancy-configuration.md?tabs=portal#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), [PowerShell](files-change-redundancy-configuration.md?tabs=powershell#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli), or [CLI](files-change-redundancy-configuration.md?tabs=azure-cli#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli) to switch to ZRS, then [perform a conversion](#perform-a-conversion) to LRS ³ | [Perform a conversion](#perform-a-conversion)³ | [Use Azure portal, PowerShell, or CLI](#change-the-redundancy-configuration-using-azure-portal-powershell-or-azure-cli)| **N/A** |

+¹ [Adding geo-redundancy incurs a one-time egress charge](#costs-associated-with-changing-how-data-is-replicated).<br />

+² If your storage account contains blobs in the archive tier, review the [access tier limitations](../common/redundancy-migration.md#access-tier) before changing the redundancy type to geo- or zone-redundant.<br />

+³ The type of conversion supported depends on the storage account type. For more information, see the [storage account table](#storage-account-type).<br />

+⁴ Conversion to ZRS or GZRS for an LRS account resulting from a failover isn't supported. For more information, see [Failover and failback](#failover-and-failback).<br />

+⁵ Converting from LRS to ZRS [isn't supported if the NFSv3 protocol support is enabled for Azure Blob Storage or if the storage account contains Azure Files NFSv4.1 shares](#protocol-support). <br />

+⁶ Even though enabling geo-redundancy appears to occur instantaneously, failover to the secondary region can't be initiated until data synchronization between the two regions is complete.<br />

+## Change the replication setting

+Depending on your scenario from the [changing redundancy configuration](#changing-redundancy-configuration) section, use one of the following methods to change your replication settings.

+### Change the redundancy configuration using Azure portal, PowerShell, or Azure CLI

+In most cases you can use the Azure portal, PowerShell, or the Azure CLI to change the geo-redundant or read access (RA) replication setting for a storage account.

+Changing how your storage account is replicated in the Azure portal doesn't result in down time for your applications, including changes that require a conversion.

+# [Portal](#tab/portal)

+To change the redundancy option for your storage account in the Azure portal, follow these steps:

+1. Navigate to your storage account in the Azure portal.

+1. Under **Data management** select **Redundancy**.

+1. Update the **Redundancy** setting.

+1. Select **Save**.

+ :::image type="content" source="../common/media/redundancy-migration/change-replication-option-sml.png" alt-text="Screenshot showing how to change replication option in portal." lightbox="../common/media/redundancy-migration/change-replication-option.png":::

+# [PowerShell](#tab/powershell)

+You can use Azure PowerShell to change the redundancy options for your storage account.

+To change between locally redundant and geo-redundant storage, call the [Set-AzStorageAccount](/powershell/module/az.storage/set-azstorageaccount) cmdlet and specify the `-SkuName` parameter.

+```powershell

+Set-AzStorageAccount -ResourceGroupName <resource_group> `

+ -Name <storage_account> `

+ -SkuName <sku>

+```

+# [Azure CLI](#tab/azure-cli)

+You can use the Azure CLI to change the redundancy options for your storage account.

+To change between locally redundant and geo-redundant storage, call the [az storage account update](/cli/azure/storage/account#az-storage-account-update) command and specify the `--sku` parameter:

+```azurecli-interactive

+az storage account update \

+ --name <storage-account> \

+ --resource-group <resource_group> \

+ --sku <sku>

+```

+### Perform a conversion

+A redundancy "conversion" is the process of changing the zone-redundancy aspect of a storage account.

+During a conversion, there's [no data loss or application downtime required](#downtime-requirements).

+There are two ways to initiate a conversion:

+- [Customer-initiated](#customer-initiated-conversion)

+- [Support-initiated](#support-initiated-conversion)

+> [!TIP]

+> Microsoft recommends using a customer-initiated conversion instead of support-initiated conversion whenever possible. A customer-initiated conversion allows you to initiate the conversion and monitor its progress directly from within the Azure portal. Because the conversion is initiated by the customer, there is no need to create and manage a support request.

+#### Customer-initiated conversion

+Instead of opening a support request, customers in most regions can start a conversion and monitor its progress. This option eliminates potential delays related to creating and managing support requests. For help determining the regions in which customer-initiated conversion is supported, see the [region limitations](#region) article.

+Customer-initiated conversion can be completed in supported regions using the Azure portal, PowerShell, or the Azure CLI. After initiation, the conversion could still take up to 72 hours to begin.

+> [!IMPORTANT]

+> There is no SLA for completion of a conversion.

+>

+> If you need more control over when a conversion begins and finishes, consider a [Manual migration](#manual-migration). Generally, the more data you have in your account, the longer it takes to replicate that data to other zones or regions.

+>

+> For more information about the timing of a customer-initiated conversion, see [Timing and frequency](#timing-and-frequency).

+# [Portal](#tab/portal)

+To add or modify a storage account's zonal-redundancy within the Azure portal, perform these steps:

+1. Navigate to your storage account in the Azure portal.

+1. Under **Data management** select **Redundancy**.

+1. Update the **Redundancy** setting.

+1. Select **Save**.

+ :::image type="content" source="../common/media/redundancy-migration/change-replication-zone-option-sml.png" alt-text="Screenshot showing how to change the zonal-replication option in portal." lightbox="../common/media/redundancy-migration/change-replication-zone-option.png":::

+# [PowerShell](#tab/powershell)

+To change between locally redundant and zone-redundant storage with PowerShell, call the [Start-AzStorageAccountMigration](/powershell/module/az.storage/start-azstorageaccountmigration) command and specify the `-TargetSku` parameter:

+```powershell

+Start-AzStorageAccountMigration

+ -AccountName <String>

+ -ResourceGroupName <String>

+ -TargetSku <String>

+ -AsJob

+```

+# [Azure CLI](#tab/azure-cli)

+To change between locally redundant and zone-redundant storage with Azure CLI, call the [az storage account migration start](/cli/azure/storage/account/migration#az-storage-account-migration-start) command and specify the `--sku` parameter:

+```azurecli-interactive

+az storage account migration start \

+ -- account-name <string> \

+ -- g <string> \

+ --sku <string> \

+ --no-wait

+```

+##### Monitoring customer-initiated conversion progress

+As the conversion request is evaluated and processed, the status should progress through the list shown in the following table:

+| Status | Explanation |

+||--|

+| Submitted for conversion | The conversion request was successfully submitted for processing. |

+| In Progress¹ | The conversion is in progress. |

+| Completed<br>**- or -**</br>Failed² | The conversion is completed successfully.<br>**- or -**</br>The conversion failed. |

+¹ Once initiated, the conversion could take up to 72 hours to begin. If the conversion doesn't enter the "In Progress" status within 96 hours of initiating the request, submit a support request to Microsoft to determine why. For more information about the timing of a customer-initiated conversion, see [Timing and frequency](#timing-and-frequency).<br />

+² If the conversion fails, submit a support request to Microsoft to determine the reason for the failure.<br />

+> [!NOTE]

+> While Microsoft handles your request for a conversion promptly, there's no guarantee as to when it will complete. If you need your data converted by a certain date, Microsoft recommends that you perform a manual migration instead.

+>

+> Generally, the more data you have in your account, the longer it takes to replicate that data to other zones in the region.

+# [Portal](#tab/portal)

+The status of your customer-initiated conversion is displayed on the **Redundancy** page of the storage account:

+# [PowerShell](#tab/powershell)

+To track the current migration status of the conversion initiated on your storage account, call the [Get-AzStorageAccountMigration](/powershell/module/az.storage/get-azstorageaccountmigration) cmdlet:

+```powershell

+Get-AzStorageAccountMigration

+ -AccountName <String>

+ -ResourceGroupName <String>

+```

+# [Azure CLI](#tab/azure-cli)

+To track the current migration status of the conversion initiated on your storage account, use the [az storage account migration show](/cli/azure/storage/account/migration#az-storage-account-migration-show) command:

+```azurecli-interactive

+az storage account migration show \

+ --account-name <string> \

+ - g <sting> \

+ -n "default"

+```

+#### Support-initiated conversion

+Customers can request a conversion by opening a support request with Microsoft.

+> [!TIP]

+> If you need to convert more than one storage account, create a single support ticket and specify the names of the accounts to convert on the **Additional details** tab.

+Follow these steps to request a conversion from Microsoft:

+1. In the Azure portal, navigate to a storage account that you want to convert.

+1. Under **Support + troubleshooting**, select **New Support Request**.

+1. Complete the **Problem description** tab based on your account information:

+ - **Summary**: (some descriptive text).

+ - **Issue type**: Select **Technical**.

+ - **Subscription**: Select your subscription from the drop-down.

+ - **Service**: Select **My Services**, then **Storage Account Management** for the **Service type**.

+ - **Resource**: Select a storage account to convert. If you need to specify multiple storage accounts, you can do so on the **Additional details** tab.

+ - **Problem type**: Choose **Data Migration**.

+ - **Problem subtype**: Choose **Migrate to ZRS, GZRS, or RA-GZRS**.

+ :::image type="content" source="../common/media/redundancy-migration/request-live-migration-problem-desc-portal-sml.png" alt-text="Screenshot showing how to request a conversion - Problem description tab." lightbox="../common/media/redundancy-migration/request-live-migration-problem-desc-portal.png":::

+1. Select **Next**. The **Recommended solution** tab might be displayed briefly before it switches to the **Solutions** page. On the **Solutions** page, you can check the eligibility of your storage account(s) for conversion:

+ - **Target replication type**: (choose the desired option from the drop-down)

+ - **Storage accounts from**: (enter a single storage account name or a list of accounts separated by semicolons)

+ - Select **Submit**.

+ :::image type="content" source="../common/media/redundancy-migration/request-live-migration-solutions-portal-sml.png" alt-text="Screenshot showing how to check the eligibility of your storage account(s) for conversion - Solutions page." lightbox="../common/media/redundancy-migration/request-live-migration-solutions-portal.png":::

+1. Take the appropriate action if the results indicate your storage account isn't eligible for conversion. Otherwise, select **Return to support request**.

+1. Select **Next**. If you have more than one storage account to migrate, on the **Details** tab, specify the name for each account, separated by a semicolon.

+ :::image type="content" source="../common/media/redundancy-migration/request-live-migration-details-portal-sml.png" alt-text="Screenshot showing how to request a conversion - Additional details tab." lightbox="../common/media/redundancy-migration/request-live-migration-details-portal.png":::

+1. Provide the required information on the **Additional details** tab, then select **Review + create** to review and submit your support ticket. An Azure support agent reviews your case and contacts you to provide assistance.

+### Manual migration

+A manual migration provides more flexibility and control than a conversion. You can use this option if you need your data moved by a certain date, or if conversion [isn't supported for your scenario](#limitations-for-changing-replication-types). Manual migration is also useful when moving a storage account to another region. For more detail, see [Move an Azure Storage account to another region](../common/storage-account-move.md).

+You must perform a manual migration if you want to migrate your storage account to a different region.

+> [!IMPORTANT]

+> A manual migration can result in application downtime. If your application requires high availability, Microsoft also provides a [conversion](#perform-a-conversion) option. A conversion is an in-place migration with no downtime.

+With a manual migration, you copy the data from your existing storage account to a new storage account. To perform a manual migration, you can use one of the following options:

+- Copy data by using an existing tool such as AzCopy, one of the Azure Storage client libraries, or a reliable non-Microsoft tool.

+- If you're familiar with Hadoop or HDInsight, you can attach both the source storage account and destination storage account to your cluster. Then, parallelize the data copy process with a tool like DistCp.

+For more detailed guidance on how to perform a manual migration, see [Move an Azure Storage account to another region](../common/storage-account-move.md).

+## Limitations for changing replication types

+> [!IMPORTANT]

+> Boot diagnostics doesn't support premium storage accounts or zone-redundant storage accounts. When either premium or zone-redundant storage accounts are used for boot diagnostics, users receive a `StorageAccountTypeNotSupported` error upon starting their virtual machine (VM).

+Limitations apply to some replication change scenarios depending on:

+- [Region](#region)

+- [Feature conflicts](#feature-conflicts)

+- [Storage account type](#storage-account-type)

+- [Protocol support](#protocol-support)

+- [Failover and failback](#failover-and-failback)

+### Region

+Make sure the region where your storage account is located supports all of the desired replication settings. For example, if you're converting your account to zone-redundant (ZRS or GZRS), make sure your storage account is in a region that supports it. See the lists of supported regions for [Zone-redundant storage](files-redundancy.md#zone-redundant-storage) and [Geo-zone-redundant storage](files-redundancy.md#geo-zone-redundant-storage).

+> [!IMPORTANT]

+> [Customer-initiated conversion](#customer-initiated-conversion) from LRS to ZRS is available in all public regions that support ZRS except for the following:

+>

+> - (Europe) Italy North

+> - (Europe) UK South

+> - (Europe) Poland Central

+> - (Europe) West Europe

+> - (Middle East) Israel Central

+> - (North America) Canada Central

+> - (North America) East US

+> - (North America) East US 2

+>

+> [Customer-initiated conversion](#customer-initiated-conversion) from existing ZRS accounts to LRS is available in all public regions.

+### Feature conflicts

+Some storage account features aren't compatible with other features or operations. For example, the ability to fail over to the secondary region is the key feature of geo-redundancy, but other features aren't compatible with failover. For more information about features and services not supported with failover, see [Unsupported features and services](../common/storage-disaster-recovery-guidance.md#unsupported-features-and-services). The conversion of an account to GRS or GZRS might be blocked if a conflicting feature is enabled, or it might be necessary to disable the feature later before initiating a failover.

+### Storage account type

+When planning to change your replication settings, consider the following limitations related to the storage account type.

+Some storage account types only support certain redundancy configurations, which affect whether they can be converted or migrated and, if so, how. For more information on Azure storage account types and the supported redundancy options, see [the storage account overview](../common/storage-account-overview.md#types-of-storage-accounts).

+The following table lists the redundancy options available for storage account types and whether conversion and manual migration are supported:

+| Storage account type | Supports LRS | Supports ZRS | Supports conversion<br>(from the portal) | Supports conversion<br>(by support request) | Supports manual migration |

+|:-|::|::|:--:|:-:|:-:|

+| Standard general purpose v2 | &#x2705; | &#x2705; | &#x2705; | &#x2705; | &#x2705; |

+| Premium file shares | &#x2705; | &#x2705; | | &#x2705; ¹ | &#x2705; |

+¹ Conversion for premium file shares is only available by [opening a support request](#support-initiated-conversion); [Customer-initiated conversion](#customer-initiated-conversion) isn't currently supported.<br />

+### Protocol support

+You can't convert storage accounts to zone-redundancy (ZRS or GZRS) if either of the following cases are true:

+- NFSv3 protocol support is enabled for Azure Blob Storage

+- The storage account contains Azure Files NFSv4.1 shares

+### Failover and failback

+After an account failover to the secondary region, it's possible to initiate a failback from the new primary back to the new secondary with PowerShell or Azure CLI (version 2.30.0 or later). [Initiate the failover](../common/storage-initiate-account-failover.md#initiate-the-failover).

+If you performed a customer-managed account failover to recover from an outage for your GRS account, the account becomes locally redundant (LRS) in the new primary region after the failover. Conversion to ZRS or GZRS for an LRS account resulting from a failover isn't supported, even for so-called failback operations. For example, if you perform an account failover from GRS to LRS in the secondary region, and then configure it again as GRS, it remains LRS in the new secondary region (the original primary). If you then perform another account failover to failback to the original primary region, it remains LRS again in the original primary. In this case, you can't perform a conversion to ZRS or GZRS in the primary region. Instead, perform a manual migration to add zone-redundancy.

+## Downtime requirements

+During a [conversion](#perform-a-conversion), you can access data in your storage account with no loss of durability or availability. [The Azure Storage SLA](https://azure.microsoft.com/support/legal/sla/storage/) is maintained during the migration process and no data is lost during a conversion. Service endpoints, access keys, shared access signatures, and other account options remain unchanged after the migration.

+If you choose to perform a manual migration, downtime is required but you have more control over the timing of the migration process.

+## Timing and frequency

+If you initiate a zone-redundancy [conversion](#customer-initiated-conversion) from the Azure portal, the conversion process could take up to 72 hours to begin. It could take longer to start if you [request a conversion by opening a support request](#support-initiated-conversion). If a customer-initiated conversion doesn't enter the "In Progress" status within 96 hours of initiating the request, submit a support request to Microsoft to determine why. To monitor the progress of a customer-initiated conversion, see [Monitoring customer-initiated conversion progress](#monitoring-customer-initiated-conversion-progress).

+> [!IMPORTANT]

+> There is no SLA for completion of a conversion. If you need more control over when a conversion begins and finishes, consider a [Manual migration](#manual-migration). Generally, the more data you have in your account, the longer it takes to replicate that data to other zones or regions.

+After a zone-redundancy conversion, you must wait at least 72 hours before changing the redundancy setting of the storage account again. The temporary hold allows background processes to complete before making another change, ensuring the consistency and integrity of the account. For example, going from LRS to GZRS is a two-step process. You must add zone redundancy in one operation, then add geo-redundancy in a second. After going from LRS to ZRS, you must wait at least 72 hours before going from ZRS to GZRS.

+## Costs associated with changing how data is replicated

+Azure Files offers several options for configuring replication. These options, ordered by least- to most-expensive, include:

+- LRS

+- ZRS

+- GRS

+- GZRS

+The costs associated with changing how data is replicated in your storage account depend on which [aspects of your redundancy configuration](#options-for-changing-the-replication-type) you change. A combination of data storage and egress bandwidth pricing determines the cost of making a change. For details on pricing, see [Azure Files Pricing page](https://azure.microsoft.com/pricing/details/storage/files/).

+If you add zone-redundancy in the primary region, there's no initial cost associated with making that conversion, but the ongoing data storage cost is higher due to the increased replication and storage space required.

+Geo-redundancy incurs an egress bandwidth charge at the time of the change because your entire storage account is being replicated to the secondary region. All subsequent writes to the primary region also incur egress bandwidth charges to replicate the write to the secondary region.

+If you remove geo-redundancy (change from GRS to LRS), there's no cost for making the change, but your replicated data is deleted from the secondary location.

+## See also

+- [Azure Files redundancy](files-redundancy.md)

+## Availability Zone

+Standard SKU Public IPs can be created as non-zonal, zonal, or zone-redundant in [regions that support availability zones](../../availability-zones/az-region.md). Basic SKU Public IPs do not have any zones and are created as non-zonal.

+A public IP's availability zone can't be changed after the public IP's creation.

+| Value | Behavior |

+| | |

+| Non-zonal | A non-zonal public IP address is placed into a zone for you by Azure and doesn't give a guarantee of redundancy. |

+| Zonal | A zonal IP is tied to a specific availability zone, and shares fate with the health of the zone. |

+| Zone-redundant | A zone-redundant IP is created in all zones for a region and can survive any single zone failure. |

+In regions without availability zones, all public IP addresses are created as nonzonal. Public IP addresses created in a region that is later upgraded to have availability zones remain non-zonal.

+> [!IMPORTANT]

+> We are updating Standard non-zonal IPs to be zone-redundant by default on a region by region basis. This means that in the following 12 regions, all IPs created (except zonal) are zone-redundant.

+> Region availability: Central Canada, Central Poland, Central Israel, Central France, Central Qatar, East Norway, Italy North, Sweden Central, South Africa North, South Brazil, West Central Germany, West US 2.