Azure Functions
Arpio replicates Azure Function Apps and their associated resources, enabling serverless workloads to be restored in recovery environments. Function Apps share the same underlying resource type as Web Apps (Microsoft.Web/sites) and use the same App Service Plans, App Service and App Service Certificates documented in the App Service article.
Arpio replicates Azure Function Apps with their application code, app settings, connection strings, and authentication settings. Function Apps are identified by their kind field (e.g., functionapp, functionapp,linux) and follow the same replication approach as Web Apps with some differences in how code is backed up and deployed.
For standard Function Apps, Arpio backs up the deployed code via the Kudu API and restores it using zipdeploy. For Flex Consumption Function Apps, the deployment package is backed up directly from the deployment storage container and restored using the OneDeploy ARM API. The deployment storage account is automatically included as a dependency even if it differs from the standard AzureWebJobsStorage account.
Container-based Function Apps are also supported — container image references are translated to point at the recovery container registry. No code backup is performed for container-based apps since the code lives in the container image.
The following attributes are translated during replication:
| Attribute | Translation Method |
|---|---|
| App Service Plan | Reference translated to recovery App Service Plan |
| Virtual Network Subnet | Reference translated to recovery subnet |
| Key Vault Reference Identity | Translated to recovery user-assigned identity |
| Container Image (linuxFxVersion / windowsFxVersion) | ACR image references translated to recovery registry |
| ACR User Managed Identity | Translated to recovery user-assigned identity |
| IP Security Restriction Subnets | References translated to recovery subnets |
| SSL Certificate Resource IDs | Translated to recovery certificates |
| App Settings & Connection Strings | Resource IDs, Storage Account keys, and Key Vault URIs translated |
| Deployment Storage (Flex Consumption) | Storage account reference translated to recovery storage account |
The following resources are automatically selected into recovery points when a Function App is selected:
- App Service Plan hosting the Function App
- Virtual network subnets (for VNet integration and IP restrictions)
- User-assigned managed identities
- App Service Certificates bound to the site
- Container Registries and images (for container-based apps)
- Storage Accounts and Key Vaults referenced in app settings
- Deployment storage account (for Flex Consumption apps)
If your Function App has public access disabled, Arpio will deploy a private delegate that is able to access the Function App via an existing private endpoint. This delegate will be used by Arpio to back up and restore code and settings for the Function App.
After recovery, code deployment to private Function Apps occurs in a separate step after Private Endpoints are established in the recovery environment. Flex Consumption Function Apps are an exception — their code is deployed inline via the ARM API and does not require this separate step.
Flex Consumption Function Apps use a different deployment model where the application package is stored in a blob container rather than deployed via Kudu. Arpio detects Flex Consumption apps automatically and adjusts backup and restore accordingly:
- Backup: The deployment package is read directly from the storage container referenced in
functionAppConfig.deployment.storage - Restore: Code is deployed using the OneDeploy ARM API instead of Kudu zipdeploy
The deployment storage account is automatically included as a dependency even if it differs from the standard AzureWebJobsStorage account.
During recovery, Arpio restores custom hostname bindings. If DNS verification fails, Arpio surfaces a recovery issue titled Custom Domain Verification Required with the exact TXT record that needs to be added to your DNS (record type, host, and value). This issue is visible in the Arpio UI during the recovery operation.
During failover tests, -dr is appended to the default domain name to avoid conflicts with the primary environment.
Arpio replicates App Service Plans with their SKU, pricing tier, and worker configurations into the recovery environment.
The following attributes are translated during replication:
| Attribute | Translation Method |
|---|---|
| Hosting Environment Profile | Reference translated to recovery App Service Environment |
The following resources are automatically selected into recovery points when an App Service Plan is selected:
- Function Apps hosted on the plan
Arpio replicates App Service Certificates that are sourced from Key Vault or are Azure-managed free certificates. Key Vault certificates are recreated in recovery by referencing the translated Key Vault and secret name. Azure-managed free certificates are reprovisioned in recovery, which requires DNS domain validation.
Certificate-to-hostname bindings are restored with SNI SSL.
The following attributes are translated during replication:
| Attribute | Translation Method |
|---|---|
| Key Vault ID | Translated to recovery Key Vault |
| Server Farm ID | Translated to recovery App Service Plan |
- Uploaded PFX certificates cannot be recovered — Azure does not return the certificate blob or password via the API. These certificates must be manually re-uploaded after recovery.
- Azure-managed free certificates require DNS validation — recovery may require updating CNAME or A records to point to the recovered Function App before the certificate can be provisioned.
- Elastic Premium App Service Plans — worker size is dynamically assigned by Azure and may differ in recovery.
- Deployment slots are not currently supported; only the main site is replicated.