Microsoft + AWS: A Winning Combo (Part 4)

If you would like to read the other parts in this article series please go to:

Introduction

In Part 1 of this series, we took a look at how Amazon’s AWS provides a solid cloud platform for running any of the currently supported versions of Windows Server, and a wide variety of Microsoft server applications that can be migrated from your on-premises data center to the Amazon cloud. In Part 2 we continued the discussion of how to run Windows servers and applications on AWS and how to get the most bang for your buck out of this Microsoft/Amazon combination.

In Part 3, we began a discussion aimed at how to deploy popular Microsoft server applications such as Exchange and SharePoint on your Windows instances running on AWS. Specifically, we provided some tips on capacity planning for an Exchange deployment on an AWS EC2 instance. Here in Part 4, we will continue with that discussion.

Deploying Exchange Server on AWS EC2

Now that we’ve talked about capacity planning, it’s time to think about how to best deploy your cloud-based Exchange servers for high availability, as well as some specifics of instance configuration, monitoring and patch management, backup considerations and the all-important issue of security.

High Availability considerations

High availability is an important element for mission critical servers in today’s business environment, and for most of us, email services are one of the most mission critical of all our computing services. Redundancy is a key component for high availability, but simple redundancy isn’t enough. You could have a complete backup server that’s ready to go if your primary server fails, but if it’s sitting in the same room (or building) as the primary server, it would most likely do you no good in case of a natural disaster such as a tornado or bombing because the backup would be destroyed along with the primary server.

For true high availability, you should have backup servers that are in a wholly different geographic area. That’s not always easy to do when your email servers are located on premises, if your organization doesn’t have multiple physical sites. That’s one way in which cloud computing can offer a big advantage. Because AWS EC2 is hosted in data centers that are spread out across the country and world, you can distribute your application (in this case, Exchange) across different physical locations so that a failure is less likely to take you offline.

Amazon’s services are available in nine different regions around the world, in North America, South America, Europe, Singapore, Tokyo, Beijing and Sydney. You can find out more about the regions here.

Within each region there are availability zones that are separated from one another. You can provision instances in multiple geographic regions or spanning different availability zones to achieve high availability. In most cases, spanning availability zones will provide sufficient protection and is less complex than spanning multiple regions. If you do span regions, you must pay the Internet data transfer rates for both instances (sending and receiving).

You can distribute your Active Directory site across multiple availability zones, but it is better not to span regions with AD sites. Designing your AD topology to span zones can provide for failover with minimal replication latency. However, there are some caveats. When you span zones with AD, you can only have one Client Access Array object per AD site, and you may pay more for regional data transfer monthly charges. Thus you might want to put each AD site in a single availability zone. Then each zone can be configured with its own Client Access Array object. Be aware, though, that you’ll need to have multiple instances of each role. A Mailbox server in one zone can’t use services of other Exchange roles that are in a different AD site.

Refer to the AWS Exchange Planning and Implementation Guide for step-by-step instructions on how to configure Active Directory for high availability.

Automating instance configurations

If you need to deploy a number of Exchange servers in the AWS cloud, the most efficient way to do that is to use the standard AWS CloudFormation templates. This provides you with an Amazon Machine Image (AMI) of the Windows Server operating system. Then you can use PowerShell scripts to automate the configuration tasks.

Note:
Amazon also provides AWS Tools for PowerShell that include cmdlets for scripting operations on AWS resources, using the PowerShell command line. This is handy for those admins who prefer the speed of the command line to working with GUI interfaces.

For more information about setting up and using the AWS tools for Windows PowerShell, see Amazon’s documentation.

There are a number of tasks that you can automate this way. You will need to rename the instance to give it a unique name, and you can create a forest and domain, join your Exchange Mailbox Servers to the domain, configure the network and download Exchange installation files.

It’s also possible for you to create your own custom AMI instead of using the standard one. That way, you’re able to preconfigure the things that will be the same for all of your Exchange servers. To create a custom AMI, you start with an existing machine image. Amazon’s web site provides a video that walks you through the process of creating a custom AMI.

There’s a big caveat you need to be aware of, though: Do not install Exchange Server in the custom AMI and don’t join the custom AMI to the domain. Although this might seem to be a way to save even more time, it won’t work because Exchange Server doesn’t support Sysprep. All software that you install into the custom AMI has to support Sysprep.

Using CloudWatch to monitor your instances

Chances are you’re going to want to keep up with how your instances are performing. For that, you can use Amazon’s CloudWatch. CloudWatch can also monitor EBS volumes, elastic load balancers and other Amazon resources as well, but here we’ll be focusing on how to monitor the EC2 instances on which your Exchange Server deployment is running.

With CloudWatch, you can get statistical information and graphs and you can set alarms to alert you when specified conditions occur. You don’t have to install any additional software to monitor your instances with CloudWatch, and basic monitoring is automatically enabled for all EC2 instances. The information is available via the CloudWatch tab in the AWS Management Console and you can also use the CloudWatch API to access it.

At additional cost, you can upgrade from basic monitoring to detailed monitoring. Basic monitoring gives you seven pre-selected metrics at five minute frequency, whereas Detailed Monitoring increases that to one-minute frequency and allows you to aggregate the data by ECs AMI ID and instance type.

You can also combine CloudWatch with Microsoft System Center Operations Manager. You can monitor your EC2 instances together with your on-premises resources in the same console by using the AWS Management Pack for Microsoft System Center that’s provided by Amazon. You can find out more about that here.

Backup, Patch Management and Security

Keeping your email accessible and secure is vital to business productivity and continuity. You have different options for backing up your Exchange Servers that run on EC2 instances. There are third party backup products that can store backup data on Amazon Simple Storage Service (S3). You can also use application-level backup software and create an AMI of your Exchange Server. Amazon doesn’t recommend using the Amazon EBS Snapshot to back up your Exchange servers.

Your Windows Server and Exchange software that runs in EC2 instances must be regularly updated just like machines that you run on premises. You can use Microsoft System Center Configuration Manager (SCCM) and Windows Server Update Service (WSUS) for managing patching. Otherwise you can simply use Group Policy to configure the Windows Update service on the Windows servers.

It’s important to configure your Exchange servers for best security practices. You can use Microsoft’s UAG 2010 so that you don’t provide direct access to your Exchange Server client access servers. It’s best to use Edge Transport servers instead of directly publishing inbound SMTP access to Hub Transport servers on a multiple role Exchange server. Amazon also cautions to never provide open access to RDP over the Internet, and provides more detailed information on how to secure the Remote Desktop Gateway and the Microsoft platform in general in a white paper that you can download from the AWS web site.

Summary

In this, Part 4 of our Microsoft + AWS: A Winning Combination series, we wrapped up the discussion of how to deploy Microsoft Exchange on Amazon EC2 instances. In Part 5, the final article in this series, we will offer some tips on deploying SharePoint on EC2 and bring this discussion to a close. Join us then!

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top