Most of us who already experimented with Sitecore 8.2 Update 1 running on Web Apps have noticed that the default provisioning consumes quite some Azure credits. A bit too much maybe, at least for Research & Development purposes. So, to save some costs, I started looking into downscaling options. Of course, you can simply provision a CM-only seat, but that won’t allow you to play around with the full functionality of the XP version. Alternatively you can alter the ARM templates provided by Sitecore to use cheaper pricing tiers, but for the sake of creating a representative test environment compared to your production version, I’d rather not touch the ARM templates. As with compiled code, we want to use the exact same artifact for all environments or publishing targets.

One last option is to scale down the most expensive resources after the initial provisioning. And that’s exactly what I am going to do. You can do this manually, but we want to automate all the things, right?

You can download the complete PowerShell script written for this blog on the Sitecore-Azure-Scripts repository of my GitHub account.

A powerful PowerShell script

When working with Azure, you’ll soon learn how powerful and easy the Azure CmdLets are. In a very short time I have written a reusable and configurable script to perform this task fully automatically.

So the idea of this script is, that you can use it to scale up or down after provisioning with the same ARM templates for test, acceptance and production, while handling the ARM templates as a fixed asset / artifact for all environments. Of course, the ARM templates of Sitecore are a starting point and you wouldn’t use them in production straight away – so if you alter these templates and scripts, you should alter this scaling script accordingly.

The layout of the script is a lot like the script provided by Sitecore, used for the ARM deployment. It contains the option to use a Service Principle for automatic authentication, but if left out, you can login into your Azure subscription manually after running the PowerShell script. But before doing so, you need to fill in the name of the resource group and the ID of your Azure Subscription. Actually, you can just copy these fields from the other PowerShell script, or extend the original script with the commands below, for they use the exact same variable names:

Sizing configuration

You can leave the values of the following variables default, as they scale the environment down exactly as described in this blog post. However, you can always alter these values to your own liking or even use this script to scale up your freshly provisioned Sitecore environment when running in production. For now, we’ll start using these values:

Once all variables are set, we can now move on to the actual scaling tasks.

From two to one SQL server

The XP ARM template places your Azure SQL web database in a separate SQL server. Which is a very charming security measure. But when just playing around or for testing purposes, one SQL server would suffice. Easier to maintain and less resources. We can easily achieve this by copying the web database from one server to another and deleting the now superfluous SQL server instance:

Scaling down Azure SQL databases

The Azure SQL databases are actually the most expensive assets in the whole setup. So we will tune them back from a Standard S1 pricing tier to the Standard S0 tier. You will probably experience some performance degradation when going back from 20 to 10 DTUs, but when only validating the provisioning and deployment mechanism itself you won’t notice this. And for testing purposes you can also choose to leave out the master database in this script so it will stay on S1 and the Sitecore Client won’t slow down.

I have written a simple loop that goes through the different databases (now all hosted on the same SQL server), scaling down the database Edition and Service Objective, which make up the pricing tier together:

So, not suitable for production, but for testing purposes this is a great cost saving going from 25.30 to 12.65 EUR/MONTH per database at the time of writing.

Scaling down App Service plans

The hosting or App Service plans for all the different Sitecore server roles (like Content Management, Content Delivery, Reporting and Processing) can be scaled down from the Standard S1 pricing tier to the Basic B1 App Service plan. The performance of those tiers is equal and we only sacrifice storage, going from 50 GB to 10 GB, but that’s still more than enough for most Sitecore implementations. The only real limitations come with losing the SSL option and having less outscaling options, but for testing purposes, this will do just fine.

I have written a simple loop that goes through the different hosting plans and scales them down to the tier configured earlier:

This will change the estimated monthly costs from 62.74 to 47.06 EUR/MONTH per hosting plan at the time of writing this blog post. And mind we have four of them in the XP setup.

The result

By running this simple PowerShell script right after provisioning your Sitecore environment on Azure Web Apps,

we have saved a generous amount of 113.32 EUR/MONTH

I think that’s worth it, isn’t it? So now you can even get more out of your monthly Azure credits!