Running Microsoft Exchange Server at Scale on AWS

Pairing Amazon EC2 instances with a Windows Server provides a secure and reliable environment to quickly deploy and run Microsoft Exchange Server. Many of our customers have opted for this architecture, which is compatible with several versions of Exchange Server, including 2007, 2010, 2013, and 2016.

Managed email services, such as Amazon WorkMail, can improve predictability and remove the burden of managing email servers. Still, some government customers choose to manage their own email servers privately on EC2 for regulatory reasons. Consider the following cost-reduction options as you look to run Exchange Server on EC2.

Size it right

Start with the Exchange Server Role Requirements Calculator to size EC2 instances for Exchange Server, using these parameters:

Server Role Virtualization: Yes
High Availability Deployment: Yes
Consider Storage Designs Utilizing JBODs: Yes
Multiple Databases/Volume: Yes
Automatically Calculate Number of Exchange Database Volumes Required: Yes
Automatically determine number of DAGs and Servers: Yes
Optimize for fewest Servers or fewest DAGs? Servers

For server memory:

Use Microsoft Recommended Limit for Maximum Mailbox Server Memory: No
Maximum Mailbox Server Memory: 128GB

Microsoft recommends a maximum of 96GB of memory per mailbox server in Exchange Server 2013 and Exchange Server 2016. Many customers bypass the recommended maximum mailbox server memory limit and let the Exchange Calculator recommend slightly larger machines, up to 128GB of memory. This allows you to leverage more efficient instance sizes, such as the r4.4xlarge, which features 16 vCPUs and 122 GB of memory.

Historically, people have associated Exchange Server with an IOPS-hungry, I/O-dependent workload. At the core of Exchange Server lies a database, so disk I/O is important. However, recent versions of Exchange Server and advances in storage technology have re-defined storage requirements and recommended storage architectures. SSD disks are not required for Exchange Server 2016 mailbox servers to perform efficiently.

Use st1 volumes instead of gp2

What EBS storage makes economic sense and provides the requisite throughput and IOPS for Exchange Server 2016? We decided to put the lower-priced st1 (Throughput Optimized) disks to the test.

Test case: We built an environment with Exchange Server 2016 CU4 mailbox servers running on Windows Server 2016 r4.4xlarge instances, plugged in nine st1 EBS volumes of 6400GB each per mailbox server, an Exchange mailbox database on each disk, and a separate volume for the OS disk. We ran the Exchange Server Jetstress Tool, which simulates Exchange 2013 and Exchange 2016 disk I/O load on a server. The objective is to verify the performance and stability of your disk subsystem before deploying Exchange in a production environment.

Outcome: the st1 disks performed well and passed all Jetstress tests.

Test input parameters:

9 databases per host. 1 active database per st1 volume. Logs and database files were co-located on same st1 volume.
Database size: 2.4 TB
Copies per database: 3
Run Background Database Maintenance: Yes

The results in more detail:

Transactional I/O Performance

Host Performance

Email filtering and security

With hosting your own email server comes the need to secure and protect against spam and malware. There are multiple approaches to email filtering. The common ones include Exchange Edge servers, third-party filtering appliances, and a hosted mail filtering service. Customers may choose from one of these solutions, depending on their use case and requirements.

Good architecture calls for implementing services over servers – the former being loosely coupled, highly scalable, and predictable. Using a mail filtering service not only reduces cost, but also removes the complexity of managing EC2 instances for Exchange Edge servers.

For instance, customers with a Microsoft Enterprise Agreement may be eligible to use the Exchange Online Protection (EOP) service as part of their Enterprise CAL with Services. EOP is a hosted email filtering service from Microsoft. The customer Mail Exchange (MX) records point to the service, and filtered email is delivered to Exchange Mailbox servers running on EC2, relying on scalable services and reducing overall EC2 costs.

A few security best practices include:

Point your MX records in the Domain Name System (DNS) to the email filtering service provider you choose.
Your VPC and Security Groups should be configured so that only SMTP (port 25) traffic from the known IP addresses of your email filtering service can reach your Exchange Servers. This limits the scope of inbound SMTP traffic. Additionally, allow only IP addresses of your email filtering service provider to relay email on your Exchange Receive Connectors.
You can deploy the Exchange servers in a private subnet and install a third-party firewall in front of it. When used in conjunction with EOP, make sure the firewall allows SMTP traffic on port 25 without any modification or processing.
Implement a NAT Gateway to allow Exchange Servers to get to the Internet.
Use a Remote Desktop Gateway server or a bastion host (jump server) to connect to your Exchange Servers via RDP from the Internet. An alternate approach is to allow access to your Exchange Servers only from your on-premises network via VPN or AWS Direct Connect.

Archive on Amazon S3, not Amazon EBS

Exchange Server provides archiving capability out of the box. However, the archive mailbox databases are stored on disk, which relies on EBS volumes. EBS volumes are generally more expensive than S3 storage – and S3 storage is better suited for archive data.

Since Exchange Server does not natively support writing archives to S3, a third-party solution, such as Metalogix Archive Manager for Exchange, would be required. Your choice here might depend on the cost of procuring and maintaining a third-party archival solution that supports S3 and its associated costs. Compare this to the cost of EBS volumes needed to store the Exchange mailbox databases for archive databases.

Automate

Begin by leveraging the Exchange Server Quick Start to automate the deployment of Microsoft Exchange on AWS. You can customize the CloudFormation templates provided with this Quick Start to deploy the latest version of Exchange with st1 disks, as well as within your existing Active Directory forest.

Authored by Shijaz Abdulla, Solutions Architect Lead- Public Sector, Amazon Web Services