By Vince Lujan Posted October 25, 2017
What is AWS Directory Service? AWS Directory Service offers multiple identity management solutions for Amazon Web Services (AWS) such as AWS Microsoft AD, AWS AD Connector, and Simple AD to suit different use cases. Each offering solves a different part of the problem for IT admins and DevOps engineers in managing user access to AWS resources.
The primary purpose of the AWS Directory Service solutions are for connecting user identities to AWS resources. However, most organization’s prefer the AWS Directory Service solutions that are built from Microsoft Active Directory® (AD) to complement their existing on-prem AD instances and extend on-prem AD identities to AWS resources. This is especially true for larger organizations with more mature IT infrastructures.
Summary of AWS Directory Service
While Amazon Cognito can manage mobile devices, and Simple AD and AWS Cloud Directory can manage siloed AWS resources, one could argue the main use case for AWS Directory Service is to allow IT administrators and DevOps engineers to extend Active Directory identities to AWS resources. This is because there are a lot of organizations that already use AD as their core directory service. So it made sense for AWS to have the ability to easily integrate with AD.
Integrating AWS with AD is possible with either AWS Microsoft AD or the AWS AD Connector. Both of which require an existing AD instance to operate. The primary benefit with implementing AWS Directory Service is that organizations can now extend AD identities and management capabilities to AWS resources.
Without the AWS Directory Service, both AD and AWS would be siloed to their respective resources and would have to be managed separately. Yet, with so many options, which solution for connecting users to AWS resources is right for your organization?
Pros and Cons of AWS Directory Service
AWS Microsoft AD
AWS Microsoft AD is effectively a traditional Active Directory instance hosted in the cloud. The difference being that AWS takes some of the heavy lifting out of setting up an AD server, AD domain controllers, and configuring them with the ability integrate with AWS resources. With this approach, IT admins can take advantage of most of the native functionality offered by AD for managing resources on AWS.
The challenge with AWS Microsoft AD is this flavor of AWS Directory Service is limited to connecting AWS AD identities living in the cloud to AWS resources. Remember that Active Directory works on the direct connect model – the IT resources that it is managing need to be able to directly connect to AD.
The primary reason that AWS decided to include AWS Microsoft AD was to enable IT organizations to leverage AWS WorkSpaces. AWS WorkSpaces offers server access and a desktop-as-a-service solution (primarily Microsoft-based resources). The two solutions working together can provide IT admins with the ability to control user access at the hosted server and desktop level.
While it is possible to extend AWS Microsoft AD identities beyond AWS resources, additional AWS solutions will be required. In essence, AWS gives you AD with AWS Microsoft AD, but won’t let you realize its full potential without purchasing more AWS services.
AWS AD Connector
The AWS AD Connector is a great example of an additional AWS service that will be required to get the most out of your on-prem AD within AWS. The AWS AD Connector is another means of extending AD identities to AWS resources. With this approach, IT admins can extend AD identities from an existing on-prem AD instantiation to AWS resources in the cloud. It can also be used as an AD bridge to mirror an on-prem AD instance into AWS Microsoft AD.
The advantages with this approach are that organizations can continue to leverage their existing on-prem AD infrastructure, without the limitations of AWS Microsoft AD, while gaining the ability to extend on-prem AD identities to resources living in the cloud. Additionally, AD identities can either be extended directly to AWS resources, or synced with an AWS Microsoft AD instance to provide added layers of redundancy should the on-prem AD instance fail.
The main issue with this approach is organizations must have an existing AD infrastructure already in place on-prem, or spend a huge amount of time and money setting one up. While this may not be a challenge for larger organizations with more mature IT infrastructures, it does present a huge hurdle for smaller cloud-forward organizations.
Furthermore, this approach has two major limitations, among others. For one, the AWS AD Connector again is only for extending AD to AWS resources. That means additional solutions will be required to connect to resources outside of AWS.
Additionally, organizations are stuck with the native limitations of Active Directory itself. These limitations include limited user management capabilities for Mac and Linux users, non-existent device management capabilities for Mac and Linux systems, limited support for cloud applications (e.g. Box, Zendesk, Salesforce), networks (wired & WiFi), and a lot more. IT admins and DevOps engineers should understand that this is really a version of a cloud identity bridge, but with very limited scope – realistically AWS Windows resources.
That means yet even more solutions will be required just to manage the resources most modern organizations use on a daily basis. The costs of which can certainly add up quickly.
AWS Simple AD
This is where a third AWS Directory Service option, AWS Simple AD, comes into play for organizations that have limited to no investment with AD. AWS Simple AD is a basic AWS directory platform inspired by Active Directory, but serves as an AD alternative. It can provide simple management tools for organizations that might not need the full capabilities of Active Directory at a far more cost effective price point.
However, it is important to note that while Simple AD is inspired by AD, it is fundamentally different. For example, Simple AD is built from Samba 4, not Active Directory (even though AD is in the name).
The result is that Simple AD cannot integrate with existing AD instances, either on-prem or even with AWS Microsoft AD. What IT admins are left with is a Simple AD solution that feels a lot like AD but does not share the most powerful capabilities of AD like Group Policy, trust relationships, and more.
Which AWS Directory Service Option is Best?
The bottom line is that AWS has a lot of great resources. The challenge is connecting user identities to those resources. The current offerings from AWS Directory Service require IT admins to choose between what is effectively Samba (e.g. Simple AD) that is drastically limited in scope, or integrating with a costly and difficult to manage AD implementation on top of requiring AWS Directory Service solutions (e.g. AWS Microsoft AD or AD Connector).
While these solutions can be great for organizations that only leverage AWS, or who have already invested in AD, neither is all that great for smaller cloud-forward organizations leveraging a variety of cloud resources from different providers. Fortunately, a powerful solution called Directory-as-a-Service® from JumpCloud was created to help those organizations caught in the middle.
Directory-as-a-Service vs. AWS Directory Service
Directory-as-a-Service by JumpCloud is a cloud-based directory service platform designed for the modern organization. It is effectively the cloud alternative for AD, but takes a considerably more streamlined approach to connecting JumpCloud user identities to resources at AWS and a lot more.
Directory-as-a-Service integrates directly with AWS servers via the JumpCloud agent. With the agent installed, users can gain access to the server with their core JumpCloud identity.
For more fine grained control, IT admins can also leverage the JumpCloud AWS Single Sign-On (SSO) connector to extend JumpCloud identities into the AWS IAM solution.
This SAML based connector enables organizations to securely federate user identities to the AWS web console, which admins can then leverage to configure individual user permissions to AWS resources. The result is that organizations are empowered to connect their users to AWS resources without the complexity and costs of the AWS Directory Service.
The Directory-as-a-Service approach offers additional advantages as well. One huge advantage is that the Directory-as-a-Service makes it possible for organizations to completely eliminate Active Directory from the picture. That alone should come as a welcome relief for a lot of IT administrators.
With this approach, JumpCloud becomes the source of truth for user identities. Identities which can then be leveraged to gain access to resources on AWS and beyond. This empowers organizations to take control of the breadth of their digital assets.
These resources can include like cloud resources from AWS and beyond (e.g. G Suite, Office 365, Azure), disparate systems (Windows, Mac, Linux), web applications (e.g. Box, Zendesk, Salesforce), on-prem applications (e.g. Jenkins, Jira, OpenVPN), networks (e.g. wired and WiFi), Samba and NAS devices (e.g. Synology, FreeNAS, QNAP), and much more.
Sounds pretty good right? But wait, there’s more.
For organizations that are not ready to break up with Active Directory, Directory-as-a-Service also seamlessly integrates with AD via JumpCloud Active Directory Integration. JumpCloud Active Directory Integration enables organizations to continue leveraging their on-prem AD infrastructure as their source of truth. Organizations can then federate on-prem AD identities into JumpCloud, which can then be extended to resources on AWS (and more).
The best part is that either approach can provide the full functionality of the Directory-as-a-Service platform at one flat rate.
Learn more about Directory-as-a-Service vs. AWS Directory Service
To learn more about what AWS Directory Service is, and how Directory-as-a-Service stacks up, drop us a note. You can also sign up and start extending user identities to AWS resources today. Your first ten users are on us so that you can see just how powerful Directory-as-a-Service can be.