29 January 2025 Azure Robert Muehsig

General

An Azure Resource Group is more or less one of the first things you need to create under your Azure subscription because most services need to be placed in an Azure Resource Group.

A resource group has a name and a region, and it feels just like a “folder,” but it’s (sadly) more complicated, and I want to showcase this with App Service Plans.

What is an App Service Plan?

If you run a Website/Web Service/Web API on Azure, one option would be Web Apps-Service.

If you are a traditional IIS developer, the “Web Apps-Service” is somewhat like a “Web Site” in IIS.

When you create a brand-new “Web Apps-Service,” you will need to create an “App Service Plan” as well.

The “App Service Plan” is the system that hosts your “Web App-Service.” The “App Service Plan” is also what actually costs you money, and you can host multiple “Web App-Services” under one “App Service Plan.”

All services need to be created in a resource group.

Recap

An “App Service Plan” can host multiple “Web App-Services.” The price is related to the instance count and the actual plan.

Here is a screenshot from one of our app plans:

x

So far, so good, right?

A few months later, we created another resource group in a different region with a new app plan and discovered that there were more plans to choose from:

x

Especially those memory-optimized plans (“P1mV3” etc.) are interesting for our product.

The problem

So we have two different “App Service Plans” in different resource groups, and one App Service Plan did not show the option for the memory-optimized plans.

This raises a simple question: Why and is there an easy way to fix it?

Things that won’t work

First, I created a new “App Service Plan” within the same resource group as the “old” “App Service Plan,” but this operation failed:

x

Then I tried to just move the existing “App Service Plan” to a new resource group, but even then, I could not change the SKU to the memory-optimized plan.

The “reason” & solution

After some frustration - since we had existing services and wanted to maintain our structure - I found this documentation site.

Scale up from an unsupported resource group and region combination

If your app runs in an App Service deployment where Premium V3 isn’t available, or if your app runs in a region that currently does not support Premium V3, you need to re-deploy your app to take advantage of Premium V3. Alternatively newer Premium V3 SKUs may not be available, in which case you also need to re-deploy your app to take advantage of newer SKUs within Premium V3. …

It seems the behavior is “as designed,” but I would say that the design is a hassle.

The documentation points out two options for this, but in the end, we will need to create a new app plan and recreate all “Web App-Services” in a new resource group.

Lessons learned?

At first glance, I thought that “resource groups” acted like folders, but underneath—depending on the region, subscription, and existing services within that resource group—some options might not be available.

Bummer, but hey… at least we learned something.


Written by Robert Muehsig

Software Developer - from Saxony, Germany - working on primedocs.io. Microsoft MVP & Web Geek.
Other Projects: KnowYourStack.com | ExpensiveMeeting | EinKofferVollerReisen.de