Scaling cloud resources dynamically is a fascinating topic. Microsoft Azure provide quite a few ways to dynamically scale resources. This article focuses on creating a scheduled vertical scaling (scaled up/down) of App Services. The approach outlined here can be used for other Azure resource like SQL Databases, Redis Cache or in fact pretty much most of the Azure resources that support scaling. Just to clarify right at the outset, we are talking about vertical scaling (between pricing tiers) and not horizontal scaling (scale in/out) wherein we deal with the number of instances at our disposal.

It is a common knowledge that Azure provides out-of-the-box options to scale out/ scale in based on the scaling rules for App Service plan but there is no way to scale up / scale down as per some schedule.

For instance, there is no direct way to say that between 10 AM and 12 Noon, let my App Service plan run on P2V2 and come back to P1V2 there after or have my SQL Server move up to P6 for a few hours before coming back to S2. In other words, no option to scale up/scale down based on schedule

Note on Serverless Azure SQL Database :- We have Serverless Azure SQL Databases with two key capabilities which make them attractive in terms of cost. 1. The option to auto scale up / down between the minimum and maximum threshold 2. Auto-pause — wherein the SQL Server is stopped after a predefined period of inactivity till some activity is detected again. You don’t get charged for the period of inactivity. The downside is that it will take some time of the SQL Server to warm up and be available for the next use after the period of inactivity. Serverless is best suited for test / dev environments where you have tolerance to the brief period of connection unavailability during the warm-up. There could also be slight performance degradation for sometime as the cache memory are gradually reclaimed. Serverless is not for your use case if these limitations are not acceptable. Furthermore, there are cases when although your usage will be limited for an interval you cannot afford to shut down the server using auto pause. Without auto pause you will be charged for the minimum number of vCores and minimum memory configured. For more details, refer to Microsoft documentation on Azure Serverless SQL Database

So, if your case is such that you will want to use DTU based provisioning and still want scaling based on a schedule as you have predictable utilisation, you can use the approach outlined in this article. One example that comes to my mind is bumping up your DTU for a few hours when you are doing a performance test or scaling down during a seasonal / weekend low utilisation to save costs.

Alright, now that we have context set, let us move on to see how we can achieve this scheduled vertical scaling for Azure resource in the following section

To start with, create an automation account. Details on how to create automation account can be found here. Azure Automation allows us to invoke runbooks as per a schedule. We will leverage this capability for our purpose. Please remember to select the option to create a RunAs account while creating the Automation account as shown below. This is the principle under with the runbooks can execute.

After the automation account is created, create two Runbooks which will be invoked by a scheduler to perform the scaling operation automatically without our intervention. These runbooks will contain PowerShell scripts to perform the scaling operation based on your need. (one for Scale up and another for Scale down) The fact that we use PowerShell to perform the scaling gives us the option to scale pretty much all resource for which you can get hold of PowerShell scripts to scale; and the best source for PowerShell reference is Microsoft’s official documentation.

Now that you have the automation account and the runbooks that you need, create a schedule and link these runbooks as per your need. (I won’t go into details on creating a schedule as it is very well documented and simple. Refer to Microsoft’s documentation on how to create a Schedule )

So, for instance, the below schedule will automatically call the “ScaleDown” runbook at 5:10 AM on 7th Feb

The below PowerShell script can be used to scale up / down an App Service Plan

Write-Output “API Scale”

$connectionName = “AzureRunAsConnection”
try {
$servicePrincipalConnection=Get-AutomationConnection -Name $connectionName

Add-AzureRmAccount -ServicePrincipal -TenantId $servicePrincipalConnection.TenantId -ApplicationId $servicePrincipalConnection.ApplicationId -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint

Set-AzureRmAppServicePlan -ResourceGroupName “«yourresourcegroup” -Name “«yourappserviceplanname” -Tier PremiumV2 -NumberofWorkers 2 -WorkerSize “Medium”}

catch {
if (!$servicePrincipalConnection){
$ErrorMessage = “Connection $connectionName not found.”
throw $ErrorMessage } else{
Write-Error -Message $_.Exception
throw $_.Exception
}}

In case you receive an error as below, go and update the PowerShell modules in your automation account. That should fix the issue

The term ‘Set-AzureRmAppServicePlan’ is not recognized as the name of a cmdlet, function, script file, or operable program.

Below, I have provided a sample PowerShell to scale a SQL database; it scales to database to P1 tier. This script uses a credential to perform the DB scaling as opposed to the AzureRunAsAccount in the previous PowerShell.

To create a new credential, navigate to your automation account and select the “Credentials” option in the “Shared Resources” section. Refer to the below screen shot showing the credential creation

param([parameter(Mandatory=$true)] [PSCredential] $Credential )

# Name of the Azure SQL Database server
[string] $SqlServerName = “yourserver.database.windows.net”

$Servercredential = New-Object System.Management.Automation.PSCredential($Credential.UserName, (($Credential).GetNetworkCredential().Password | ConvertTo-SecureString -asPlainText -Force))

$CTX = New-AzureSqlDatabaseServerContext -ServerName $SqlServerName -Credential $ServerCredential

[string] $DatabaseName = “yourdb”
[string] $Edition = “Premium”
[string] $PerfLevel = “P1”
$Db = Get-AzureSqlDatabase $CTX –DatabaseName $DatabaseName

Write-Output “Database Scale state " - $Db.ServiceObjectiveAssignementStateDescription

if($Db.ServiceObjectiveName -ne $PerfLevel -and $Db.ServiceObjectiveAssignementStateDescription -ne “Pending”){
$ServiceObjective = Get-AzureSqlDatabaseServiceObjective $CTX -ServiceObjectiveName $PerfLevel

# Set the new edition/performance level
#None, Business, Web, Premium, Basic, Standard”

Write-Output “Trigger the scale operation”
Set-AzureSqlDatabase $CTX –Database $Db –ServiceObjective $ServiceObjective –Edition $Edition -Force

Write-Output “Completed vertical scale”
}else{
Write-Output “The DB is already in the target pricing tier Or DB is currenlty being scale up / down”}

This same approach can be applied for other Azure resources also. Go on and try it out!

Happy Scaling!