Microsoft Servers on AWS
Microsoft Servers Quick Start

Appendix B: Best Practices

Networking and Security

The networking and security components of the Quick Start architecture and key considerations include:

  • Amazon VPC

  • Security groups and network access control lists (ACLs)

  • VPC Flow Logs

  • Remote administration

  • Principle of least privilege

These are discussed in the following sections.

Amazon VPC

Amazon VPC allows IT to configure internet protocol (IP) ranges, public/private subnets, routing tables, and internet gateways or virtual private gateways. The customer has complete control over their virtual networking environment, including selection of their own IP address range, creation of subnets, and configuration of route tables and network gateways.

Customers can easily customize the network configuration for their Amazon VPC. For example, they can create a public-facing subnet for their web servers that has access to the internet and place their backend systems such as databases or application servers in a private-facing subnet with no internet access. They can leverage multiple layers of security, including security groups and network access control lists (ACLs), to help control access to Amazon EC2 instances in each subnet.

Additionally, customers can create a hardware VPN connection between their corporate data center and their Amazon VPC, and leverage the AWS Cloud as an extension of their corporate data center.

Security Groups and Network ACLs

There are two features that you can use to increase security for your Amazon VPC:

  • Security groups, which act as a firewall for associated Amazon EC2 instances, controlling both inbound and outbound traffic at the instance level.

  • Network ACLs, which act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level.

When you launch an instance in a VPC, you can associate one or more security groups that you’ve created. Each instance in your VPC could belong to a different set of security groups. If you don’t specify a security group when you launch an instance, the instance automatically belongs to the default security group for the VPC. For more information about security groups, see the Security Groups for Your VPC section of the Amazon VPC User Guide.

You can secure your VPC instances using only security groups, or you can add network ACLs as a second layer of defense. For more information about network ACLs, see the Network ACLs section of the Amazon VPC User Guide.

You can use AWS Identity and Access Management (IAM) to control who in your organization has permission to create and manage security groups and network ACLs. For example, you can give that permission to your network administrators, but not to personnel who only need to launch instances. For more information, see the Controlling Access to Amazon VPC Resources section of the Amazon VPC User Guide. Amazon security groups and network ACLs don’t filter traffic to or from link-local addresses (for example, or AWS reserved addresses (the first four IP addresses and the last one in each subnet). These addresses support the following services: Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), Amazon EC2 instance metadata, AWS Key Management Service (AWS KMS) for license management of Windows instances, and routing in the subnet. You can implement additional firewall solutions in the instances to block network communication with link-local addresses.

This table summarizes the basic differences between security groups and network ACLs:

Security group Network ACL
Operates at the instance level (first layer of defense) Operates at the subnet level (second layer of defense)
Supports allow rules only Supports allow rules and deny rules
Is stateful: Return traffic is automatically allowed, regardless of any rules Is stateless: Return traffic must be explicitly allowed by rules
Evaluates all rules before deciding whether to allow traffic Processes rules in numerical order when deciding whether to allow traffic
Applies to an instance only if someone specifies the security group when launching the instance, or associates the security group with the instance later on Automatically applies to all instances in the subnets it’s associated with (backup layer of defense, so customers don’t have to rely on someone specifying the security group)

VPC Flow Logs

VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. Flow log data is stored using Amazon CloudWatch Logs. After you create a flow log, you can view and retrieve its data in CloudWatch Logs.

Flow logs can help you with a number of tasks; for example, to troubleshoot why specific traffic is not reaching an instance, which, in turn, can help you diagnose overly restrictive security group rules. You can also use flow logs as a security tool to monitor the traffic that is reaching your instance.

Remote Administration

Components for remote administration include:

  • Amazon VPC with network ACLs for provisioning a private, isolated section of the AWS Cloud for launching services.

  • Amazon EC2 for launching virtual machine instances. This deployment uses the m4.xlarge instance type for RD Gateway instances and the t2.small instance type for network address translation (NAT) instances.

  • Microsoft Windows Server 2012 R2.

  • Remote Desktop Gateway (RD Gateway), which uses RDP for remote Windows administration.

This Quick Start uses an Amazon Machine Image (AMI) with preconfigured settings to set up remote Windows administration using the Remote Desktop Protocol (RDP) in your AWS account in minutes. You can use the trial deployment for up to 60 days. When you are ready for production or if you want to customize your deployment, follow the instructions in the Quick Start deployment guide for Remote Desktop Gateway.

Architecture components

The architecture is deployed into the US West (Oregon) region by default, but you can change the region of a Quick Start during launch. To customize the configuration or to deploy RD Gateway into an existing Amazon VPC, see the Quick Start deployment guide for Remote Desktop Gateway.


  • High availability – Critical workloads are deployed into two private Amazon VPC subnets in separate Availability Zones to ensure high availability.

  • Security – Components such as web servers, application servers, database servers, and domain controllers are placed in separate tiers for effective traffic management. Internal and other non-internet facing servers are placed in private subnets to prevent direct access from the internet.

  • Remote administration – The RD Gateway uses RDP over HTTPS to establish a secure, encrypted connection between remote users and Windows-based Amazon EC2 instances without needing to configure a VPN connection. This architecture helps reduce the attack surface on your Windows-based instances while providing a remote administration solution. For information about configuring RDP over HTTPS, see the Quick Start deployment guide for Remote Desktop Gateway.

