Running Exchange 2013 on Amazon Web Services

I’ve covered the topic of using Amazon Web Services (AWS) to host Exchange when I speculated on when cloud application platforms might become commonplace for applications such as Exchange. Today, Amazon offers an Exchange 2010 hosted service based on AWS (a guide is available from Amazon) and I speculate that work is ongoing inside Microsoft to figure out how to best support Exchange on the Azure platform. It’s been proven that it is possible to run Exchange 2013 on Azure, but there’s a world of difference between being able to install and run software and being able to provide a guaranteed level of support.

For now, the Microsoft position is that they do not support Exchange when deployed on a cloud application platform. This position was well enunciated by Jeff Mealiffe at the recent Exchange Connections conference. It means that if you encounter a problem when running Exchange on EWS or Azure, you won’t get support unless you can replicate the problem on a supported platform (physical or virtual server). In fact, the position is the same as in the early days of virtualization when VMware proved that Exchange 2003 worked well on their platform but Microsoft would not support virtual servers until they had to on their own hypervisor.

Recently I took a look at a test drive of Exchange 2013 on AWS offered by a company called Apparatus. The offer was simple. Sign up and Apparatus will build out a sample Exchange 2013 environment that you can then use for four hours. It sounded like a reasonable thing to check out, so I signed up and hit the button to build the lab.

The lab was ready 25 minutes later. I received an email giving me connection details and I used RDP to connect to the test drive environment composed of two Exchange 2013 CU2 servers (standard edition) configured in a Database Availability Group (DAG). The lab comes complete with a handbook to coach you through the steps of connecting to the servers, using the Exchange Administration Center, and connecting to Exchange with various clients. All pretty simple stuff so far before the lab moved onto details of how to test Exchange high availability by stopping all the services on one of the DAG nodes to observe how the databases failed over to the other. Again, not too hard.

Everything worked as expected with the exception of outbound messages, which stubbornly refused to be delivered to either my Office 365 tenant domain or Gmail. However, inbound mail worked smoothly. I’m sure that some minor glitch occurred in the background to stop outbound mail flow as the lab guide sets the expectation that bidirectional email is supported.

The configuration is limited through some customization of RBAC roles so that you cannot access all features. A quick check with EMS revealed that 174 cmdlets were available to the Administrator account against the normal 965 that would be available if the account was not restricted. This is similar to what happens with Exchange Online in Office 365 where RBAC is used to remove access to the cmdlets used to manage features like high availability for on-premises servers. So you can’t create a new DAG, for instance, nor can you play around with roles and permissions. I was able to create a new database (DB3 in the screen shot).

The Apparatus people are careful to point out that the configuration they provide is not representative of a production environment. Instead, it’s intended to demonstrate that complex applications like Exchange 2013 can run on a cloud application platform. I’m sure that a lot of work was necessary behind the scenes to make AWS work with Exchange 2013, but that’s always the case when new computing paradigms hove into view.

The point that I took from the test drive is that cloud application platforms are maturing quickly and that the time when we will be able to use AWS and Azure to host Exchange 2013 and future version in a supported manner is approaching quickly, perhaps faster than first anticipated. 2014 might be the year when things really happen in this space. In the meantime, maybe you’d like to check things out and take a test drive to kick the proverbial tires of the AWS platform.