By Rajat Bhargava Posted July 16, 2015
At least once a week we hear prospects and customers ask us about the idea of placing a Microsoft Active Directory instance within AWS (or Google Compute Engine for that matter). Some are IT admins, some are DevOps personnel or sys admins, and some are even developers – but the reasons they give are all largely the same.
Reasons to Place AD within AWS
- User management in the cloud is painful
- Windows user management is a lot harder than Linux even if you use configuration automation solutions like Chef and Puppet
- We don’t want to open up our on-premises Active Directory instance to the Internet
- The overhead of networking every cloud server instance back to our on-premises directory seems like too much work
With those challenges and others, they reach the conclusion that maybe it’s just easier to drop another Active Directory instance into the cloud infrastructure. We can see where they’re coming from and clearly that is one option. If the infrastructure is more Linux-based, OpenLDAP becomes an option as well.
But just because you can place another instance of your existing AD/OpenLDAP directory in the cloud, that doesn’t mean you should.
Reasons Not to Place AD within AWS
When we speak with these IT admins, DevOps personnel, and sys admins, we offer the following advice: If there is already a central directory service within the organization, we strongly discourage the addition of another directory.
Why? Well to start, the whole goal of IT with directory services is to have one corporate identity per person, not multiple.
Second, Active Directory wasn’t designed to live in the cloud. This means that IT admins will have to build additional security mechanisms themselves in order to ensure that their identities stored in their Active Directory instance on a cloud server are safe. Ultimately, you’re trading more work for less security.
If there isn’t a central directory already available, we ask why they would want to create more work for themselves? If they are already thinking about cloud directory services, then why not choose a true SaaS-based platform?
Cloud-Based Directory Alternatives that Work
IT departments have a number of great reasons to have their identities available to cloud infrastructure like at AWS. But they can also achieve those goals without enduring the pain of trying to leverage a legacy, enterprise oriented directory service on the cloud.
There are far simpler alternatives. One is to have one central identity work on-premises and the cloud, seamlessly. Directory-as-a-Service is one such mechanism.
For those with an existing central directory, Directory-as-a-Service acts as a bridge to the cloud. The existing identities are securely bridged to AWS. Changes in the on-premises directory are updated in Directory-as-a-Service and subsequently to the AWS cloud servers.
For those that don’t have a directory on-premises, Directory-as-a-Service acts as the central, authoritative directory source for cloud infrastructure, but also for any on-premises infrastructure as well. The DaaS cloud directory can be connected to more than just AWS and can act as a true directory service for multiple applications, device platforms, and networks.
As you think about how you want to manage your identities in the cloud, Active Directory can be an option, just not a very good one. We would opine that there are far better ways to accomplish the goal of a central directory service to manage all of your infrastructure regardless of location.
Take a look at JumpCloud’s Directory-as-a-Service as a strong option. Drop us a note or sign-up for a free account and you can learn why it’s a better option than AWS and Active Directory.