AWS IAM (Identity and Access Management)

AWS IAM stands for Identity and Access Management. It is the security system that controls who can access AWS resources and what actions they are allowed to perform. Every time someone or something interacts with AWS — a developer logging into the console, a server calling an API, or an application reading from a database — IAM is the gatekeeper that checks permissions.

IAM is one of the most critical AWS services. Getting IAM right means the entire AWS environment stays secure.

Why IAM Matters — A Simple Analogy

Think of a large office building. The building has different rooms — server room, accounts department, HR office, and the CEO's office. Not everyone can enter every room. A visitor gets a temporary badge that allows access only to the reception. An HR employee can enter the HR office but not the server room. The CEO can enter all rooms.

IAM works exactly like this building's access control system. AWS resources are the rooms. IAM defines who gets in and what they can do inside.

Core IAM Components

1. IAM Users

An IAM User represents a single person or application that needs access to AWS. Each user has a unique name and credentials (password or access keys).

• A developer on the team gets an IAM User with access to EC2 and S3.
• A billing manager gets an IAM User with access only to the billing console.

By default, a new IAM User has no permissions at all — they cannot do anything until permissions are granted explicitly.

2. IAM Groups

An IAM Group is a collection of IAM Users. Instead of assigning permissions to each user individually, permissions are assigned to the group. All users in the group inherit those permissions.

[IAM Group: Developers]
   |-- Policy: EC2FullAccess
   |-- Policy: S3ReadAccess
         |
         +-- User: Ravi
         +-- User: Priya
         +-- User: Arjun

All three users get EC2 and S3 access because they belong to the Developers group. If permissions need to change, update the group once — all users are updated automatically.

3. IAM Roles

An IAM Role is like a temporary badge. It is assigned to AWS services (not users) or given temporarily to users who need elevated access.

Example: An EC2 server needs to read files from an S3 bucket. Instead of storing access keys inside the EC2 instance (which is risky), an IAM Role is created with S3 read permission and attached to the EC2 instance. The EC2 server automatically gets temporary credentials through this role.

[EC2 Instance] --- has role ---> [IAM Role: S3ReadRole]
                                         |
                                  [Policy: S3GetObject]
                                         |
                              [Can read S3 bucket files]

4. IAM Policies

An IAM Policy is a JSON document that defines permissions. It specifies:

• Effect: Allow or Deny
• Action: Which AWS API action (e.g., s3:GetObject, ec2:StartInstances)
• Resource: Which specific resource (e.g., a specific S3 bucket)

Example policy — allows reading files from a specific S3 bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-company-bucket/*"
    }
  ]
}

This policy says: Allow the action "GetObject" (download a file) on all objects inside "my-company-bucket".

Types of IAM Policies

IAM Architecture Diagram

+--------------------------------------------------+
|                   AWS Account                    |
|                                                  |
|  [Root Account] — use only for billing & setup   |
|                                                  |
|  [IAM Users]    [IAM Groups]    [IAM Roles]      |
|       |               |               |          |
|  [Policies attached to each]                     |
|       |               |               |          |
|  [Access AWS Resources: EC2, S3, RDS, etc.]      |
+--------------------------------------------------+

The Principle of Least Privilege

The most important security principle in IAM is: grant only the permissions that are absolutely necessary and nothing more.

A developer who only needs to deploy code should not have permission to delete databases. A monitoring tool that reads logs should not have permission to launch new servers.

This principle minimizes damage if a credential is stolen or misused — a compromised account with minimal permissions causes far less harm than one with full access.

IAM Best Practices

• Never use the root account for daily tasks. Create an IAM Admin user immediately after account setup.
• Enable MFA (Multi-Factor Authentication) for all users, especially admin accounts.
• Use Groups to assign permissions — never assign policies to individual users when a group works.
• Use Roles for services — never store access keys inside EC2 instances or Lambda functions.
• Rotate access keys regularly — old keys that are no longer needed should be deleted.
• Review unused permissions periodically using IAM Access Analyzer.

Real-World Example — Startup Team Setup

A startup has three roles: developers, a DBA (database admin), and a finance person. Here is how IAM is set up:

Additionally, a Role called "AppServerRole" is created with S3ReadAccess and attached to all EC2 instances running the application. The servers read from S3 without needing any hardcoded credentials.

IAM Access Analyzer

IAM Access Analyzer is a built-in tool that scans the AWS environment and reports resources that are accessible from outside the account — such as an S3 bucket set to public or an IAM Role that can be assumed by any AWS account. It helps catch and fix misconfigured permissions before they become security issues.

Summary

• IAM controls who can access AWS and what they can do.
• IAM Users represent people or applications. IAM Groups manage users in bulk. IAM Roles give temporary access to services.
• IAM Policies are JSON documents that define Allow or Deny rules for specific AWS actions.
• The principle of least privilege means granting only the minimum permissions required.
• Always use MFA, avoid the root account for daily tasks, and use Roles for services instead of hardcoded credentials.