Amazon IAM - The Backbone of AWS


IAM at a High-Level

Key Players of IAM 🧩

  • Resource: This is the (or really any) application/service that is worth protecting. Could be a SPA (Single-Page Application) hosted and stored via S3. An event-driven serverless API built using Lambda. A database in RDS. An always-up-and-running API built using containers (ECS or EKS).
  • Policy: This is the system(s) of rules that say what/who can or cannot do something on either a single resource, or a group of resources.
  • Action: The specific action(s) or anything someone can do inside the AWS Cloud environment. Could be something like: DELETE contents from a bucket(s), Create an IAM User, etc. the list goes on.
  • User: An IAM User (not to be confused with AWS database users). IAM Users belong to AWS Accounts. One of them being the Root user. NEVER use Root for ANYTHING!
  • Group: A set of users with the same permissions granted (or denied).
  • Principal: The actual user or application/service requesting access to a resource.
  • Role: A set of permissions provided to a principal. Typically for an allowed period of time, until the access is no longer required.

So.. Why is IAM being called the backbone of AWS? 🤔

  • You do not want a Lambda that uploads your monitoring logs to your log bucket to have WRITE access to your actual application bucket.
  • You do not want your automated Glue Job to overwrite the data snapshot in RDS for May 21. ONLY create new records for the day it has ran (i.e. May 22).
  • You would not want just any Redshift DB User to automatically have permissions to CreateGroup or JoinGroup once created.

Now, what does Amazon IAM provide? 🤔

  • Least-Privileged Access: Any user/entity is ONLY given the access it needs for a specific request. This helps enable granularity.
  • Granular Access: The set of permissions that dictate and control each action that can be applied on a resource. Quick example: An IAM User may have permissions to see an S3 Bucket, but might not have permissions to change bucket policies or the bucket contents itself. This is highly-tied an implemented via role-based access management.
  • Authentication: Telling something (or someone) and verifying who you are. Or what is the application/service trying to connect.
  • Authorization: Once authenticated, process of identifying whether something or someone can perform the action(s) they are requesting to make.
  • Governance: The process or set of action AWS Account Administrators in organizations implement to know what is happening within their company’s AWS Accounts. For security, compliance, and budgetary purposes to ensure least-privileged access.

So, what happens if IAM is not implemented? 🔥🔥🔥

Increased Risk of Insider Threats 👾

Arduous Account Setup & Time-Consuming (loss to business) 💸

Offboarding employees securely can be risky ⚠️

You’d need to use manual human intervention for the simplest changes 😠

Alright! I am sold on using IAM! Got any Best Practices to adhere to? 🤯

1) 🛡️NEVER Grant Full (*) Wildcard Access… EVER!

2) 🛡️Implement Groups instead of Multiple Users

3) 🛡️Implement RBAC on Existing Users for Creating New Users

4) 🛡️Audit Permissions Frequently

5) 🛡️Implement Permissions Boundaries early!

Closing thoughts 🏁

Want to learn more about AWS Cloud? Security?📝

AWS & Cloud Computing

12 stories

Secure Coding & Engineering

3 stories



Multi-disciplinary Technical Lead specialized in building products users love. Today, I manage & secure big data in the cloud. All views shared are my own.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Abdul Wahab

Multi-disciplinary Technical Lead specialized in building products users love. Today, I manage & secure big data in the cloud. All views shared are my own.