Issues encountered and workarounds
There are a whole host of reasons why you may want to change the App Service Plan for your App Service.
In App Service (Web Apps, API Apps, or Mobile Apps), an app always runs in an App Service plan. In addition, Azure Functions also has the option of running in an App Service plan. An App Service plan defines a set of compute resources for a web app to run.
One reason maybe that you want to benefit from features in your app service that require an upgraded plan, such as ‘Always On’ in the portal. Another reason maybe to consolidate your app services under a single plan to keep costs down, particularly where bandwidth consumption is fairly low.
Below is a feature that was required, for this blog, which runs as an Azure App Service over Azure CDN, utilising the 'Always On' configuration setting in the Azure portal. This requires an App Service Plan of at least the 'Standard' pricing tier of machine resource capabilities.
Azure will always keep an instance of the Web App running at all times. This way when a user / client hits the Azure Front Door endpoint, the backend Web App will always be ready to respond to that request without timing out
The Problem
Soon ran across an immediate issue. After selecting Change App Service Plan, couldn't see the App Service Plan that exists in the same Region and Resource Group that is already being used for another running app service?
It turns out that there are 3 factors that need to align in order for this to work.
-
Same physical location (Region: West Europe)
-
Same resource group (Resource Group: wbg-weu)
-
Same webspace (deployment unit)
Azure deploys each new App Service plan into a deployment unit, internally called a webspace. Each region can have many webspaces, but your app can only move between plans that are created in the same webspace. An App Service Environment is an isolated webspace, so apps can be moved between plans in the same App Service Environment, but not between plans in different App Service Environments.
The problem is further compounded as you cannot specify the webspace you would like to use when creating a plan, but it’s possible to ensure that a plan is created in the same webspace as an existing plan.
In short, all plans created with the same resource group and region combination are automatically deployed into the same webspace.
But in my case, the blog app service was not originally created in the same region and resource group combination, as i set it up initially on a free plan without really knowing at that point if i would even continue using it let alone want start paying for it.
Additionally, plans can’t move webspaces after they’re created, so you can’t move a plan into “the same webspace” as another plan by moving it to another resource group, which is exactly what i initially attempted to do, resulting in a successful move but without the desired App Service Plan being available for selection.
A Workable Solution
Of course just creating a new App Service Plan would have solved the problem immediately and all would have worked as expected, with the penalty of the additional cost, which would have defeated the purpose.
The region in which the app runs is the region of the App Service plan it's in. However, you cannot change an App Service plan's region. If you want to run your app in a different region, one alternative is app cloning. Cloning makes a copy of your app in a new or existing App Service plan in any region.
You can find Clone App in the Development Tools section of the menu.
The first step is to temporarily upgrade the current plan to be able to utilise the clone feature as prompted, if required.
Then the Clone App blade will appear enabling you to enter a new name for the target application, along with, the target resource group and App Service Plan/deployment (unit) location: AKA webspace.
This is the magic required for the app to be placed inside the same webspace.
Allow the validation to complete to avoid any errors further down the line as shown below
Select Create
Monitor the deployment progress
After a couple of minutes the clone completes and the Activity Log for the resource group indicates the steps that have taken place including validation of the deployment and backup of the website.
Once the clone has completed, the expected App Service Plan will be available for selection.
Worth noting, Cloning does have some limitations. Mainly around more complex configuration and security. However all cloned as expected, including database, in our case but comparing and re-applying some configuration shoudln't be too problematic. Definitely worth keeping the source app around until the newly cloned application has been fully tested. Link below for the official docs around Azure App Service App cloning.
Conclusion
Managing App Service Plans effectively can mean significant cost savings and it is worth reviewing your resources as a whole on a fairly regular basis to ensure you are getting the best out of your environment setups.
Keeping services in the same resource group and location has always been a best practice in terms of efficiency and reducing latency incurred having to traverse physical locations and servers and this article has helped uncover another consideration, that of the webspace. When you are ready to create your deployment scripts or manually provisioning your infrastructure as code or otherwise, it is worth ensuring the App Service Plan is a key consideration as it is tied to a unique webspace, which does not change once provisioned.
Utilising the clone feature, under the Development section in the portal is one way of creating a copy and being able to benefit from an already created App Service and App Service Plan without too much added pain.
Also, don't forget to remove the temporary plan created or any other resources not required, including the old version you used to perform the clone, once you have tested the newly cloned app Service is performing as expected.
References
