The cloud is supposed to save you money, right? No infrastructure of your own to manage, a leaner IT staff on-site, etc. But running a production workload in the cloud can be costly — particularly if you’re configuring SQL Server for high availability (HA). In an HA scenario, where you’re expecting to have your SQL Server system available no less than 99.99% of the time, you encounter the cost of maintaining two or more instances of your SQL Server configuration in geographically separate data centers, but you may also incur costs you were not expecting (such as costs arising from the movement of data between the regional data centers if you’ve placed your failover infrastructure at a different region).

There are, however, ways to reduce some of the costs associated with configuring SQL Server for HA in the cloud — and not by piddling amounts.

Consider Your HA Architecture

How are you going to configure your SQL Server infrastructure for high availability? One difference between configuring on-premises and in the cloud is that, in the cloud, you can’t configure a windows failover cluster instance (FCI) using a shared storage area network (SAN) resource, which you might have done by default on-premises. In the cloud, you need to configure storage for each node in your FCI. Whether you’ll incur higher or lower costs for storage in the cloud remains a question complicated by many factors, and there is, as of yet, no consensus. What you really need to consider from a cost perspective is this: How will you replicate the data from your active SQL Server instance to the remote instances?

That’s a critical question because, in the event of a failover, the secondary instance of SQL Server that comes online will need a local copy of all of the data the primary instance had been using. It won’t be able to interact with the database attached to the primary instance, so it needs its own up-to-date copy. One thing to consider on this point is where your secondary instances of SQL Server are to run. If you configure your FCI nodes in different data centers within the same region, there’s no cost to replicating data between them. If you configure FCI nodes in different regions, you’ll find that your cloud provider charges you a fee to move data between regions. Plan your configuration accordingly.

Cutting Costs Related To Data Replication

With regard to the mechanism of data replication in a HA cloud configuration, you have basically two options. You can use the always-on availability groups (AGs) feature of SQL Server, or you can use a third party SANless cluster tool. Both approaches enable the synchronization of data between the active SQL Server system and the secondary systems, but they accomplish this in different ways and have distinctly different cost implications.

The AGs feature of SQL Server does a fine job of replicating user-defined databases, but that’s all it synchronizes. AGs leave certain key databases—including the master database (MSDB) and the database of agent jobs, logins, and passwords unsynchronized. These databases may not be crucial to the operation of the backup SQL Server instance in the short term, but long term, you’ll need them — particularly if you have to run on your secondary server for an extended period of time. Without copies of these other SQL databases on your secondary instances, you’ll be wanting to move back to the primary SQL Server instance as quickly as possible.

That’s a vulnerability cost, but AGs can also involve a significant financial cost. AGs require you to license the more expensive enterprise edition of SQL Server 2012 or later. If your workloads require only the standard edition of SQL Server (or still run on an earlier version of SQL Server), the requirement that you move to the enterprise edition of SQL Server just to take advantage of AGs for replication is going to increase your costs substantially. Remember that you’ll need an enterprise license for each CPU core supporting SQL Server.

The way to cut both the vulnerability and financial costs associated with an AG is to use a SANless clustering tool. SANless clustering tools are application agnostic; they simply replicate data at the block level between nodes. They’ll replicate all databases (and any other data) from the primary to the secondary infrastructures.

From a financial perspective, the real cost-cutting advantage of a SANless clustering tool lies in the fact that you can achieve your HA data synchronization goals without needing to deploy the more costly enterprise edition of SQL Server. Indeed, the ability to continue to use the standard edition  can reduce your licensing costs substantially. Consider: If you were to run standard edition SQL Server on a two-node failover cluster with four-core CPUs and a SANless clustering tool managing data synchronization, your total costs would be 58% lower than they would be if you were to run the enterprise edition on the same cluster with AG providing synchronization support. And the savings grow even greater as you increase the number of cores.

Consider your configuration options carefully. You need to address storage when configuring SQL Server for HA in the cloud. But there are ways to keep your costs in check if you know where to look.