By Rajat Bhargava Posted January 22, 2016
Many cloud-forward organizations are leveraging both Google Apps and AWS. Not surprisingly, these products serve two different functions: productivity and production. An organization’s email and productivity infrastructure needs may be met by Google Apps via their cloud-based Apps suite, while their production infrastructure is often hosted at AWS. Each of these pieces of the IT infrastructure is critical. Which one is more important? That would be hard to argue either way, and therein lies the problem. Do you let Google control your identities and federate them to AWS, or do you let AWS control your identities and federate them to Google? Google Apps Directory is pitted against AWS Directory Services, so to speak.
The Disconnect Between Google and AWS
After digging further into the problem, the obvious question is: how does an organization manage its identity infrastructure? Users need to be managed across both major services – Google and AWS. All users may not need access to AWS servers, but nearly the entire organization needs to access Google Apps. In fact, a case could be made to utilize Google Apps Directory as the core identity and access control solution. Unfortunately, Google Apps Directory is not a true directory service. It doesn’t provide authentication capabilities for devices such as those found on-premises and in the cloud at, say, AWS. So, while the identity source could be Google, it wouldn’t connect to AWS.
With AWS Directory Service, organizations can get a full-blown Samba instance. Samba functions much like Active Directory. It handles Windows devices reasonably well, but struggles with Linux. If you are interested in managing devices with policies, then you, too, will tussle with AWS Directory Service. Here’s another thing to consider: there is no interface to the solution. You’ll need to leverage Windows Server tools if you want to manage Samba at AWS. Finally, there is the issue of AWS Directory Service only working within AWS; it doesn’t connect to Google Apps.
DaaS Makes the Connection Between Systems, Applications, and Networks
The challenge really doesn’t lie in making a decision between Google Apps Directory versus AWS Directory Service. These services can be used within their own figurative four walls, but they don’t t lend much support in the way of being an Identity-as-a-Service type of solution. If organizations would like to leverage one cloud-based directory service to connect to Google Apps, AWS, applications (cloud and on-premises), networks, and systems, neither of these solutions will work. Luckily, there is a new identity and access management platform that solves this issue. What is it? It’s called Directory-as-a-Service (DaaS), and it’s a cloud-based directory service. DaaS integrates with both Google Apps and AWS, so you don’t have to choose one or the other. It also connects to all of your on-premises systems, cloud applications, and WiFi networks. DaaS truly is a centralized user management platform for all of the IT resources a user needs.
If you would like to learn more about how you can leverage a cloud-based directory service, drop us a note. We’d be happy to discuss how Google Apps, AWS Directory Service, and Directory-as-a-Service all work as well as the pros and cons of each.