A Few Things That Made AWS IAM Click for Me

I’ve been going through AWS IAM recently, and at first I found it more confusing than I expected.

The individual terms are not that difficult. A user is a user, a policy contains permissions, a role can be assumed. The confusing part was understanding how all of these pieces fit together when an actual request is made.

What helped me was to stop thinking about IAM as a list of AWS features and instead think about one question:

From there, policies started making more sense. They are basically the rules AWS checks when something tries to access a resource.

The other thing I initially misunderstood was roles. I was thinking of them almost like another type of user. What made the distinction clearer was the idea that a role is something an identity or service can assume when it needs a specific set of permissions.

For example, if an EC2 instance needs to read something from S3, putting long-lived access keys inside the application would be a pretty bad solution. Giving the instance a role for that job makes much more sense.

Least privilege also sounds almost too obvious when you first read about it: only give something the permissions it actually needs.

But once I started looking at IAM policies, I could see why it matters. Giving s3:* is easy. Figuring out the few actions and resources that are actually required takes more work.

That seems to be a recurring theme in security in general. The convenient configuration is often not the one you would want to keep.

I’m still very early into AWS, so I’m definitely not pretending to have IAM figured out yet. Policy evaluation and cross-account access are probably the next parts I want to understand properly.

But the “who is doing what, against which resource?” mental model already made IAM feel much less abstract.