Five Functional Facts about AWS Identity and Access Management
This post is part of an open-ended series I’m writing where I take a specific protocol, app, or whatever-I-feel-like and focus on five functional aspects of that thing in order to expose some of how that thing really works.
The topic in this post is the AWS Identity and Access Management (IAM) service. The IAM service holds a unique position within AWS: it doesn’t get the attention that the machine learning or AI services get, and doesn’t come to mind when buzzwords like “serverless” or “containers” are brought up, yet it’s used by–or should be used by–every single AWS customer (and if you’re not using it, you’re not following best practice, tsk, tsk) so it’s worthwhile to take the time to really get to know this service.
Let’s begin!
1 – The root user supersedes IAM policies
The main reason I threw a bit of shade about following best practice and always using IAM has to do with the root user in an account. The root user is what’s created when a new AWS account is opened. The username for the root user is always an email address and the root user is able to log into the AWS account Continue reading