|
1 | 1 | --- |
2 | | -title: Relocate Azure Functions to another region. |
3 | | -description: Learn how to relocate Azure Functions to a another region. |
4 | | -author: anaharris-ms |
5 | | -ms.author: anaharris |
6 | | -ms.date: 06/06/2024 |
| 2 | +title: Relocate Azure Functions app to another region |
| 3 | +description: Learn how to relocate Azure Functions to another region. |
| 4 | +ms.topic: how-to |
7 | 5 | ms.service: azure-functions |
8 | | -ms.topic: concept-article |
9 | | -ms.custom: |
10 | | - - subject-relocation |
11 | | -# Customer intent: As a cloud architect/engineer, I want to move my functions app to another region. |
| 6 | +author: anaharris |
| 7 | +ms.date: 07/15/2024 |
| 8 | +ms.custom: subject-relocation |
| 9 | +#Customer intent: As an Azure service administrator, I want to move my Azure Functions resources to another Azure region. |
12 | 10 | --- |
13 | 11 |
|
14 | | -# Relocate Azure Functions to another region |
| 12 | +# Relocate Azure Functions to another region |
| 13 | + |
| 14 | +This article describes how to move Azure Functions to another Azure region. |
| 15 | + |
| 16 | +[!INCLUDE [relocate-reasons](./includes/service-relocation-reason-include.md)] |
| 17 | + |
| 18 | +Azure Functions resources are region-specific and can't be moved across regions. Instead, you must create a copy of your existing function app resources in the target region, and then redeploy your functions code over to the new app. |
| 19 | + |
| 20 | +If minimal downtime is a requirement, consider running your function app in both regions to implement a disaster recovery architecture: |
| 21 | + |
| 22 | +- [Reliability in Azure Functions](../reliability/reliability-functions.md#cross-region-disaster-recovery-and-business-continuity) |
| 23 | + |
| 24 | + |
| 25 | +## Prerequisites |
| 26 | + |
| 27 | +- Make sure that the target region supports Azure Functions and any related service whose resources you want to move |
| 28 | +- Have access to the original source code for the functions you're migrating |
| 29 | + |
| 30 | +## Prepare |
| 31 | + |
| 32 | +Identify all the function app resources used on the source region, which may include the following: |
| 33 | + |
| 34 | +- Function app |
| 35 | +- [Hosting plan](../azure-functions/functions-scale.md#overview-of-plans) |
| 36 | +- [Deployment slots](../azure-functions/functions-deployment-slots.md) |
| 37 | +- [Custom domains purchased in Azure](../app-service/manage-custom-dns-buy-domain.md) |
| 38 | +- [TLS/SSL certificates and settings](../app-service/configure-ssl-certificate.md) |
| 39 | +- [Configured networking options](../azure-functions/functions-networking-options.md) |
| 40 | +- [Managed identities](../app-service/overview-managed-identity.md) |
| 41 | +- [Configured application settings](../azure-functions/functions-how-to-use-azure-function-app-settings.md) - users with the enough access can copy all the source application settings by using the Advanced Edit feature in the portal |
| 42 | +- [Scaling configurations](../azure-functions/functions-scale.md#scale) |
| 43 | + |
| 44 | +Your functions may connect to other resources by using triggers or bindings. For information on how to move those resources across regions, see the documentation for the respective services. |
| 45 | + |
| 46 | +You should be able to also [export a template from existing resources](../azure-resource-manager/templates/export-template-portal.md). |
| 47 | + |
| 48 | + |
| 49 | +## Plan |
| 50 | + |
| 51 | +This section is a planning checklist in the following areas: |
| 52 | + |
| 53 | +- State, Storage and downstream dependencies |
| 54 | +- Certificates |
| 55 | +- Configuration |
| 56 | +- VNet Connectivity / Custom Names / DNS |
| 57 | +- Identities |
| 58 | +- Service Endpoints |
| 59 | + |
| 60 | + |
| 61 | +### State, Storage and downstream dependencies |
| 62 | + |
| 63 | +- **Determine whether your Functions App is stateful or stateless.** Although its recommended that Functions (With the exception of Durable Functions) be stateless, and the files on the `%HOME%\site` drive should be only those required to run the deployed application and any temporary files, it's possible to store runtime application state on the `%HOME%\site` virtual drive. If your application writes state on the app shared storage path, make sure to plan how you are going to manage that state during a resource move. |
| 64 | + |
| 65 | + If the application uses Durable Functions, and particularly Durable Entities, the migration becomes much more application centric, and depends on the needs of the application itself. You must consider how to migrate entity state and how to reconcile the new entity state with the old service. This is particular the case, if you are doing anything more complex than a straight Active/Active + GRS Failover. |
| 66 | + |
| 67 | +### Certificates |
| 68 | + |
| 69 | +### Configuration |
| 70 | + |
| 71 | +### VNet Connectivity / Custom Names / DNS |
| 72 | + |
| 73 | +### Identities |
| 74 | + |
| 75 | + |
| 76 | + |
| 77 | +See [Relocation for App ] |
| 78 | +## Relocate |
| 79 | + |
| 80 | +If you have access to the deployment and automation resources that created the function app in the source region, re-run the same deployment steps in the target region to create and redeploy your app. |
| 81 | + |
| 82 | +If you only have access to the source code but not the deployment and automation resources you can deploy and configure the function app on the target region using any of the available [deployment technologies](functions-deployment-technologies.md) or using one of the [continuous deployment methods](functions-continuous-deployment.md). |
| 83 | + |
| 84 | +### Review configured resources |
| 85 | + |
| 86 | +Review and configure the resources identified in the [Prepare](#prepare) step above in the target region if they weren't configured during the deploy. |
| 87 | + |
| 88 | +### Relocation considerations |
| 89 | ++ If your deployment resources and automation doesn't create a function app, [create an app of the same type in a new hosting plan](functions-scale.md#overview-of-plans) in the target region |
| 90 | ++ Function app names are globally unique in Azure, so the app in the target region can't have the same name as the one in the source region |
| 91 | ++ References and application settings that connect your function app to dependencies need to be reviewed and, when needed, updated. For example, when you move a database that your functions call, you must also update the application settings or configuration to connect to the database in the target region. Some application settings such as the Application Insights instrumentation key or the Azure storage account used by the function app can be already be configured on the target region and do not need to be updated |
| 92 | ++ Remember to verify your configuration and test your functions in the target region |
| 93 | ++ If you had custom domain configured, [remap the domain name](../app-service/manage-custom-dns-migrate-domain.md#4-remap-the-active-dns-name) |
| 94 | ++ For Functions running on Dedicated plans also review the [App Service Migration Plan](../app-service/manage-move-across-regions.md) in case the plan is shared with web apps |
| 95 | + |
| 96 | +## Clean up |
| 97 | + |
| 98 | +After the move is complete, delete the function app and hosting plan from the source region. You pay for function apps in Premium or Dedicated plans, even when the app itself isn't running. |
| 99 | + |
| 100 | +## Next steps |
| 101 | + |
| 102 | ++ Review the [Azure Architecture Center](/azure/architecture/browse/?expanded=azure&products=azure-functions) for examples of Azure Functions running in multiple regions as part of more advanced solution architectures |
0 commit comments