Microsoft + AWS: A Winning Combo (Part 3)

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

• Microsoft + AWS: A Winning Combo (Part 1)
• Microsoft + AWS: A Winning Combo (Part 2)
• Microsoft + AWS: A Winning Combo (Part 4)
• Microsoft + AWS: A Winning Combo (Part 5)

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.

Deploying Microsoft Exchange on AWS

Exchange Server is one of the most popular email solutions for businesses, as it easily integrates with other Microsoft products and interoperates with mobile devices of all types, while allowing you to control access and usage. Exchange uses Kerberos authentication and supports S/MIME for digitally signing and encrypting emails and attachments, and also enables sharing of calendars and contacts.

Running an Exchange Server on premises in a traditional data center requires a capital outlay for hardware and ongoing hardware maintenance. Running an Exchange Server on Amazon EC2 can reduce administrative time and effort and can be more cost effective.

This is particularly beneficial in cases where your organization is growing rapidly and you need to be able to scale up your Exchange deployment quickly and easily. You can add virtual machine instances to handle the extra load, without worrying about hardware resources or data center space needs. Because you don’t have to deal with the hardware planning, purchase and setup processes, you can have your Exchange servers up and running in less time.

What about licensing? In Part 1, we talked about the Microsoft License Mobility through Software Assurance program. Through this program, if your organization is a Microsoft volume license customer, you can use your existing Exchange Server licenses when deploying Exchange on AWS.

What about security? We’ll discuss that in more detail later, but you can leverage AWS’s security features such as multi-factor authentication and data encryption to protect your Exchange deployment and the sensitive email that it handles.

Designing your cloud-based Exchange deployment

We will assume here that you have some basic familiarity with Amazon EC2 and VPC as well as Windows Server. For purposes of this article, we’re going to examine a typical deployment scenario using Windows Server 2008 R2 and Exchange 2010, but the same basic principles would apply to Windows Server 2012/2012 R2 and Exchange 2013.

We won’t be talking about the details of installing and configuring the software but rather the special considerations that surround the deployment of Exchange Server in the AWS cloud. After all, if you’ve installed Exchange Server in your own data center, the installation process is the same when installing on the AWS infrastructure.

One of the first things that you’ll want to do is determine your capacity needs based on your mailbox servers. You can use the Exchange Server Role requirements calculator on the Microsoft web site. You’ll find the calculator for Exchange 2010 here.

If you’re installing Exchange 2013, you’ll find that version of the calculator here .

Processor Sizing

Now you’re going to need to determine the processor size you’ll need for your EC2 virtual CPU. Amazon measures CPU resources in terms of EC2 Compute Units or ECUs. The ECUs represent the amount of CPU capacity that is allocated to your EC2 instance. You can use the Exchange Processor Query Tool provided by Microsoft to help you determine a processor’s SPECInt2006 rate value. This is an online tool so you need an Internet connection when using it.

You want to make sure that the mailbox role doesn’t use more than 75 percent of the CPU resources for a standalone server or in a multiple role server, that no more than 35 percent of the processor is used. If the processor usage exceeds these numbers, you should deploy additional Exchange Server Mailbox role instances.

The Mailbox role is the most important in this calculation because the sizing for other roles depends on a ratio of role processor cores to Mailbox role processor cores. Mailbox to hub transport ratio is 5:1, Mailbox to client access is 4:3 or Mailbox to client access plus hub transport combined role is 1:1. The Mailbox to Active Directory Global Catalog role should be 8:1 for 64 bit GC servers or 4:1 for 32 bit GC servers.

Thus you need to select the AWS instance for each of your Exchange Servers in light of its roles and based on these sizing ratios. There are other considerations for additional roles. The Edge Transport role’s processor sizing should be based on what you estimate would be the peak workload. You have to measure (or estimate) the connections per second, messages per second and average message size in order to determine how many Edge Transport servers you need. You can find out more about this in Microsoft’s Understanding Server Role Ratios and Exchange Performance doc on the TechNet web site.

Memory Sizing

The next consideration is how much memory your Exchange server deployment will need, so you can choose the correct AWS EC2 instance with the right memory configuration. All standalone Exchange Servers require a minimum of 4 GB of RAM and multiple role servers need at least 8 GB, but these are minimums. For Exchange 2010, the following table can server as a guideline. Memory recommendations are also dependent on processor configuration.

Table 1

Storage Sizing

Yet another important consideration is the amount of storage space you’ll need for the mailboxes and other data. Microsoft recommends minimums for Exchange 2010 of 1.2 GB of storage space for the installation of Exchange, plus 500 MB of space for each unified messaging language pack (if any) that you install on it and at least 500 MB of storage space for the message queue database on the Edge Transport server or Hub Transport Server.

Remember to allow for storage space for logging and patching. Microsoft’s recommendation for the minimum volume size for the partition on which the Windows Server operating system resides is 80 GB. It’s best to install Exchange on a path on the Amazon EBS volume that’s different from the partition where the operating system is installed. To get better performance, you should also put the paging file and temporary files for Exchange on a different volume than the operating system.

To accurately calculate your storage requirements, you need to have an idea of how many mailboxes you want to deploy, expected growth in number of mailboxes, how much mail (on average) users receive per day, mailbox size limits, average message size, and deleted item retention period.

You can use AWS’s Elastic Block Storage (EBS) volumes, which can be very quickly provisioned or deprovisioned when your storage requirements increase or decrease. Amazon’s EBS volumes are the equivalent of logical unit numbers (LUNs). There is a limit of 26 volume mount points per instance, so you might need to add more Mailbox role instances in order to keep from going over this limit.

You can use the free Microsoft Exchange Server Jetstress tool to test the capacity of the storage configuration. The tool simulates disk input and output on your server to verify the performance and stability of the disk subsystem. You can download the tool from the Microsoft Download Center.

Sizing Summary

For a very detailed discussion of how to calculate memory (and processor) needs, check out the Exchange 2010 Sizing Cheat Sheet over on the MSExchange.org web site.

If you’re deploying Exchange 2013, here is a similar cheat sheet.

You can find detailed instructions for processor, memory, storage, log replication and network traffic sizing in the AWS Exchange Planning and Implementation Guide that’s downloadable from the AWS web site.

Summary

As we turn our discussion to some specifics of how to deploy Exchange Server on Amazon Web Services in an EC2 instance, we covered the planning process and how to determine your capacity needs so as to select the best EC2 instance types for your particular situation.

In the next installment of this series, Part 4, we’ll continue our discussion about Exchange and talk about high availability (including Active Directory site design and cross region deployment), instance configuration, monitoring and patch management, backup and security considerations. See you then!

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

• Microsoft + AWS: A Winning Combo (Part 1)
• Microsoft + AWS: A Winning Combo (Part 2)
• Microsoft + AWS: A Winning Combo (Part 4)
• Microsoft + AWS: A Winning Combo (Part 5)