A service that handles a quiet Tuesday may struggle during a holiday sale. Autoscaling adjusts resources as demand changes, helping maintain performance at busy times without keeping peak capacity running all the time. section 10.4.4 section 11.1.1
Scaling down is one possible change, but it is not the same thing as autoscaling. Making one virtual machine smaller is vertical scaling down; adding or removing machines is horizontal scaling. Autoscaling means those adjustments happen in response to workload or configured thresholds rather than requiring each change by hand. section 3.5.1 section 1.3.1
What changes depends on the Azure service:
- For Virtual Machine Scale Sets, estimate average and peak workloads, then set scaling thresholds and minimum and maximum instance counts. App Services also support autoscaling. section 1.3.1
- For Azure SQL Database, performance levels can rise with demand and fall when demand eases, reducing the need to scale the database manually. section 10.4.4
- For Azure Cosmos DB, throughput adjusts with workload up to a configured maximum. Set that limit explicitly: a default based on existing throughput might not suit either performance or budget. section 11.1.1
C:/> az cosmosdb update --name alpacacosmosdbaccount --resource-group AlpacaRG --capabilities EnableAutoScale --max-throughput 10000
This Azure CLI example enables Cosmos DB autoscaling and caps throughput at 10,000 request units per second. section 11.1.1
For a busy online shop, a Cosmos DB MongoDB collection can also use autoscale throughput with a specified maximum. The trade-off is worth watching: throughput can increase during a sales rush, and so can the bill. Check the limit against both the expected traffic and the budget. section 11.2.1 section 11.1.3
