I may be completely off base here, but I’ve noticed a correlation between folks who use Amazon Web Services and their understanding that once you scale up a service during a busy business period, you can always scale back down again once the busy period is over. Perhaps that understanding is missing from the Azure side — or there’s a misconception about how to allocate resources to begin with — that mirrors on-premises implementations and force of habit.
So, consider this a public service announcement that it’s OK to scale down a service if you’re not using the resources right now. In fact, Azure bills you by the second, so if you’re able to reduce your service tier, you absolutely should.
When you buy hardware for your on-premises environment you spend a lot of money and time in planning how long that hardware will last you and how best to assign resources. You try and make sure the workload doesn’t consume all resources because it doesn’t allow for growth. That makes perfect sense.
With cloud computing, you’re renting time on someone else’s hardware, so you don’t really want to spec a system that matches your on-premises environment. On the contrary, you need to figure out what your usage is during an average workday and find a service tier that matches that average. Then if it gets busy you can scale up for that particular period of time, knowing that you will be able to scale back down again when it gets less busy.
Remember, the promise of Azure SQL Database (and Managed Instance) is a fully managed service that takes a number of tasks off your hands (backups, maintenance, and a fair amount of tuning too).
Don’t feel like your CPU needs to run at 15% all day. If it’s at 80% or higher then you’ve picked the right service tier. Skate that edge and save yourself some money in the process.
Share your thoughts in the comments below.