AWS Identity and Access Management (IAM) is a free AWS service that lets you securely control who can access your AWS resources and what actions they can perform, using users, groups, roles, and policies to enforce the principle of least privilege across your cloud infrastructure.

What is AWS IAM?

AWS IAM is a free AWS service that controls who can access your AWS resources and what actions they can perform. In fact, it is the gatekeeper for your entire AWS environment.

With IAM you can create and manage users and groups, define permissions through policies, assign roles to AWS services and applications, enforce MFA, and audit all access through CloudTrail.

Key Concept: IAM uses a deny-by-default model. No user or service can access anything unless explicitly allowed by a policy.

Why Does IAM Security Matter?

Still, IAM misconfigurations are one of the most common causes of cloud security breaches. For example, real-world consequences include exposed S3 buckets, compromised access keys used to mine crypto costing thousands overnight, attackers gaining full admin access, and compliance violations under GDPR, HIPAA, and PCI-DSS.

1. Follow the Principle of Least Privilege

In other words, give users, roles, and services only the permissions they absolutely need. Start with zero and add only what is required.

• Avoid "Action": "*" — it allows all actions on every service
• Avoid "Resource": "*" unless truly necessary
• Review and remove unused permissions regularly using Access Analyzer

Least Privilege — Good Policy

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-app-bucket/*"
}

2. Never Use the Root Account for Daily Tasks

The root user has unrestricted access and cannot be limited by any IAM policy. Next, Use it only for initial setup, changing account email, or closing the account.

• Enable MFA on root immediately after account creation
• Create a separate IAM admin user for all daily work
• Never create access keys for the root account

AWS Exam Alert: SAA-C03 heavily tests this. Always choose answers that say create an IAM user — never use root for operational tasks.

3. Enable MFA on All Accounts

Multi-Factor Authentication adds a second layer beyond passwords. Even a stolen password cannot be used without the physical MFA device.

Deny all actions unless MFA is active

Thus, {
  "Effect": "Deny",
  "NotAction": ["iam:CreateVirtualMFADevice","iam:EnableMFADevice","sts:GetSessionToken"],
  "Resource": "*",
  "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
}

4. Use IAM Roles Instead of Long-Term Access Keys

IAM Roles provide temporary, auto-rotating credentials far safer than static access keys that can be accidentally pushed to GitHub.

• EC2 instances — Attach an instance profile, never hardcode keys
• Lambda functions — Always assign an execution role
• Cross-account access — Use AssumeRole via AWS STS

Real World: EC2 server uploading to S3? Create a role with only s3:PutObject on your specific bucket. Attach to EC2. No keys. No leaks.

5. Use Groups to Manage Permissions

Never assign permissions directly to individual users. Create IAM Groups, attach policies to groups, then add users.

• Admins — Full access (very few members)
• Developers — EC2, S3, Lambda, RDS
• ReadOnly — View-only for auditors
• BillingTeam — Cost management only

6. Rotate Access Keys Regularly

Generally, If you must use long-term access keys, rotate them every 90 days minimum. Never embed keys in source code. Use AWS Secrets Manager or SSM Parameter Store instead.

Real Threat: An exposed key on GitHub gets scraped by bots within seconds, resulting in massive unexpected AWS bills within minutes.

7. Use Managed Policies Over Inline Policies

Use Customer Managed Policies for custom permissions — reusable, versioned, and easy to audit. Similarly, avoid inline policies except for very specific one-off cases.

8. Set a Strong IAM Password Policy

• Minimum 14 characters with uppercase, lowercase, numbers, symbols
• Password expiry every 90 days
• Prevent reuse of the last 24 passwords

9. Use IAM Access Analyzer

Naturally, Continuously monitors your policies and identifies access unintentionally shared with external entities — public S3 buckets, externally assumable roles, Lambda with public resource policies. Enable it in every AWS region you operate in.

10. Audit All Activity with AWS CloudTrail

Records every API call in your account — who did what, from where, and when. Enable in all regions with log file validation enabled.

CloudTrail vs CloudWatch: CloudTrail records who did what (API calls, identity). CloudWatch monitors performance (CPU, memory). Both together give full observability.

11. Use Permission Boundaries

Sets the maximum permissions a user or role can ever have — even if their attached policy allows more. Prevents privilege escalation when developers self-create roles for Lambda. Effective permissions = identity policy ∩ permission boundary ∩ SCPs.

12. Use SCPs in AWS Organizations

Service Control Policies act as guardrails applied across all member accounts, overriding even admin permissions.

• Deny actions outside approved AWS regions
• Prevent disabling CloudTrail or GuardDuty in any account
• Prevent accounts from leaving the organization

Important: SCPs do NOT grant permissions — they only restrict. Both the SCP and IAM policy must allow an action for it to succeed.

Common IAM Mistakes to Avoid

Using Root Daily

Create a named IAM admin. Lock root away with MFA permanently.

Hardcoding Access Keys

Hence, Keys in GitHub get scraped instantly. Always use roles or Secrets Manager.