It doesn't seem that long ago when the DTU model was the only way of purchasing Azure SQL Database. In the last year Microsoft has announced some significant changes in the way we can buy it. Earlier in the year I blogged about the introduction of the vCore purchasing model, which provides greater control as well as the ability to leverage on-premises licenses under the Azure Hybrid Benefit for SQL Server. Earlier this month, Microsoft announced a new pricing option known as Azure SQL Database Reserved Capacity. In this blog post, we'll explore what it is as well as some considerations before you jump in.
What is Reserved Capacity for Azure SQL Database?
It's important to understand the term "Reserved Capacity". If you're unfamiliar with Azure Reserved Virtual Machine Instances (RIs), the idea of reserving capacity may be new and slightly misleading. You may think your workload will run on dedicated hardware with guaranteed performance. However, unfortunately it does not mean your workloads get dedicated vCores or compute - there is no capacity or performance benefit.
Reserved Capacity involves prepaying for Azure SQL Database vCores to benefit from significant discounts by making a 1 or 3-year upfront commitment (costs associated with storage, networking and software are not included). Reserved Capacity can be scoped to a specific subscription or shared across multiple subscriptions.
Customers can realise significant cost savings compared to standard pay-as-you-go (PAYG) rates over longer timeframes. When using Reserved Capacity, you're not charged at the PAYG rate (only when the commit period expires). Today, this new pricing option is available for single database or elastic pool deployments, availability for Managed Instances (MI) will come later - we assume once MI is generally available, later in 2018.
When making any kind of monetary commit in Azure, it's important to understand that you're making an upfront capital investment, which requires rigour in budgetary pre-planning. When purchasing Reserved Capacity for Azure SQL Database through the Azure Portal, you are billed upfront for the entire cost. For PAYG customers this means the chosen payment method on the subscription will be billed (e.g. credit card or invoice). Customers who have an EA and Azure commit, will see the Reserved Capacity charged as overage or consumption on the existing monetary commitment.
There’s a lot that might change in 12 or 36 months, which means it's important to understand the business' long-term plans before committing to a multi-year agreement. This purchasing vehicle works well where organisations have a solid roadmap and confidence in the lifetime and role of the data platform in the future. This is particularly relevant for organisations who plan to modernise a set of applications to use Azure SQL Database. Savings of up to 80% can also be achieved if Reserved Capacity is combined with Azure Hybrid Benefit for SQL Server. This benefit is provided exclusively to customers with active Software Assurance, allowing them to use existing on-premises licenses in Azure. This incentive means there is significant benefit for customers migrating on-premises SQL Server to Microsoft Azure, compared with other cloud providers. Additionally, there are more options to transform to an evergreen data platform, such as Azure SQL Database.
The Reserved Capacity billing mechanism works using a maximum number of vCores consumed. As such, Azure SQL Database workload consumption may exceed the Reserved Capacity, which will be billed in addition, using your Azure billing method. The chart below illustrates a customer with a Reserved Capacity of 16 vCores, who consumes vCores in excess of their Reserved Capacity (between points A and B marked on the chart). During this burst timeframe, the additional vCores will be billed in addition, using hourly billing.
Given the nature of the upfront investment, this additional usage and subsequent additional charges represents a balance between the upfront commitment and expected demand. Many organisations have seasonal characteristics where peak activity can be notably higher than the average workload. Coeo recommends workload analysis and demand modelling, the result of which is a demand model where reserved capacity is typically below peak demand. This allows customers to "burst", consuming additional vCores during peak periods and therefore avoiding under-utilised reserved capacity.
Microsoft announced the vCore purchasing model in April 2018, and it was only a matter of time before it extended the ability to reserve capacity through vCores. If you're only intending to deploy proof-of-concepts or tear-up/tear-down environments, you may find the DTU purchasing model is better suited. However, if you're intending to modernise strategic data platform workloads over time, Reserved Capacity will provide you with more flexibility and a cost-effective solution that will deliver significant savings in the long run.