Whether you’re just stepping into the AWS universe or building cloud-native apps, there’s one service that touches everything: IAM (Identity and Access Management).
IAM is how AWS controls who can do what across your account. It’s more than just security – it’s the digital equivalent of your office’s keycard system, reception desk, and visitor log, all rolled into one.
This guide will walk you through IAM from the ground up, with no jargon overload – just simple explanations and easy examples.
What is IAM?
IAM is AWS’s security tool that lets you control who can access your AWS resources and what actions they can take. Think of it as the security system of your AWS account, helping you manage users, groups, and permissions safely in your cloud environment. IAM is the Backbone of AWS Security
IAM is your cloud’s security gatekeeper that allows you to:
– Define who can access your AWS resources
– Specify what actions they can perform
– Control how long they can access them
Let’s understand it with a simple Example: Think of IAM like the security staff in a corporate office:
– Every employee has an access card tailored to their department (i.e., Marketing, Development, Sales, etc), but each card only unlocks doors relevant to that person’s department.
– The cleaning crew can access the floors at night.
– Developers access the server room.
– Executives and managers get broader access.
Pro Tip: Always follow the principle of least privilege – grant only the necessary access to keep things secure.
IAM is a Global AWS Service
IAM is a global AWS service, meaning it operates across all AWS regions with a single control plane. Unlike region-specific services like EC2 or S3 buckets, IAM is not tied to any particular region; its resources and policies are universally accessible. You don’t need to configure them separately for each region (i.e, India, USA, Singapore, etc).
Scope of IAM – Where it applies
IAM is the foundation of security in AWS, governing access at multiple levels:
– Users and Groups: Who Can Log In and Access AWS Resources?
– Roles: Temporary permissions for applications and services.
– Policies: Rules that define what users can and cannot do.
Think of IAM like a security system that controls different levels of access across a company:-
– Employees: IAM users, each with specific permissions.
– Departments: IAM groups, grouped based on roles (e.g., Developer, Tester).
– Contractors: IAM roles, temporary access that expires after a certain period.
Pro Tip: Never grant full administrative access unless necessary!
Creating IAM Users: Rules and Best Practices
IAM users represent people (or systems) that need access to your AWS environment. IAM usernames must follow specific rules to ensure consistency and security.
Allowed characters:
– Letters (A-Z, a-z)
– Numbers (0-9)
– Special characters: _+=,.@-
Restrictions:
– No spaces in usernames.
– Cannot exceed 64 characters.
– Usernames must be unique within an AWS account.
Username Rules:
– Must be unique per AWS account
– Max length: 64 characters
Avoid vague usernames like admin or dev1, user1, etc
Best Practice: Think of IAM usernames like email addresses:
– They must be clear, unique, and easy to manage.
– Avoid generic names like ‘admin’, ‘developer1’, etc.
– Use descriptive usernames for better tracking
Stick to a naming convention like: [email protected]
This makes it easy to identify and manage the user.
Custom IAM Password Policies:
AWS allows you to set custom password policies to enforce security standards. Here are some password policy options:
– Minimum length (e.g., 12 characters).
– Require uppercase, lowercase, numbers, and symbols.
– Enforce password expiration (e.g., 90 days).
– Prevent password reuse (e.g., last 5 passwords).
Think of password policies like a net banking account:
– The user must change passwords regularly after a certain period (i.e., 90 days).
– Passwords must be strong enough and not the same as the last 5 passwords used.
Pro Tip: Combine strong password policies with MFA for maximum security!
IAM Groups: Manage Permissions Efficiently
IAM groups are collections of users who share the same permissions. IAM allows you to create users and groups, but there’s a right way to do it.
Let’s understand with the following example: Imagine a school where:
– All teachers belong to the “Teachers” group.
– Admin staff are in the “Admin Office” group.
Even your WhatsApp/Skype has different groups:
– The school friends are in a different group (name: school buddies)
– The society you are living in has a different group where you can exchange messages with society persons
– The office group where you’re all office colleagues is there, and you communicate regarding office-related work
Instead of configuring permissions one by one, assign them to the group and let IAM handle the rest. It’s simpler, cleaner, and scalable.
Best Practice: Always use groups to simplify user management; no need to manually set permissions for every individual.
IAM Roles: Temporary Access, Smart Security
IAM roles are perfect for granting temporary, role-based access – whether it’s a developer working from a client’s machine, or an EC2 instance accessing S3. They allow limited-time access and are revoked automatically after a certain period.
Try to understand with a few simple examples: Think of IAM roles as guest passes:
– Temporary visitors get guest badges (IAM roles), and they can enter, but their access expires once the visit is over.
– Sometimes AC repair or cleaning person needs to enter your premises for a certain time. Once his work is done, he is not allowed to access or enter your premises.
– For technical support, we need to create a user to allow us to check the system log for a short time to resolve the issue.
Unlike users, “Roles” don’t require passwords or long-term credentials, making them more secure for automation and external access.
Session Durations: How Long is a Role Session Valid?
IAM role sessions come with expiration timers. The default & Maximum Duration is as below:
– Default: 1 hour
– Configurable: up to 12 hours
After the session ends, access is cut off unless the user re-assumes the role.
Let’s understand it with a simple example: A freelancer working for your company is given a role with a 1-hour session limit. After the hour is up, they must reauthenticate. This limits long-term exposure and increases accountability.
Pro Tip: Use IAM roles whenever possible instead of creating extra IAM users!
Attaching Policies to IAM: Granting the Right Access
When you create a user (IAM), you need to attach a policy. IAM policies control everything users and roles can and cannot do in AWS. Think of IAM policies as security checklists for employees.
What is a Policy?
A policy is a JSON document that defines:
– Allowed actions (like s3:GetObject)
– Resources (like a specific S3 bucket)
– Conditions (like requiring MFA or specific IPs)
Let’s understand with the following simple examples:
– A newly joined employee only checks the servers and documents shared with them. They can’t make any updates or deletions.
– An experienced employee can create and edit the document, but can’t delete the files.
– A senior employee and manager can create, edit, and delete the document.
Best Practice: Always follow least privilege access; only give users the permissions they need!
IAM Access Keys: For Code, Not Humans
IAM access keys allow programmatic access to AWS services via CLI, SDK, or APIs. Instead of logging in manually, applications use access keys to authenticate.
Best Practice while using Access Keys:
– Never embed access keys in your code.
– Rotate them regularly.
– Use IAM roles for applications whenever possible.
Let’s understand it with an example: A Lambda function (one of the core AWS services) needs to read an S3 bucket. Instead of hardcoding credentials, assign an IAM role to the Lambda, and it securely gets temporary access behind the scenes.
Multi-Factor Authentication (MFA) in IAM
MFA adds an extra layer of security by requiring a second authentication factor in addition to user name and password sign-in credentials. With MFA enabled, when a user signs in to the AWS Management Console, they are prompted for their user name and password- something they know, and an authentication code from their MFA device. Use apps like Google Authenticator, Authy, or hardware tokens like YubiKey for MFA.
Let’s understand it with a simple example: Assuming it is like accessing your bank account:
– You need your username & password and a one-time code to log in.
– If someone steals your password, they can’t do a transaction without the OTP (MFA code).
Best Practice: Always enable MFA for root users and IAM users with sensitive permissions!
Enable MFA for: – Root account and IAM users with elevated privileges
AWS IAM Permission Boundaries
When managing users and roles in AWS IAM (Identity and Access Management), it’s common to assign policies that define what actions a user can perform. But what if you want to limit the maximum permissions someone can have, even if another admin tries to give them more?
A Permission Boundary is like a safety net or fence around a user or role. It defines the maximum permissions that a user or role can ever have, even if someone assigns a broader policy later.
Let’s explain it with a simple and real-time example scenario: Imagine you work in a company where there’s a rule, “New employees can only view files, not edit or delete them until their probation ends.”
Now, a manager hires his friend as a new employee and wants to help him settle quickly. So the manager intentionally gives him full access to the internal system, including edit and delete rights, which is against company policy. But thankfully, the company’s cloud team has already added a Permission Boundary to all junior employees that limits the actual permissions, no matter what the manager gives.
So even though the IAM policy says “full access”, the Permission Boundary says “read-only only”, and AWS enforces the boundary.
How do permission boundaries secure the resource in the above situation?
– The manager tried to break the rules (intentional over-permissioning).
– The company’s Permission Boundary stopped the access quietly.
– The friend cannot edit or delete anything, even though the manager tried.
By applying Permission Boundaries, you:
– Protect your system
– Ensure compliance with security rules
– Avoid accidental or intentional damage
IAM Security Best Practices: A Quick Checklist
- Enable MFA for all critical accounts
- Use IAM roles over access keys
- Least privilege ensures employees don’t have unnecessary permissions.
- Use IAM roles instead of creating unnecessary IAM users.
- Role-based access prevents unauthorized entry into the system.
- Apply naming conventions and organize into groups
- Review policies regularly
- Monitor with CloudTrail and IAM Access Analyzer
- Lock down your root account– use it only for essentials
I hope this guide helped solidify your understanding of IAM and equipped you with the practical knowledge to navigate AWS confidently. If you feel something’s missing or want more clarity on any section, don’t hesitate to leave a comment. I’ll be happy to update the post and expand on it just for you!