AWS Managed Active Directory, Day 2 Operations
Disclaimer: This is a personal weblog. The opinions expressed here represent my own and not those of my employer.
Part 1 – The 101: What is AWS Managed Active Directory
Introduction
In the previous blog post I brought you up to speed on what the AWS Managed Active Directory capability was and how to initially deploy within the AWS public cloud. This blog post is intended to build upon the first and discuss Day-2 type operations. Before I dive into these operations I’ll walk through a few design considerations which need consideration before deploying AWS Managed Active Directory.
A Few Design Considerations
When designing an environment, either in the cloud or on-premises it is very important to examine the requirements as well as the design considerations. When I read the use cases, best practices as well as the limits documentation. In the previous blog, I listed out the individual use cases in which AWS documents. In my lab, I operate within the US-West-1 Region and have VPC Peering setup with the US-East-1 Region. I figure that this best represents a similar setup to which a customer would have implemented where there’s multiple locations. This either satisfies a hot / hot style setup, for redundancy. Another scenario I envision would be active / standby for disaster recovery purposes.
As it relates to AWS Managed Active Directory this setup raises the first design consideration. Currently, AWS Managed Active Directory is able to be deployed within a single AWS Region – cross region is not yet supported. You’re still able to contact domain controllers within the Managed AD environment over the VPC Peering connection, you’re just not able to natively deploy DC’s in the other AWS Regions. This is less than ideal, what if the link between US-West-1 and US-East-1 is unavailable? Clients within US-East-1 would be unable to operate until proper connectivity was restored. As a workaround, while I have not officially tested this, in theory, I could launch another Managed Active Directory instance in US-East-1 and create a trust to the Managed AD environment. More to come on this topic as I test this out….Alternatively one could build EC2 instances and create their own domain / trusts with on-premises Active Directory too, this is a supported configuration.
AWS Managed Microsoft AD Limits
The last consideration I’ll mention is the hard limits of the Managed AD service. The following are the default limits for AWS Managed Microsoft AD. Each limit is per region unless otherwise noted.
| Resource | Default Limit |
|---|---|
| AWS Managed Microsoft AD directories | 10 |
| Manual snapshots | 5 per AWS Managed Microsoft AD – cannot be altered |
| Maximum number of domain controllers per directory | 20 |
Management Tasks
AWS makes it quite easy and very seamless to manage the domain after installation. For example, in the Instance Launch Wizard I have the ability to automatically add computers to the domain as part of the build process. I have built out a Windows Server 2016 image using the Amazon Windows 2016 AMI, done a few customizations which I do on all of my servers and then created an image. Just note here, with Windows – be sure to use the Create Image and uncheck the no reboot options.
Per AWS best practices you also, which I agree with, create within VPC, a DHCP Option Set with the necessary domain options defined (domain name, name servers, ntp servers, etc.). AWS Directory Service lets you run Microsoft Active Directory as a managed service. This means I cannot log in to the domain controllers themselves. Also, it means that I do not have Domain Admin rights to the root of the domain. AWS creates a delegated structure with pre-created groups and an ‘Admin‘ account. However, users have access to the full suite of Remote Server Administration Tools (RSAT) from Microsoft. This includes Active Directory Users & Computers, DNS, Active Directory Sites & Services and Group Policy Manager. Just note that with GPO’s you can’t edit the Default Domain Policy for instance, so I need to create specific GPO’s targeted at the delegated hierarchy. Below are a few screenshots to illustrate these topics.
Operating System patches are also an important topic too and AWS has recently a tool to help with this! AWS Systems Manager – This is a pretty cool piece of functionality which I’ll dig deeper into and write a separate blog post soon.
Summary
To quickly wrap things up, managing Active Directory within the AWS Managed AD offering is slightly different than what a customer might be used to on-premises. For instance, managing the domain controllers themselves and what are the intra-region requirements for instance. In summary, before embarking down this path you need to make sure that this is correct solution for you – however, AWS allows you to maintain control over what AD components matter the most to the business.
