Choosing the Correct AWS Directory Service Option


One of the areas that Amazon Web Services certainly excels at is in providing options for its customers. This is evident by visiting the AWS Products and Services page and reviewing the wide array of AWS services and features available for you to use in your applications.

It is both amazing and overwhelming at the same time. Where do you start? What services do you need? Do you need a traditional relational database or are you looking for a NoSQL option? Do you want to install, monitor and patch the service yourself on Elastic Cloud Compute (EC2) instances? Or do you want to leverage one of AWS’s managed services and let Amazon do the heavy lifting for you?

AWS Directory Service is one of AWS’s managed services. It provides a fully managed, highly available directory service for customers who require Microsoft Active Directory in the cloud but don’t want the associated overhead of managing their own AD cluster. But when you choose AWS Directory Service, you are presented with another choice: which directory type to use?

In this blog post, I’ll review the AWS Directory Service directory types available to you and how to choose between them. When you’re done reading this, you’ll be armed with the right information to make the correct choice for your application. Let’s get started.

What AWS Directory Service options are there?

AWS Directory Service provides three different options, or directory types, which are each purpose-built for specific workloads (for the purpose of this discussion, I’m not considering AWS Cloud Directory of Amazon Cognito, which might also be considered different types of directories). The directory types are:

  • AD Connector — uses your existing on-premise Microsoft Active Directory to access AWS applications and services like Workspaces, WorkDocs and Workmail. AD Connector proxies (no caching is done on AWS) Kerberos and LDAP requests from these applications to your on-premises directory to authenticate users. AD Connector also allows your EC2 instances to seamlessly join your existing domain, but cannot be utilized by other Windows workloads or applications.
  • Simple AD — a Microsoft Active Directory–compatible directory that is powered by Samba 4 and hosted on the AWS cloud. Simple AD provides commonly used Active Directory features such as user accounts, group memberships, domain-joining EC2 instances running Linux and Microsoft Windows, Kerberos-based SSO and group policies, but does not allow you to set up trust relationships to your on-premises directories.
  • Microsoft AD — also known as AWS Directory Service for Microsoft Active Directory (Enterprise Edition) Microsoft AD is a Microsoft Active Directory hosted on the AWS Cloud. AWS Microsoft AD includes most Active Directory features, including support for multi-directional trusts, group based policy administration, SSO and seamless domain join for your EC2 instances running in the cloud.

Which AWS Directory Service directory type should you choose?

Your choice of AWS Directory Service type generally depends on two things: size and complexity:

How many AD users and objects do you have?

First, you need to know how many AD users and objects will be supported by your system. Consider system growth and your future plans when coming up with this number. That number will determine which of the AWS Directory service types are available to you. Less than 5k users/20k objects? All AWS Directory Service types are available to you. More than 50k users/200k objects? You might need to use Active Directory on EC2.

What AD functionality do you need?

Next, what specific AD functionality does your system require? Generally speaking, the simpler your AD requirements are, the more options available. For example, if you require authentication for custom .Net applications, you can’t use AD Connector. If you want to establish trusts with other AD domains or AWS services, you can only use Microsoft AD. The functionality you require will help you further narrow your choices and guide you to the option that is right for you.

This table will help as you are deciding on the right option. I’ve also include AD on EC2 for functional comparison:

Feature AD Connector Simple AD Microsoft AD AD on EC2
Authenticate sign on requests from AWS applications like Amazon WorkSpaces, Amazon WorkDocs, or Amazon WorkMail. Yes (proxy) Yes Yes Yes*
Domain join EC2 instances running Linux and Microsoft Windows Yes (proxy) Yes Yes Yes*
Enable single sign-on (SSO) to the AWS Management Console using existing AD credentials Yes (proxy) Yes Yes Yes*
Support for up to 5,000 users and 20,000 objects Yes Yes Yes Yes
Authenticate sign on requests from directory-aware Microsoft workloads, including custom .NET and SQL Server-based applications Yes Yes Yes
Common Active Directory features such as user accounts, group memberships, and group policies Yes Yes Yes
Advanced Active Directory features such as DNS dynamic updates, Active Directory Administrative Center, PowerShell support, Active Directory recycle bin, group managed service accounts, and schema extensions for POSIX and Microsoft applications Yes Yes
Setup trust relationships with other Active Directory domains Yes Yes
Establish trust with other AWS directories Yes Yes
Support for up to 50,000 users and 200,000 objects Yes Yes
Active Directory schema modifications, communication over LDAPS, PowerShell AD cmdlets, and the transfer of FSMO roles Yes
Active Directory replication Yes
Support for more than 50,000 users and 200,000 objects Yes
Windows Authentication to authenticate users when they connect to an Amazon RDS DB instance running Microsoft SQL Server Yes

* Requires AD Connector

The choice is yours

That’s it. You’re now ready to choose the AWS Directory Service option that’s appropriate for your application. If you’d like additional guidance specific to your needs or have further questions while deciding on the best option for you, reach out to me at Rackspace or @awsgeek. I’d be happy to help you on your journey to the cloud. It’s what I do!

For more information on AWS Directory Service, visit the AWS Directory Service product page.

Jerry Hargrove is a Senior Solutions Architect on the Fanatical Support for AWS team at Rackspace. He works with Rackspace customers, helping them architect and implement super scalable and highly available solutions in the AWS cloud. Prior to joining Rackspace, Jerry worked as a Solutions Architect at Amazon Web Services and as a software architect and developer. Jerry brings more than 20 years of software architecture and development experience to the Rackspace team and has worked in a broad cross-section of the software industry in a variety of settings. When not at work, he enjoys spending time with his family and is an avid hiker, climber and back-country skier.



Please enter your comment!
Please enter your name here