Azure Virtual Machines: Were you aware of the MAJOR caveat to their SLA?

I think this is important to many Azure customers, but very few seem to be aware of it.  So, I decided to record this caveat into a blog post, for future ease of reference.

Most people think of the cloud as a great way to provide up-time to applications without a large investment in hardware (such as a SAN).  Well, that is true. Microsoft’s Azure, for example, has a 99.95% uptime guarantee at the time of this writing.  From their website:

However, in order to actually be covered by this SLA, your configuration will need to meet certain requirements.  In order to understand those requirements, you will need to understand Availability Sets.  From the same website:

An “availability set” refers to two or more Virtual Machines deployed across different Fault Domains to avoid a single point of failure.

What is important to note here is that Azure virtual machines are NOT by default highly available (they will not fail over between fault domains such as power loss to a host server, storage connectivity loss, etc).

In order to make them effectively HA, and protect them against various outage scenarios, you will need to define an “Availability Set” inside of your Azure service portal, and then deploy “two or more” virtual machines into that availability set.

The function of the availability set in Azure is simple: it means “do not place these these two virtual machines into the same fault domains” (they can’t be on the same spindles, hosts, etc.–probably cannot be located within the same rack in the datacenter).

In case you haven’t translated this into financial terms yet, let me do it for you. What this means is, to qualify for the up-time guarantee, you need to spend 2x what you thought you were going to spend.  “Ooops!  You mean you didn’t get that memo?” You can see why customers who got started with single virtual machines were later disappointed.

Comparing costs with on-premises hardware or co-location

Here is how I would compare Azure costs to doing on-premises or co-location deployments.

For highly available (HA) workloads: Price out 2x virtual machines, and 2x the storage requirements. They will be deployed into the same virtual network, so you only need one virtual network connection. Compare this cost against a co-location of 2x host servers attached to a dual-controller SAS-connected shared storage device, with a fail-over switching stack and appropriate dual source power protection.

For workloads that do not need to be protected by HA: Use single virtual machines (not in an availability set), and compare that cost to hosting a single host server with local storage and standard switching & power protection (UPS).

Suggested use cases

Based on today’s pricing tiers, here’s my take. For development purposes, and smaller-sized production workloads, Azure is still a pretty great way to provide infrastructure quickly and at low cost. However, when you start talking about high availability for virtual machines running MSSQL, then lighting up other supporting domain infrastructure, deploying RDS and so forth on top of that, then it starts to get a little scary. Buying your own hardware, even with a co-location, is still looking pretty good in most cases.

I think an excellent SMB use case for Azure virtual machines is to connect your existing local infrastructure via a VPN tunnel to an Azure virtual network, deploy a backup domain controller and turn on DFS replication for your file shares. Very quickly, you can have some site redundancy for important directory information and file share data. You could even enable an Azure backup vault for that virtual machine to boot, and this can all be done very inexpensively–probably less than a couple hundred dollars (US) per month for many SMB’s.

Now let’s say you later acquire a new line of business application, or you upgrade an existing one, but instead of getting new hardware for it, you decide to deploy a virtual machine on the same virtual network in the cloud.  This can be done for another $200 USD (before backup) give or take, for example with a D2 VM (2 cores, 7 GB RAM).  Just be aware that this workload will not be subject to a much better (or worse for that matter) up-time guarantee than what you were getting on that standalone server in your office closet.

For more on pricing, visit the Azure pricing page.