SQL Server is the most common product that customers are bringing to AWS in a bring-your-own license model. With that, it’s also one of the most expensive licenses that Microsoft has to offer. In this guide we give you 8 tips on how to optimize your existing SQL Server licenses to get the most out of them when migrating to AWS.
The first tip is to optimize your CPUs. Normally SQL workloads are memory bound, but SQL licensing is CPU bound. The pitfall here is that a lot of times we choose instances that have a big CPU:Memory ratio when that is not necessary. So, what is an optimized CPU for SQL?
Let’s set the stage with an example: you have your SQL Server that has optimal performance with 128GB of memory. To accommodate that, you are likely to use an extra large instance or bigger, which in this example has 8 cores and 16 vCPUs. If you monitor your instance and look at the usage pattern in this situation, you will likely notice that your memory consumption is higher than your CPU at all times. Not only that, but your memory is often fully consumed, whereas your CPU is around 50% consumption at the same time.
Nonetheless you still need to pay for the SQL licenses for all the 16 vCPUs. That happens because SQL Server is licensed per core, so it does not matter if you are utilizing all of them or not, only that they are available. It can be worse if you have a secondary instance for fail over and you do not have Software Assurance. Then you need to pay double on an unoptimized scenario.
However, when launching your EC2 instance, you can specify how many cores are visible to the operating system. This allows you to decide for yourself whether you want to disable hyper threading. Meaning that instead of 16 vCPUs, you can make only eight vCPUs visible to the OS. And in this case you will only need to bring eight SQL server licenses to this instance.
It will not affect pricing for the instance, because it will be the same instance. It will also not affect the pricing of Windows on this instance, but it will affect the number of SQL Server cores that you have to bring in order to be compliant. This is what we call an optimized CPU.
The next optimization tip is to consolidate SQL workloads that have small CPU requirements. That is because currently you must license at least four virtual CPUs when using virtualized environments, even if you are not using threading. If your workload is small and does not require a lot of CPU power, you would normally pick an instance that aligns with that. But if that instance has less than four vCPUs, you will still need to assign four licenses to it. Therefore, it would be more efficient from a licensing perspective to consolidate your workloads in such a way that the necessary amount of vCPUs is a multiple of 4.
In a nutshell, when you license SQL servers on EC2, rightsize them to license in batches of four vCPUs.
Consider using dedicated hosts, as they will give you visibility into physical cores. Take an r5 instance for example. This instance type is memory optimized and very suitable for SQL workloads. The dedicated host version of the r5 (r5.metal) has 48 physical cores, each allowing you to use threading to have a total 96 vCPUs. That is the same amount that an r5.24xlarge has. The difference here is that the dedicated host is not considered a virtual environment and you can license for 48 cores against 96 vCPUs. If you have enough workloads to fill a dedicated host, consider using them, but take into account the characteristics of this kind of tenancy, especially with regards to pricing.
The next tip is a SQL server Passive Failover. This means that besides your active SQL server instance you would also have a passive SQL server instance for failover if the primary instance fails.
Starting from SQL Server 2014, if you have active software assurance, then you don’t need to pay for SQL server licenses on a passive instance. You only need to license the active one. You still need to pay for the instance, for Windows license on compute, but you don’t need to pay for SQL server licenses on the passive instance. But again, you need to have active software assurance in order to have this benefit.
Our next tip is to step down with SQL server from the Enterprise edition to the standard edition. The cost of the Enterprise edition is much higher than the cost of the standard edition. We advise you to first really try to understand what enterprise features are actually being used in your organization.
If it’s only used for high availability, and you don’t use it for Read Replicas for example, then you can step down to the standard edition. And instead of always on availability groups, you can use failover cluster instances using FsX for example. You can lower the cost on the license significantly when you switch from the enterprise edition to the standard edition.
The next topic is disaster recovery. We mentioned that if you have a Software Assurance you do not need a SQL license for your passive instance. So, you have your active instance and you have your passive instance for failover, but what if you also have disaster recovery requirements?
What if you need one more instance in a different region just for disaster recovery purposes? Well, even with Software Assurance, that DR instance would need to be licensed for SQL. But for disaster recovery you can just use -block replication on the storage level. You don’t need to pay for the SQL license on that instance.
SQL Server Developer Edition: you can bring it to either dedicated tenancy or on shared tenancy. If you have non-production workloads used for development or testing purposes, then you can use SQL Server Developer Edition, which is free.
When you assess your environment, just check if you have servers not being used in production and that have any paid SQL workload. Then consider using SQL server developer edition.
The last tip on SQL Server licenses is that you can run SQL Server on Linux. You will still need to pay for SQL Server licenses, but you can eliminate the cost of the underlying Windows servers license costs. Compatibility is nearly on pair, but there can be a few differences, such as the access to the file system. Just like on tip number 5, it is important to check the real needs and requirements of your environment, but if your workload is dependent on SQL Server, you can consider running SQL server on Linux.
To help you get insights into your savings potential, AWS has introduced the AWS Optimization and Licensing Assessment (OLA). By assessing the consumption cost and provisioning of your Microsoft workloads using the AWS OLA, you can more accurately scope how to optimize them on the cloud. Analysis of the data gathered by the AWS OLA helps you more effectively model costs and determine the best business optimization scenarios to fuel sustained growth.