How to run Microsoft Exchange Server on AWS using Amazon EC2

I’ve been asked, “Is it possible to run Microsoft Exchange on AWS?” Yes, it is. In this two-part blog series, I will walk you through two common architectures for running Microsoft Exchange on AWS.

In this first post, I cover the architecture of running Microsoft Exchange on Amazon Elastic Compute Cloud (EC2) Windows instances and running Microsoft Active Directory domain controllers on EC2 instances. If you already have Active Directory (AD) on-premises, this approach will enable you to extend your AD domain into the AWS cloud by adding domain controllers that run on EC2 Windows instances. Once you have your AD domain controllers in AWS, you will be able to run many Windows workloads in the cloud, in addition to Microsoft Exchange Servers. We’ll publish part two of this series in September, where I’ll cover running Microsoft Exchange Servers in a Resource Forest Model. By running Microsoft Exchange on AWS, you can retain control over your email data while taking advantage of AWS’s scalability, reliability, and performance.

Let’s start by looking at what Exchange can look like on AWS.

Architectural Diagram for Exchange on AWS

In the following diagram, we created a scenario where a company has extended their Active Directory forest (corp.example.com) to AWS by adding domain controllers in AWS. The company’s Exchange organization has also been extended to AWS by adding Exchange servers in AWS. Once you have extended your on-premises Active Directory and Exchange environments onto AWS, you can easily move your users’ mailboxes into the new environment.

In the architecture, Microsoft Exchange runs on Amazon EC2 instances in the same Active Directory forest as your on-premises Active Directory forest.  This architecture is commonly used when customers want to move some or all of their Exchange servers out of their data center and into the AWS cloud. Some customers also take this approach during the process of upgrading their Microsoft Exchange Server environment to a newer version on AWS. To help modernize your Microsoft Exchange Server workloads, we offer AWS Professional Services and AWS Partner Network support.

Now that we know what Exchange looks like running on AWS, let’s dive into the tutorial.

Step 1: Set up connectivity between on-premises and AWS environments

1.1 Establish Network Connectivity

The first step is to establish network connectivity between your on-premises data center and AWS.  Most customers choose one of two approaches to establish connectivity:

• A site-to-site Virtual Private Network (VPN) connection: Establish a VPN over the internet between your on-premises network and the AWS cloud. A Getting Started guide can be found here.
• AWS Direct Connect: Establish a Direct Connect network connection between your on-premises network and AWS. A Getting Started guide can be found here.

I generally recommend the Direct Connect approach instead of VPN connection for production workloads such as a hybrid Active Directory and Exchange architecture. This is because Direct Connect provides more predictable latency and consistent bandwidth between your data center and your VPC. See the AWS Direct Connect documentation for more information.

During this process, it is important to design the IP address ranges (CIDR) for your AWS cloud environment so that they do not overlap with your on-premises network. You must then establish network routing so that packets can route between the on-premises and AWS environments.

After the IP ranges are assigned, plan the Active Directory site(s), AD subnets objects, and AD site links that are needed for the network created in AWS.

1.2       Establish hybrid DNS resolution

Once you have established the network connection, the next step is to design the DNS resolution between your on-premises servers and the servers on AWS so that DNS queries can be resolved for resources either on-premises or in the cloud. This is referred to as a “hybrid DNS architecture.”

One option is to change the DNS server setting on the servers running in AWS to point to the IP addresses of the on-premises DNS servers. You may also need to add the AD domain name to the DNS suffix list (see following figure).

Figure 2:  Add on-premises DNS servers’ addresses and append DNS suffixes for AD domain name

Once DNS servers are set up in AWS, then these DNS setting could be updated to point to the DNS servers in AWS.

If you have Route 53 private zones and must establish hybrid DNS, another option is to use Route 53 resolvers. The blog post, New – Amazon Route 53 Resolver for hybrid clouds, discusses how to set up hybrid DNS and outlines how to use Amazon Route 53 Outbound and Inbound Endpoints to enable hybrid DNS between on-premises and AWS.

For more information on hybrid DNS, please see this blog.

1.3 Extend Active Directory (AD) to AWS

After you set up hybrid DNS resolution between resources on-premises and in the cloud, the next step is to extend your on-premises Active Directory to AWS. To do this step, set up new servers in AWS and promote them to become AD domain controllers. The servers can be promoted to be domain controllers in the same Active Directory domain as on-premises or a new AD domain in the same AD forest.

During the AD domain controller promotion process, install the DNS server role on the server. This action enables the AD domain controllers to resolve DNS queries.

