Virtual machines (VMs) in Azure are fantastic. They are considered “Infrastructure as a Service” (IaaS) and can implement production workloads, dev/test environments, and as learning/sandbox areas.  For instance, with SQL Server 2016 having so many new features, it’s great to be able to fire up a VM quickly, stop it when I’m not using it, and delete it when I’m done with it.

As more and more customers are interested in moving some portion of their BI/analytics workloads to cloud services, one question that comes up occasionally is whether or not you should start with a marketplace image that has SQL Server already installed. So far I’ve noted a few key considerations for this decision:

1. Do you want to pay for the SQL Server license as part of the VM pricing?
2. Do you want to configure SQL Server in a specific way (i.e., following best practices)?
3. Do you want Azure to handle things like automated patching by default?

What is an Azure Marketplace VM Image?

The Azure Marketplace is also sometimes called the Azure Gallery. It’s an “online store” with a ton of predefined solutions including VM images to use as starting points. When you click the Add button to create a new virtual machine, you find there’s a wide variety of predefined images to choose from:

For instance, if you do a search for SQL Server 2016, you’ll see a few choices of images which have SQL Server pre-installed:

Following are a few considerations regarding if you want to utilize a pre-built image for SQL Server.

Pricing of Virtual Machine

Let’s say you already own SQL Server licenses, potentially with Software Assurance. In this case you probably do not want to pay for SQL Server as part of the VM pricing. 

Below is example pricing for a small-ish A6 Windows machine (in reality, a D series is recommended for running SQL Server). Using a Windows image means you would install SQL Server yourself which would be considered a “bring your own license” type of situation for SQL Server:

Example of a SQL Server machine which includes a SQL Server Standard license:

Example of a SQL Server machine which includes a SQL Server Enterprise license:

You can find the pricing calculator here:  https://azure.microsoft.com/en-us/pricing/calculator/. Obviously the above screen shots show retail pricing, but it makes the point that there’s a difference in pricing with a base Windows machine vs a SQL Server VM. Do keep in mind that you only pay the licensing costs for each individual hour that the VM is running. This Azure article discusses pricing considerations a bit further.

At this point in time (April 2016), if you want to apply your own license, the way to do that is to use a Windows image and install SQL Server yourself or transfer a VHD. (Be sure to verify it’s still true if you’re reading this too far in the future.) Having said that, there’s other reasons you may want to install SQL Server yourself anyway…

Setting Up SQL Server in an Azure VM Using Best Practices

If you are a DBA with specific ideas about how things should be set up (as well you should), then you’ll most likely lean towards a Windows image and install/configure SQL Server yourself. With the most recent SQL Server images I’ve used, the DB defaults to installing data and logs both on F:\, and TempDB is on C:\. The allocation unit size is also set to 4096. I could go on but you get the picture (I’m a BI developer, not a DBA, so I’m not even going to try to enumerate what I think should or shouldn’t change from the built-in SQL Server image). Now of course a seasoned DBA can go in afterwards and reconfigure some things, but the message here is that the SQL Server images aren’t pre-configured based on commonly held best practices. For a less experienced DBA, this could potentially lead to performance concerns later.

Here you can find Performance Best Practices for SQL Server in Azure Virtual Machines. 

Control Over Patching of SQL Server and Windows

The recent SQL Server images I’ve seen have automated patching by default, which includes both Windows and SQL Server.