Menu
Exchange Server on AWS
Quick Start Reference Deployment Guide

Additional Considerations

Network Security

As with any enterprise application deployment, an Exchange Server organization in AWS should implement strict security controls. AWS provides a comprehensive set of security features that allow you to control the flow of traffic through your Amazon VPC and associated subnets, and ultimately to each Amazon EC2 instance. These features allow you to reduce the attack surface of your environment while providing end-user access to Exchange Server content and applications, as well as administrator access for securely managing the Microsoft Windows Server infrastructure. The following sections discuss the security features and approaches implemented in this reference deployment.

Security Groups

When launched, Amazon EC2 instances must be associated with at least one security group, which acts as a stateful firewall. You have complete control over the network traffic entering or leaving your security groups, and you can build granular rules that are scoped by protocol, port number, and source/destination IP address or subnet. By default, all outbound (egress) traffic from a security group is permitted. Ingress traffic, on the other hand, must be configured to allow the appropriate inbound traffic to reach your instances.

This Quick Start creates a number of security groups, and each group has several inbound rules for various TCP and UDP ports for server-to-server and client-to-server communication. You can customize these security groups and their associated rules within the provided AWS CloudFormation templates.

Network ACLs

A network access control list (ACL) is a set of permissions that can be attached to any network subnet in an Amazon VPC to provide stateless filtering of traffic. Network ACLs can be used for inbound or outbound traffic, and provide an effective way to blacklist a CIDR block or individual IP addresses. These ACLs can contain ordered rules to allow or deny traffic based upon IP protocol, service port, or source or destination IP address. By default, each Amazon VPC subnet includes a network ACL that permits all traffic from any source or destination.

You may choose to either keep the default network ACL configuration or lock it down with more specific rules to restrict traffic between subnets at the network level. One benefit to having multiple layers of network security (security groups and network ACLs) is that they can be managed by separate groups in your organization. If a server administrator inadvertently exposes unnecessary network ports on a security group, a network administrator could override this configuration by using an explicit deny rule, blocking the traffic at the network ACL layer in Amazon VPC.

Edge Transport Servers

The Exchange Edge Transport server role is deployed in the perimeter network to reduce the attack surface of your messaging system for Internet-facing mail flow. These servers act as an SMTP gateway and run agents that provide additional layers of protection and security.

When you launch this Quick Start, you can optionally include Edge Transport servers in the public subnets in each Availability Zone.

As shown in Figure 22, the AWS CloudFormation template uses a conditional parameter called IncludeEdge to control this setting. To include the Edge Transport servers in your deployment, set the parameter to true. After the deployment, you'll need to create an Edge Subscription and configure your DNS MX records to resolve to the Elastic IP addresses of your Edge Transport servers. For more information, see Edge Subscriptions in the Microsoft TechNet Library.


	                Specifying Edge Server Options in Template Parameters

Figure 22: Specifying Edge Server Options in Template Parameters

The edge servers deployed by this Quick Start will not be domain-joined. To authenticate to these servers for remote administration, you'll need to authenticate locally on each instance. The edge server in the first Availability Zone is named edge1, and the edge server in the second Availability Zone is named edge2. To log in, use edge1\administrator or edge2\administrator for the user name, and use the password specified via the DomainAdminPassword parameter when launching the AWS CloudFormation template. You can authenticate to the remaining domain-joined servers by using the domain administrator user name and password provided when launching the template.

Reverse Proxy Servers

When you allow client access to your Exchange infrastructure over the Internet for HTTP-based workloads such as Microsoft Outlook Web App, Exchange ActiveSync, or Outlook Anywhere, you can add an additional layer of security by placing reverse proxy/threat management servers into your public Amazon VPC subnets. The public subnets in this reference architecture can be considered a perimeter network (DMZ) that you would typically use in a traditional physical network environment.


	                Reverse Proxy Server in a Public VPC Subnet

Figure 23: Reverse Proxy Server in a Public VPC Subnet

One of the benefits of this architecture is the ability to pre-authenticate users at the perimeter of your network, while shielding your internal Exchange servers from the public Internet. Several third-party appliances and applications can be used for this task. The Web Application Proxy role in Microsoft Windows Server 2012 R2 also provides support for publishing your Exchange servers to the Internet. Another option is to use Microsoft IIS Application Request Routing (ARR).

