Creating App Service Plans on specific deployment units

Over the last few years, Azure has rolled out a number of improved offerings in their V3 App Service plans, however these new SKUs are not available on every Deployment Unit within a region. MS therefore recommend that if you plan on using these new tiers, you should:

When creating the App Service plan, select a Premium V3 tier. This step ensures that the App Service plan is deployed into a deployment unit that supports Premium V3. Then, redeploy your application code into the newly created app. Even if you scale the App Service plan down to a lower tier to save costs, you can always scale back up to Premium V3 because the deployment unit supports it.

To ensure that app service plans I create can scale appropriately I’d like to be able to always create them using a P0v3 (if supported by the region) and then scale them to the desired size, as a “one shot” action, ideally as the service plan is initially created.

Forgetting to do this when initially creating the app service plan can lead to the resource being created on an older deployment unit, and leave the whole resource group unable to use the newer, more efficient (in terms of costs and resources) tiers.

As far as I understand, Terraform doesn’t support a “multi-step” approach, it has to be able to move from one state to another in a single step - which makes implementing this, and other related dependencies rather tricky to manage. Is there a way to achieve this via Terraform, or is terraform only any use for “achieving the current state, but not how we got there”.

I appreciate that this is a limitation caused by the platform being a little sporadic with how its features are available, but this is quite a combined limitation.

For example, in Bicep, I can create a resource, and then later on modify that resource with more information within the same deployment, either like above where I want to create an App Service Plan as a P3v0 and then scale down to an S1, or create an App Service, add that as a back-end to a new Front Door instance, and then update the original App Service with the details of the FrontDoorId so that it only accepts requests from the specific FrontDoorId.

That can all exist within a single, parameterised Bicep deployment, that I can run successfully to create environments as needed.

With the Terraform setup I can’t reuse the scripts to create a new environment because they need to be run multiple times with different settings to get things how they need to be.