AWS IAM Indecision

AWS IAM Indecision

May 7, 2018 0 By Eric Shanks

Identity and Access Management (IAM) can be a confusing topic for people that are new to Amazon Web Services. There are IAM Users that could be used for authentication or solutions considered part of the AWS Directory Services such as Microsoft AD, Simple AD, or AD Connector. If none of these sound appealing, there is always the option to use Federation with a SAML 2.0 solution like OKTA, PING, or Active Directory Federation Services (ADFS). If all of these option have given you a case of decision fatigue, then hopefully this post and the associate links will help you to decide how your environment should be setup.

IAM Users

Your first option is the easiest to configure but comes with a few risks. An IAM user is a username and password that is created in the AWS IAM Console. You can give IAM Users access to login to the console or through the API, but it also means that its a separate login from the account you probably use in your corporate environment. For example, you login to your laptop every morning with a corporate Active Directory login and then go to login to the AWS console with a completely different username or password. Maybe you’ve even decided to use the same username and password that is used with your corporate AD but they aren’t sync’d so you still need to manage them separately. While IAM Users are easy to setup, they provide a few challenges for enterprises who’d like to use a single login. There are other solutions available to limit operational complexity and the number of logins managed meaning fewer attack vectors.

Directory Services

AWS also provides a service called AWS Directory Service that provides several different options for authenticating both machines and users with your environment.

Simple AD – Simple AD is an option that provides a subset of Microsoft Active Directory services and is based on Samba 4. This service deploys a pair of domain controllers, with DNS, in a VPC across a pair of subnets for availability. The solution allows you to use this new directory as a Kerberos authentication source, but be aware that this solution doesn’t allow you to create a trust relationship with your existing domain if you have one. Think of this if you plan to setup a new domain for your AWS servers to belong to, but will still be managed separate from your on-premises domain. Simple AD has two sizes where a small directory can handle around 500 users / 2000 objects and a large size can manage 5000 / 20,000 objects.


Microsoft AD – As you’d guess Microsoft AD provides a full blown Microsoft AD which is deployed  in a similar fashion to Simple AD. A pair of Microsoft AD servers (2012 R2 as of now) are deployed across AZs to provide redundancy. Microsoft AD has an advantage over Simple AD where you can create a trust relationship with these new domain controllers to your existing Microsoft Active Directory environment. Be aware that your directory cannot be extended to this new Microsoft AD instance, a trust relationship can be created though. Microsoft AD also comes in two sizes where standard supports 5000 users / 30,000 objects and more than this would require the Enterprise option.


AD Connector – If you have the need to extend your existing on-premises active directory then you could consider AD Connector. AD Connector doesn’t authenticate your users directly, but rather forwards the requests on to your on-prem AD instances. This requires network connectivity between your VPC and your on-prem domain controllers for this to work, and if you lose your connectivity, logins will fail to work.



If you want to user your existing Active Directory solution for a login method for the AWS console or CLI, then federation might be your best bet. With federation, you can continue to use your existing corporate logins to login to the AWS control plane. Be aware though, that AD Federation won’t do anything for your computer objects that need a domain to join when they are spun up. This just allows for console authentication only.



If you’re still unsure, perhaps this table will help illustrate the differences.

 Limits the number of user Accounts?Used for User logins and computer accounts?Ability to create a Trust with on-premises AD?Requires Network Connectivity to corporate data center?
IAM UsersNo - New Users would be created in AWS ConsoleNo - Cannot manage computer accounts.NoNo
Simple ADNo - A new directory has to be maintainedYesNoNo
Microsoft ADYes - If a trust relationship is created with on-premises AD.YesYesNo - Unless a trust relationship is created to on-premises AD
AD ConnectorYesNo - Computer accounts are not managed with AD ConnectorN/AYes
ADFSYesNo - Only User authentiationN/AYes - requires network access from the AWS Console to the ADFS server. (over public Internet)
ADFS with Deployed Domain ControllersYesYes - ADFS for console access and the DCs for users/computer accountsYes - AD can be extended or a trust relationship added.Yes - If the directory on-prem has been extended to the AWS Servers or a trust is created



The following resources may help you with some facets of the setup of the directory services, how federation can be used with or without role switching and general info.

Setup of Simple AD

Setup of Microsoft AD

Setup of AD Connector

Setup of ADFS with AWS

AWS Federation with Role Switching