Back on February, 1st 2010, Microsoft announced the general availability of the Windows Azure Platform in 21 countries. Since then the Windows Azure cloud journey has continued at a rapid pace. As those of you following the official Windows Azure team blog already know, Microsoft is constantly improving the service by introducing new features, flexibility and support while at the same time reducing the prices for compute power making the service even more attractive compared to the competitors in this space. At least for specific scenarios as we will talk about later.
Exchange Servers in Microsoft Azure IaaS – The Past
Microsoft Azure delivers a 99.95 % monthly SLA and can be used for many different purposes and scenarios. From the “What is Windows Azure?” site:
“Windows Azure is an open and flexible cloud platform that enables you to quickly build, deploy and manage applications across a global network of Microsoft-managed datacenters. You can build applications using any language, tool or framework. And you can integrate your public cloud applications with your existing IT environment.”
While the Microsoft Azure platform is truly production ready for most servers, applications and products (see this KB article for Microsoft servers and roles that currently are supported), there are certain products that were not supported on Microsoft Azure IaaS based virtual machines from the beginning. One of them was Exchange Server. So while it is supported to run Exchange Servers on Hyper-V and Server Virtualization Validation Program (SVVP) validated products such as VMware, this did not apply to virtual machines running in Microsoft Azure IaaS. At the same time competitors to Microsoft Azure such as Amazon allow customers to run Exchange production servers in their AWS environment despite AWS is not SVVP validated. The reason for being able to do this is that the SVVP validation is not applicable to SPLA providers. When it comes to support, support for SPLA customers is provided under the SPLA agreement by AWS. And as Amazon explains, they are fully committed to supporting their customers running Microsoft workloads including Exchange Server on AWS.
In the above, you see me use both “Windows Azure” and “Microsoft Azure”. These refer to the same thing. Originally Azure was named Windows Azure but was rebranded to Microsoft Azure back on April, 3rd 2014.
It All Started with Exchange 2013 DAG Witness Server Support
Although Exchange Server was unsupported in Microsoft Azure, the intention was of course to change this support stance once the necessary things had been validated and Microsoft Azure was capable of providing the proper virtual machines instances and storage. Back on January 9th, 2015, it was announced that it was now supported to use a Microsoft Azure virtual machine as an Exchange 2013 Database Availability Group (DAG) witness server. The idea behind this was to help customers with their automatic datacenter failover Exchange 2013 scenarios, which requires three physical sites despite many customers with stretched DAGs only have two physical sites deployed today. By enabling the use of Microsoft Azure as a third physical site, this would provide many customers with a cost-effective method for improving the overall availability and resiliency of their Exchange deployment.
Figure 1: Hosting Exchange 2013 Database Availability Group (DAG) witness server in Microsoft Azure (Image courtesy of Microsoft and taken from TechNet)
Although it sounds simple, there’s of course more to it than just deploying the DAG Witness Server in Microsoft Azure. Since the idea is to introduce a third site, it also involves deploying a Domain Controller and creating a Microsoft Azure Virtual network as well as configuring a multi-site VPN. This is all explained in detail on Microsoft TechNet. As you can see, it’s not a simple task unless you already utilizing Microsoft Azure and have a multi-site VPN created for other purposes.
Then Came Support for Running Exchange 2013 in Microsoft Azure
But it wasn’t until back at the Microsoft Ignite Conference in May 2105, that things started to roll for real. At this conference Jeff Mealiffe (Principal Program Manager on the Office 365 engineering team) announced it now supported running Exchange 2013 servers as virtual machines in Microsoft Azure.
Jeff Mealiffe actually did a complete session on concerns, tradeoffs, and best practices of running Exchange in an IaaS environment. Not specific to Microsoft Azure but IaaS in general. You can watch the session here.
So since May 2015, it has been supported to run Exchange 2013 and later on a virtual machine in Microsoft Azure and third party IaaS environments. From the Exchange 2013 virtualization TechNet documentation:
Deployment of Exchange 2013 on Infrastructure-as-a-Service (IaaS) providers is supported if all supportability requirements are met. In the case of providers who are provisioning virtual machines, these requirements include ensuring that the hypervisor being used for Exchange virtual machines is fully supported, and that the infrastructure to be utilized by Exchange meets the performance requirements that were determined during the sizing process. Deployment on Microsoft Azure virtual machines is supported if all storage volumes used for Exchange databases and database transaction logs (including transport databases) are configured for Azure Premium Storage.
As you can see, the Exchange Server must use Microsoft Azure Premium storage for Exchange databases and database transaction logs (including transport databases).
Digging Deeper into the Storage Requirements
Microsoft Azure Premium Storage is specifically designed for Azure Virtual Machine workloads requiring consistent high performance and low latency. This makes them highly suitable for I/O-sensitive such as Exchange 2013. Although the I/O requirements for Exchange has been drastically reduced from version to version, it’s still sensitive in that the I/O requirements calculated for the anticipated workload must be guaranteed by the underlying storage/disks.
Premium Storage stores data on the latest technology Solid State Drives (SSDs) whereas Standard Storage stores data on Hard Disk Drives (HDDs). As most of us know, in the on-premises world, when you design the storage for Exchange 2013 databases and logs, the recommendation is to go with Enterprise SATA Disks in a JBOD model to keeps costs down. So to me, the requirement of using SSD-based storage seems a little aggressive. My take is, it has to do with the Standard Storage disks which cannot guarantee the required IOPS at all times as dedicated SATA disks attached to on-premises Exchange 2013 servers can. However, that’s just my own theory as I haven’t been involved in the storage validation for Exchange 2013 servers running in Microsoft Azure IaaS.
More information about Microsoft Azure Premium storage can be found here.
In order to use Microsoft Azure Premium Storage, it is currently required to use the “DS” series virtual machines, which are special VMs that enhance the performance of Premium Storage disks further. Below you can see the current prices for the respective DS VMs in US dollars. Yes they are expensive!
Figure 2: Prices for the respective DS Virtual Machines available in Microsoft Azure
Does it Make Sense from a Scenario and Cost Perspective?
Scenario 1 – Hosting Your Exchange Solution in Microsoft Azure IaaS
So the idea of running all your Exchange servers in Microsoft Azure IaaS does not make any sense for small organizations with few mailboxes nor large organizations with many thousands of mailboxes. There are several reasons behind my conclusion:
- You would need to extend your on-premises network infrastructure into a Microsoft Azure virtual network and configure a site to site VPN between the virtual network in Microsoft Azure and your on-premises network infrastructure. Unless you have already done this for other purposes, it is a project that will add additional complexity to your overall infrastructure just for the reason of hosting your Exchange servers in Microsoft Azure IaaS.
- When you host your Exchange servers in Microsoft Azure IaaS, you must also deploy a number of Domain Controllers as Exchange requires Domain Controllers to be located in the same site/physical location in order to deliver the best performance and to be supported. Rule of thumb is a 1:8 CPU ratio between Domain Controller and the Mailbox Server role. So for 8 Mailbox server vCPUs, 1 Domain Controller vCPUs.
- Since only Microsoft Azure Premium Storage is supported, you need to use virtual machines from the “DS” series. Both the Premium Storage and the DS VMs have a very heavy price tag associated with them.
No matter how many times you do the pricing calculations, it will not make sense to host your Exchange solution in Microsoft Azure IaaS. Depending on the size of the organization as well as feature/compliance requirements, you should instead consider one of the following options:
- Keep your Exchange solution on-premises and if it’s too costly, you may be able to change the underlying storage system from SAN to JBOD and use multi-role Exchange servers to reduce overall cost significantly.
- Migrate to the Exchange Online multi-tenant workload in Office 365.
- If you have requirements that do now allow you to migrate to Exchange Online MT and if you have more than 30.000 mailboxes, you may also be a good fit for Exchange dedicated (now known as Exchange Online Enhanced). This is beginning to look a lot more like Exchange Online MT just with additional features. The vNext version is based on Exchange 2013 and is using the same sync engine as Exchange Online MT (AAD Connect).
- Move your Exchange solution to an Exchange Hosting provider
Scenario 2 – Deploying Exchange Hybrid Servers in Microsoft Azure IaaS
I have talked with several customers as well as consultants that liked the idea of hosting all the servers required for establishing a hybrid between Exchange Online (Office 365) and Exchange on-premises in Microsoft Azure IaaS. More specifically, hosting the Exchange hybrid servers, synchronization server, and the AD FS servers in Microsoft Azure IaaS. While the idea depending on the specific scenario can make sense for the directory synchronization server and for the AD FS servers, you still need to keep in mind that in order for the Exchange hybrid servers to be in a supported state, they must use Azure Premium Storage and for that reason also “DS” based virtual machines. Yes I know, there are organizations that have deployed Exchange hybrid servers on non-“DS” based virtual machines and have everything working fine. But that is until an issue arises. And when that happens, you are in a non-supported scenario, so don’t do it.
Scenario 3 – Running Your Exchange Test Environment in Microsoft Azure IaaS
Running your Exchange test environment makes a lot more sense than scenario 1 and 2. You should be aware though that if you require the virtual machines to be running 24/7, this can be fairly costly as well. At least for an individual person.
As you already know from my past article series here on MSExchange.org, I like to use Microsoft Azure IaaS as my sandbox as I can deploy new VMs and use advanced features not available on my physical lab server.
Scenario 4 – Hosting the Exchange 2013 DAG witness server in Microsoft Azure IaaS
This scenario makes sense for most large organizations that only have two datacenters. Refer to the section earlier in this article for the details.
This concludes this article in which I gave you an insight into running Exchange Server in Microsoft Azure and the associated complexity and costs of doing so.