Users and administrators can connect from an on-premises facility over a VPN and/or dedicated private network using the architecture shown in Figure 7.

          Remote administration architecture on AWS

Figure 7: Remote administration architecture on AWS

Principle of Least Privilege

When you create AWS IAM policies, you should follow the standard security advice of granting least privilege—that is, granting only the permissions required to perform a task. Essentially, determine what your users need to do, and then craft policies for them that let the users perform only those tasks. It’s more secure to start with a minimum set of permissions and grant additional permissions as necessary, rather than starting with permissions that are too lenient and then trying to tighten them later. Defining the right set of permissions requires some research to determine what is required for the specific task, what actions a particular service supports, and what permissions are required in order to perform those actions.

Windows Architectural Considerations on AWS

Key architectural considerations include the following:

  • Regions and Availability Zones

  • Installing critical workloads in at least two Availability Zones

  • Placing application servers in private subnets

Regions and Availability Zones

AWS data centers are built in clusters in various global AWS Regions. You can decide which AWS Region(s) house your data, and how long the data remains there. AWS provides you with the flexibility to place instances and store data within multiple geographic Regions, as well as across multiple Availability Zones within each Region.

The AWS products and services that are available in each region are listed in the Region Table on the AWS website.

Each AWS Region contains multiple distinct locations called Availability Zones. Each Availability Zone is engineered to be isolated from failures in other Availability Zones and to provide inexpensive, low-latency network connectivity to other zones in the same region. By launching instances in separate Availability Zones, you can protect applications from the failure of a single location.

For a list of AWS Regions and Availability Zones, see AWS Global Infrastructure on the AWS website.

Install Critical Workloads in at Least Two Availability Zones

This Quick Start deploys critical workloads into two or more private Amazon VPC subnets in separate Availability Zones to ensure high availability. Although Availability Zones provide service-level agreements (SLAs) for Amazon EC2, Amazon S3, Amazon CloudFront, Amazon Route 53, and Amazon Relational Database Service (Amazon RDS), and support a redundant architecture for core services per Availability Zone, designing for multiple Availability Zones ensures that a single Availability Zone outage will not affect production workloads. Because Availability Zones support single-millisecond latency between each other, they enable application architectures that assume a single physical location.

AWS currently provides SLAs for several products. Due to the rapidly evolving nature of AWS’s product offerings, we recommend that you review the SLAs on the AWS website; for example, at for Amazon EC2.

Place Application Servers in Private Subnets

From an application perspective, Availability Zones are transparent. The application will need to know only about subnets. In Amazon VPC, subnets can span multiple Availability Zones. Placing application servers in private subnets provides two benefits:

  • Tying subnet definitions to different Availability Zones increases availability.

  • Using private subnets ensures that application servers and their data are accessible only through security group firewall rules and network ACLs that manage ingress/egress at a subnet level.

Active Directory Hybrid Deployments

Figure 8 provides an example of using an Amazon VPC and a virtual private gateway to enable communication with your own network over an IPsec VPN tunnel. Active Directory is deployed in the customer data center, and Windows Server instances are deployed into two Amazon VPC subnets. After deploying the VPN connection, you can promote the Windows instances to domain controllers in the on-premises Active Directory forest, making Active Directory Domain Services highly available in the AWS Cloud.

            Reference architecture for an Amazon VPC extended to an on-premises network

Figure 8: Reference architecture for an Amazon VPC extended to an on-premises network

After deploying the VPN connection and promoting servers to domain controllers, you can launch additional instances into the empty Amazon VPC subnets in the web, application, or database tiers. These instances will have access to cloud-based domain controllers for secure, low-latency directory services and DNS. All network traffic, including Active Directory Domain Services communication, authentication requests, and Active Directory replication, is secured either within the private subnets or across the VPN tunnel.

For detailed information about extending your on-premises AD DS to the AWS Cloud, see the Quick Start deployment guide for AD DS.

Managing and Monitoring Windows Instances and Applications

Amazon CloudWatch will monitor instances in real time with standard and custom alarms on events. Standard monitoring includes capturing and setting rules around metrics and performance counters such as CPU utilization, disk read/write operations, bytes read/written, status checks, network-in/out, etc. In addition, you can export all Windows Server messages in the system, security, application, and Internet Information Services (IIS) logs to CloudWatch Logs and monitor them using Amazon CloudWatch metrics. EC2Config adds the ability to export any event log data, Event Tracing (Windows), or text-based log files to CloudWatch Logs. In addition, you can export performance counter data to Amazon CloudWatch. To manage the performance counters and logs for multiple instances, you can use Amazon EC2 Simple Systems Manager (SSM).

Managing Applications in Systems Center Operations Manager

In addition to managing AWS and operating system metrics, it is a best practice to run Systems Center Operations Manager (SCOM) with the Management Packs that Microsoft has released. SCOM provides a management platform for monitoring and taking action on server events. Microsoft has released SCOM Management Packs for the servers and technologies deployed by this Quick Start. These Management Packs are useful in a physical or virtual environment and are designed to provide application-level guidance above and beyond the infrastructure layer.