Once the DNS server role is installed on the AD domain controllers running in AWS, update the Route 53 Resolver Outbound Endpoint conditional forwarding rules to forward DNS queries for the AD DNS domain (for example, corp.example.com) to these new AD/DNS servers.

On the AD DC/DNS servers running in AWS, set up a DNS forwarding rule to forward unresolved DNS queries to Route 53. Route 53 has the ability to host private zones, which are used by AWS PrivateLink endpoints (see here for more information). Thus, if you want to take advantage of PrivateLink endpoint services, it is important that you modify the DNS setting on the AD/DNS servers to forward unresolved DNS queries to the Route 53 service versus the internet root DNS servers.

The following screenshot shows the Forwarder setting on the AD/DNS server. We set the IP address to the .2 of the subnet (for example, 10.0.0.2). The .2 address is reserved by AWS as the AWS DNS server (see here for more information).

Figure 3: Configuring the Windows DNS server forwarder settings

1.4       Extend Microsoft Exchange into AWS

Once your Active Directory has been extended to AWS, the next step is to set up Microsoft Exchange. Since the same Active Directory forest and AD schema exists on-premises and on AWS, the Microsoft Exchange servers on AWS can be part of the same Exchange organization that is on-premises. To set up Exchange in AWS, create Windows servers running on Amazon EC2 instances (see guide here), join them to the AD domain, and then install the Microsoft Exchange software onto them. As mentioned earlier, many customers take this opportunity to upgrade their Exchange server to a newer version.

The same design patterns that go into designing Exchange on-premises also apply to running Exchange servers on AWS. For example, these design patterns include server sizing, using Exchange calculator, namespace planning, mail routing, and mail hygiene. For more information, Microsoft has documented these best practices in their Exchange Preferred Architecture.

Once these steps have been completed, move your mailboxes onto the Exchange servers that are running in AWS. Start by migrating test mailboxes before you migrate larger populations of real users.

Step 2: Creating an Exchange Lab Environment

The rest of this blog shows you how to set up an AD/Exchange environment in a lab environment. To help you, AWS has created an AWS Quick Start for Microsoft Exchange. The Quick Start deploys two Microsoft Exchange servers in a database availability group (DAG) configuration with two Active Directory domain controllers, as shown in the following diagram.

Figure 4:  Exchange environment that will be created by AWS CloudFormation

Each Exchange server and domain controller is created in a separate Availability Zone (AZ) for resiliency.

Please note that you are responsible for the cost of the AWS services used while running this Quick Start reference deployment. AWS provides a Simple Monthly Calculator to estimate the cost of running this environment. To minimize the cost of running the test environment, I recommend stopping the EC2 instances in the environment when they are not in use.

2.1 Install Microsoft Exchange using AWS Quick Start

To install the AWS Quick Start For Microsoft Exchange, please follow the instructions described in detail here. After the Quick Start CloudFormation template completes, continue to the next step. The Quick Start CloudFormation process takes about 90 minutes to complete.

2.2 Connect to Microsoft Exchange

Next, connect to the remote desktop gateway (RDGW) server and the Microsoft Exchange server.

1. Connect to the RDGW instance. For instructions on how to connect, see Connecting to Your Windows Instance.
2. Once you log in to the RDGW, you can connect to the other servers in the environment with RDP. When you set up the AWS CloudFormation template in Section 3.1, you specified the AD domain name (in my example, exch.example.com), the domain admin user name (for example, stackadmin), and the password.

3. From the RDGW server, connect to Exchange server 1. When you are on Exchange server 1, launch the Exchange Administration Center. You can find the Exchange AWS Management Console on the Windows Launch Bar (see the following screenshot).

Figure 5:  Launch Exchange Administrative Center from the startup menu

You should now be able to access the Exchange Administration Center.

Figure 6: Screenshot of Exchange Administration Center

Cleaning Up

When you are done with the lab, you can go back to AWS CloudFormation and select the option to delete the CloudFormation stack. By selecting delete, AWS CloudFormation deletes the resources that it created.

Summary

Congratulations!  You have learned how to set up Microsoft Exchange in AWS. In the hands-on lab, you also got experience using AWS Infrastructure as Code (IaC) technology called AWS CloudFormation to automate the build of a Microsoft Active Directory and Microsoft Exchange Server environment. Once Exchange is set up in AWS, you can use the same AD and Exchange management tools to manage the servers on AWS that you used on-premises. In the second part of this blog series, I will walk through another common architecture for running Exchange in AWS, the Exchange resource forest architecture.

To learn more on migrating Windows Server or SQL Server, visit Windows on AWS. For more information on how AWS can help you modernize your legacy Windows applications, check our our Modernization page. Contact us to start your modernization journey today.