Keep in mind that the Exchange Edge Transport handles only the SMTP protocol. If you choose to deploy the optional Edge Transport servers into the public subnets upon launching this Quick Start, you may be able to install reverse proxy software on those servers to handle HTTP requests and minimize the number of instances required in your architecture.

Remote Administration

When architecting workloads on AWS, you should always eliminate single points of failure. This also applies to any infrastructure you will use for remote administration over the Internet (if required). You can do this in a Windows environment by deploying Remote Desktop (RD) Gateway in each Availability Zone. In case of an Availability Zone outage, this architecture allows access to the resources that may have failed over to the other Availability Zone.

The RD Gateway uses the Remote Desktop Protocol (RDP) over HTTPS to establish a secure, encrypted connection between remote administrators on the Internet and Windows-based, Amazon EC2 instances, without needing to configure a virtual private network (VPN) connection. This allows you to reduce the attack surface on your Windows-based instances while providing a remote administration solution for administrators.

The AWS CloudFormation templates provided in this Quick Start automatically deploy the architecture and configuration steps outlined in the Quick Start Reference Deployment for the Microsoft Remote Desktop Gateway.

After you've launched your Exchange Server infrastructure using the AWS CloudFormation template in this guide, you will initially connect to your instances using a standard RDP TCP port 3389 connection. You can then follow the steps in the RD Gateway Quick Start deployment guide to secure future connections via HTTPS.

Encryption at Rest

Amazon EBS encryption offers you a simple encryption solution for your Amazon EBS volumes without requiring you to build, maintain, and secure your own key management infrastructure. When you create an encrypted Amazon EBS volume and attach it to a supported instance type, data stored at rest on the volume, disk I/O, and snapshots created from the volume are all encrypted. The encryption occurs on the servers that host Amazon EC2 instances, providing encryption of data in transit from Amazon EC2 instances to Amazon EBS storage.


                Provisioning an Amazon EBS Volume with Encryption

Figure 24: Provisioning an Amazon EBS Volume with Encryption

Amazon EBS encryption uses AWS Key Management Service (AWS KMS) Customer Master Keys (CMKs) when creating encrypted volumes, and creating any snapshots from your encrypted volumes. The first time you create an encrypted Amazon EBS volume in a region, a default CMK is created for you automatically. This key is used for Amazon EBS encryption unless you select a CMK that you created separately using AWS KMS. Creating your own CMK gives you more flexibility, including the ability to create, rotate, disable, and define access controls, and audit the encryption keys used to protect your data.

Transport Limitations for Amazon EC2 Instances

In order to maintain the quality of Amazon EC2 addresses for sending email, we enforce default limits on the amount of email sent from Amazon EC2 accounts. If you want to send larger amounts of email from Amazon EC2, you can apply to have these limits removed from your account. To do so, submit a request using the AWS Request to Remove Email Sending Limitations form.

If you intend to send email to third parties from Amazon EC2 instances, we also suggest that you provide the Elastic IP address (EIP) for each Exchange Edge Transport server to AWS through the same form. AWS works with ISPs and Internet anti-spam organizations such as Spamhaus to help reduce the chance that email sent from your addresses will be flagged as spam.

You can also help avoid having your email flagged as spam by assigning a static reverse DNS record to the EIP used to send email. You have the option to provide AWS with a reverse DNS record (such as mail.example.com) to associate with your EIP(s). Note that a corresponding forward DNS record (an A record) pointing to your EIP must exist before AWS can create your reverse DNS record. It may take up to a week before the anti-spam organization approves your EIP(s).

Backup Options

The Microsoft PA for Exchange Server 2013 provides Exchange Native Data Protection, which relies on built-in Exchange Server features to protect your mailbox data without the use of backups. By combining Exchange Native Data Protection with Legal Hold, lagged database copies, and other built-in features, you can reduce or eliminate your reliance on conventional point-in-time backups, and lower your costs.

If you decide to deploy only the minimal amount of infrastructure to provide high availability (i.e., two Exchange multi-role servers), you should implement a traditional backup solution. There are a number of third-party, VSS-based backup solutions that are compatible with Exchange Server.

For details on Exchange Native Data Protection and traditional backup configurations, see the Backup, restore, and disaster recovery guidance for Exchange Server 2013 in the Microsoft TechNet Library.

On this page: