Active Directory Domain Services on AWS
Active Directory DS Quick Start

Active Directory Design

If you’re managing your own AD DS infrastructure (scenario 1 or scenario 2), review the following sections for key design considerations.

Site Topology

Active Directory site topology allows you to logically define your physical and virtual networks. Active Directory replication sends directory changes from one domain controller to another, until all domain controllers have been updated. Site topology controls Active Directory replication between domain controllers within the same site and across site boundaries. Replication traffic between sites is compressed and replication is performed on a schedule based on a site link. Additionally, domain controllers use the site topology to provide client affinity, meaning that clients located within a specific site will prefer domain controllers in the same site.

Site topology is a crucial design consideration when running AD DS in the AWS Cloud. A well-designed site topology allows you to define subnets that can be associated with the Availability Zones within your VPC. These associations help ensure that traffic—such as directory service queries, AD DS replication, and client authentication—uses the most efficient path to a domain controller. They also provide you with granular control over replication traffic.

Figure 4 shows an example of site and subnet definitions for a typical AD DS architecture running within a VPC. Active Directory sites (AZ1 and AZ2) have been created in the Active Directory Sites and Services snap-in. Subnets have been defined and associated with their respective site objects.

				Active Directory Sites and Services configuration

Figure 4: Active Directory Sites and Services configuration

By creating Active Directory sites that represent each Availability Zone in the VPC, subnets associated with those sites can help ensure that domain-joined instances will primarily use a domain controller closest to them. This is also a key design configuration for maintaining a highly available AD DS deployment.

Highly Available Directory Domain Services

Even in the smallest AD DS deployments, we recommend implementing at least two domain controllers in your AWS Cloud environment. This design provides fault tolerance and prevents a single domain controller failure from impacting the availability of the AD DS. In order to provide higher availability, we recommend that you implement domain controllers in at least two Availability Zones.

To further support the high availability of your architecture and help mitigate the impact of a possible disaster, we also recommend placing global catalog servers and Active Directory DNS servers in each Availability Zone. Global catalogs provide a mechanism for forestwide searches and are required for logon authentication in forests with multiple domains. If you do not have a global catalog and a DNS server in each Availability Zone, AD DS queries and authentication traffic could cross Availability Zones. Although this is not technically an issue during normal operations, full AD DS service availability could be impacted by a single Availability Zone failure.

To implement these recommendations, we suggest that you make each domain controller a global catalog and DNS server. This configuration allows AD DS in each Availability Zone to operate independently, and helps ensure that AD DS availability is not impacted in the unlikely event of disaster. If an Availability Zone in this architecture is cut off from other resources in the region, instances within the Availability Zone still have a local domain controller that can authenticate users, perform service directory lookups, and resolve DNS queries.

The requirements of a smaller environment might make a single Availability Zone more appealing. Even though a single Availability Zone AD DS design is not our recommendation, we realize that this may be the chosen architecture. In this case, we recommend that you deploy at least two domain controllers in your Availability Zone to provide redundancy.

The AWS CloudFormation template provided for scenario 1 will build out an Active Directory Sites and Services configuration for you automatically that will support a highly available AD DS architecture. If you plan to deploy AD DS manually, make sure that you properly map subnets to the correct site to help ensure that AD DS traffic uses the best possible path.

For detailed guidance on creating sites, adding global catalog servers, and creating and managing site links, see the Microsoft Active Directory Sites and Services documentation.

Read-Only and Writable Domain Controllers

Read-Only domain controllers (RODCs) hold a copy of the AD DS database and respond to authentication requests, but applications or other servers cannot write to them. RODCs are typically deployed in locations where physical security cannot be guaranteed. For example, in an on-premises scenario, you might deploy an RODC in a remote branch office where the physical server cannot be protected by a secure, locked closet or server room.

Writable domain controllers operate in a multi-master model; changes can be made on any writable server in the forest, and those changes are replicated to servers throughout the entire forest. Several key functions and Microsoft enterprise applications require connectivity to a writable domain controller.

If you are planning to deploy enterprise application servers into the AWS Cloud, an RODC may not be a viable option. For example, an RODC cannot process a password reset for an end user, and Microsoft Exchange Server cannot use an RODC to perform directory look-ups. Make sure you understand the requirements of the application, the dependencies on AD DS, and compatibility before considering RODCs.

Active Directory DNS and DHCP inside the VPC

With a VPC, Dynamic Host Configuration Protocol (DHCP) services are provided by default for your instances. DHCP scopes do not need to be managed; they are created for the VPC subnets you define when you deploy your solution. These DHCP services cannot be disabled, so you'll need to use them rather than deploying your own DHCP server.

The VPC also provides an internal DNS server. This DNS provides instances with basic name resolution services for internet access and is crucial for access to AWS service endpoints such as AWS CloudFormation and Amazon Simple Storage Service (Amazon S3) during the bootstrapping process when you launch the Quick Start.

Amazon-provided DNS server settings will be assigned to instances launched into the VPC based on a DHCP options set. DHCP options sets are used within an Amazon VPC to define scope options, such as the domain name or the name servers that should be handed to your instances via DHCP. Amazon-provided DNS is used only for public DNS resolution.

Since Amazon-provided DNS cannot be used to provide name resolution services for Active Directory, you'll need to ensure that domain-joined Windows instances have been configured to use Active Directory DNS.

As an alternative to statically assigning Active Directory DNS server settings on Windows instances, you have the option of specifying them using a custom DHCP options set. This will allow you to assign your Active Directory DNS suffix and DNS server IP addresses as the name servers within the VPC via DHCP.


The IP addresses in the domain-name-servers field are always returned in the same order. If the first DNS server in the list fails, instances should fall back to the second IP and continue to resolve host names successfully. However, during normal operations, the first DNS server listed will always handle DNS requests. If you want to ensure that DNS queries are distributed evenly across multiple servers, you should consider statically configuring DNS server settings on your instances.

For details on creating a custom DHCP options set and associating it with your VPC, see Working with DHCP Options Sets in the Amazon VPC User Guide.


For scenario 1 and scenario 3, the AWS CloudFormation template configures the DHCP options set with the Active Directory domain controllers as the name servers, as recommended by the AWS Directory Service documentation. This means that instances that need to join the domain will automatically be able to join, without requiring any changes.

DNS Settings on Windows Server Instances

To make sure that domain-joined Windows instances will automatically register host (A) and reverse lookup (PTR) records with Active Directory-integrated DNS, set the properties of the network connection as shown in Figure 5.

				Advanced TCP/IP Settings on a domain-joined Windows instance

Figure 5: Advanced TCP/IP settings on a domain-joined Windows instance

The default configuration for a network connection is set to automatically register the connections address in DNS. In other words, as shown in Figure 5, the Register this connection's addresses in DNS option is selected for you automatically. This takes care of host (A) record dynamic registration. However, if you do not also select the second option, Use this connection's DNS suffix in DNS registration, dynamic registration of PTR records will not take place.

If you have a small number of instances in the VPC, you may choose to configure the network connection manually. For larger fleets, you can push this setting out to all your Windows instances by using Active Directory Group Policy. For step-by-step instructions. see IPv4 and IPv6 Advanced DNS Tab in the Microsoft TechNet Library.