An Azure App Service Plan is pinned to a specific Azure Region. Any App Service Apps created in the App Service Plan will be provisioned in that same region. If your app needs additional redundancies in other regions or geographies, you'll have to:
- Provision them yourself (you'll need to create new App Service Plans in those regions, if they don't already exist).
- Use Azure Traffic Manager to route traffic to all available redundancies (you can only specify one App Service endpoint per region in a Traffic Manager profile). More details here.
The SLA for Azure App Services guarantee a 99.95% uptime for each regional deployment.
Azure Function Apps too have regional deployments. If you're using the consumption plan, then you explicitly specify the region. If on the App Service Plan, then the region is the same as that of the App Service Plan.
Similar to App Services above, any additional redundancies will have to be explicitly created and traffic to these will have to be routed via Azure Traffic Manager.
The SLA for Azure Functions guarantee a 99.95% uptime for each regional deployment (for both app service plan and consumption plan).
As I've previously mentioned, horizontal auto-scaling exists to address performance concerns rather than high-availability concerns.
App Service Apps: When horizontal auto-scaling is enabled on a parent App Service Plan, additional instances are created, and each instance hosts all App Service Apps contained in the parent App Service Plan. All instances are created in the same WebSpace. The App Service's integrated load-balancer (non-accessible) manages the traffic. Note that all scaled out instances of an app will still have the same endpoint URL.
Function Apps: Based on a combination of factors (trigger types, rate of incoming requests, language/runtime and perhaps the host health-monitor stats), the scale controller will create additional instances of an Azure Function App (max limit of 200 instances). Note that the scaling unit is the Function App (host) itself and not individual functions.
- Read more about the scaling limits imposed on App Service Apps based on pricing tiers.
- Read more about ARR affinity and ARRAffinity cookies for scaled out instances.
- You can now enable per-app horizontal scaling. More details in this blog post.
- Read more about the scaling behavior of Function Apps.
If you have an App Service App or a Function App associated with an App Service Plan in the production or isolated tier, then you should consider enabling the "always on" setting. This ensures that your app is always running and never unloaded (default behavior is to deactivate/unload idle apps to conserve resources).
- This setting is not available for App Service Apps in dev/test tier.
- Idle Function Apps in the consumption plan will be subject to cold start latency.
You can also move an App Service App to another App Service plan as long as both the source plan and the destination plan are within the same WebSpace.
FWIW, I've never tried this out myself.
And yes, like any other Azure Resource, App Service Plans and App Service Apps can be moved between resource groups.
WebSpaces are units of deployment for Azure App Service Plans. An App Service Plan's WebSpace is identified by the combination of its resource group and the region in its deployed. Any additional App Service Plan deployments to the same resource group + region combination gets assigned to the same WebSpace. See more details here.
To see the WebSpace associated with an App Service App or App Service Plan, navigate to that resource in the Azure Resource Explorer (via the Azure Portal or via the website) and see the