Microsoft SQL server in Azure versus AWS

Microsoft SQL (SQL) runs on all clouds, and in this article, we will specifically discuss the two leading cloud providers – Amazon AWS and Microsoft Azure.
We are going to highlight the main points to consider for an IT executive or professional needing to decide between running their Microsoft SQL databases in Azure SQL Database Platform as a Service (PaaS) offering versus that of Amazon AWS RDS.
We won’t discuss IaaS, since the cost performance will rely on a lot of factors and customizations that will vary from install to install. In the absence of compelling reasons not to migrate to PaaS; IaaS comes with resource management burden that adds to the overall cost. But even in this case, Azure comes with extra benefits where installing the SQL agent extension in your SQL box will “PaaS-ify” your server by adding features such as automated backup and patching, flexible licensing, etc…
I must admit that I am biased since I work for Microsoft; nevertheless, what I write about in my blog is strictly my opinion and my interpretation of articles and studies I have read as well as my years of experience working with products and services in both clouds.
For folks that don’t have time and want to get to the verdict without having to read the whole article, I would strongly advise that they consider running their “significant” Microsoft SQL workload in Azure if they are in the process of selecting a cloud vendor. For enterprises that moved most of their workloads to AWS, they should consider a multi cloud strategy since the cost performance rewards they will achieve will make up for the extra effort to enable an additional cloud in terms of networking, connectivity, reskilling, and app colocation requirements. The reasons will be discussed below, and we will link to articles and studies to support our decision. Mainly, In Azure you have the rights to use your maintained licenses in PaaS whereas you can only use them in AWS IaaS. Your Azure PaaS is highly available and offers better SLA than AWS. Your compute cost in Azure PaaS is much lower than in AWS.
A major point to consider is that Microsoft owns the product and is constantly updating it and innovating in both the cloud PaaS offering which contains the latest bits, and the on premises offering, SQL server 2022, which is touted as Cloud-enabled.
Time to go over the details of the benefits of running MS SQL on Azure. The first benefit is Licensing! Your investments in acquiring SQL licenses and your diligence in paying yearly maintenance will pay off if you move your on-premises or other cloud SQL workload to Azure PaaS. You will get all the benefits of PaaS while paying only for compute. You cannot do that in AWS RDS, you will have to lease those licenses from amazon.
This might not be important for a small Microsoft SQL workload that you are planning to phase out eventually in favor of an OSS database, but worth looking into if your Microsoft SQL footprint is significant and long term.
It’s noteworthy to mention that Azure SQL PaaS does support PostgreSQL, MariaDB, and MYSQL.
Let’s look at Licensing benefits details:

Azure SQL Hybrid Benefits

If you have stopped paying for SA (Software Assurance)/ maintenance on your licenses, and you still want to move to the cloud, you will get the same benefits from both clouds if you use license mobility in AWS, and hybrid benefits in Azure by moving those databases to a dedicated host. Even in the case where you don’t have licenses to move over to the cloud either because it’s a new workload, or an existing one with licenses where SA is not maintained, we will show that Azure is still more cost effective.

The Azure SQL database is built with high availability and has a better SLA than that of AWS. Since Azure SQL Managed Instance (MI) is the most comparable to that of AWS RDS, we will compare their SLAs. AWS only offers 2 9s for a single DB instance, and 3 9s for a Multi AZ DB instance. Azure SQL MI offers an SLA of 4 9s. So why is the SLA low in a single DB instance in AWS? The answer is straight forward, it is only a single instance that is not using Microsoft SQL high availability technology, namely Always on.

Amazon RDS supports Multi-AZ deployments for Microsoft SQL Server by using either SQL Server Database Mirroring (DBM) or Always On Availability Groups (AGs)”

For better availability, you need to use Multi AZ deployment in AWS, which unfortunately doubles your cost, and still doesn’t get you 4 99s SLA that Azure offers.

Because Azure SQL MI has two tiers, General purpose, and Business critical, it’s best to compare AWS RDS Multi AZ to Azure SQL Business critical since they both use some flavor of Always on with read replicas. After that comparison is done, and you appreciate the superior cost performance in Azure, then you can evaluate Azure SQL MI general purpose which might be enough performance for your needs and is cheaper than Business Critical. General purpose is not available in AWS, so we can’t use it in our comparison.
A quick pricing exercise will reveal the cost benefits of running SQL server in Azure versus AWS PaaS. In the Azure pricing calculator, you will have options to use Azure hybrid benefits if you own licenses and are current with SA. In both AWS and Azure calculators, you can see the savings attained by reserving compute.
For a detailed look at cost performance, check out this study conducted by Principled Technologies and sponsored by Microsoft.
In summary, the study found:

“Azure SQL Managed Instance significantly outperformed Amazon RDS. Offering between double and five times the performance depending on the workload, the three SQL Managed Instances we tested also offered better overall value, reducing price/performance by as much as 90.3 percent”

The study is well documented and replicable, and the savings are high. If you are wary of vendor sponsored studies, then spend the time reading their methods of comparison, and go ahead and run a pilot in both clouds to explore those results with your database team. You can request assistance from both your Azure and AWS sales teams and ask about potential funding of full or partial cost. If Principled technologies AWS RDS configuration is not optimal, you can change it and follow best practices from AWS.

The savings of running Microsoft SQL in Azure versus AWS or other clouds is significant enough to warrant considering a multi cloud strategy. As you move your SQL to Azure, you will find that other services in the Azure Data estate are also competitive or superior, and thus your investments in enabling multi cloud will be well worth it. Azure Synapse Analytics versus Redshift, Power BI versus QuickSight, Azure machine learning Service versus SageMaker would be good comparisons to make to support your decision to move to Azure. You will find that the Azure services are very competitive, integrated with AD, built with layers of security, very intuitive as they offer a GUI based option, and versatile for users that prefer a code first approach. For the latter users, they will enjoy the solid integration of VS Code IDE with Azure.

For Companies that are still deciding which cloud to move to and have a significant Microsoft SQL workload on premises, moving to Azure should be your first consideration. To cement your decision, use every resource you have available from your sales team to help you with funding POCs, learning about different services, and skilling your enterprise.

Connect to Azure SQL Database Read Only Replica from SSMS

This is a quick blog post that shows how to connect to a read scale out replica in Azure SQL database business critical tier.
When you create the database in the Azure portal enable Read scale out. You can change this setting in the configure blade as needed. If you don’t have access to the portal, there are several methods to accomplish this task programmatically by following this doc.

To connect to the read replica with SSMS, enter your login information, then click on the “Additional Connection Parameters” tab and add the following param: “ApplicationIntent=ReadOnly”

To check if you are connected to the read replica, you can simply try to create a table, and you would get an error such as the following:

You can also run this query to find out if your database is ready only: