Fundamentals of AWS IAM (Identity And Access Management)

AWS Identity and Access Management (IAM) is a fundamental security service in AWS, providing fine-grained access control across AWS resources. Whether you’re a cloud architect, DevOps engineer, or security specialist, understanding IAM is essential to securing your cloud environment.

What is AWS IAM?

AWS Identity and Access Management (IAM) is a service that enables organizations to manage permissions and access to AWS resources securely. IAM allows you to create and manage users, groups, roles, and policies to ensure least-privilege access control.

Why is IAM Important?

• Centralized control of your AWS account.
• Access Shared access to your AWS account.
• Granular Permission – This means you can enable a different level of access to different users within your organization.
• Identity Federation – This means you can enable users to log in using credentials stored in the active directory, Facebook or LinkedIn.

• Multifactor Authentication (MFA) – Enables authentication using multiple independent mechanisms before granting access. For example, a user must first enter a username and password and then verify their identity using a software token from an authenticator app like Google Authenticator.
• Temporary Access – Provides time-limited access to users, devices, or services as needed. For instance, when developing a web or mobile application, IAM can be configured to grant temporary permissions to access AWS resources such as an S3 bucket or a DynamoDB database.
• Password Policy – Allows you to define custom password rotation policies to enhance security.
• Service Integration – Seamlessly integrates with various AWS services, ensuring consistent access management across your cloud environment.
• Compliance – Supports PCI DSS compliance, making it suitable for applications handling payment card data.

Core Components of AWS IAM

1. IAM Users

An IAM user is an identity that represents an individual or an application requiring access to AWS resources.

Key Features:

• Each user has a unique name within an AWS account.
• Users can be assigned passwords for AWS Management Console access.
• Users can have access keys for API/CLI access.

Best Practices for IAM Users:

• Enable Multi-Factor Authentication (MFA) for added security.
• Avoid using the root user for daily operations.
• Assign users to IAM Groups to manage permissions effectively.

2. IAM Groups

An IAM group is a collection of IAM users that share common permissions. Instead of assigning policies individually, you attach them to a group, ensuring consistent access control.

Example IAM Group Structure:

IAM Group	Permissions Assigned
Admins	Full AWS Access
Developers	EC2, Lambda, S3 Read-Only
DevOps	IAM Read-Only, EC2 Full Access
Security	CloudTrail, GuardDuty Full Access

Why Use IAM Groups?

• Easier Permission Management: Assign policies to a group instead of individual users.
• Scalability: As teams grow, new users inherit the right permissions by joining a group.
• Security: Reduces misconfigurations and over-permissioning.

Best Practice: Use groups instead of individual user policies to simplify management.

3. IAM Roles

An IAM role is an identity with a set of permissions that can be assumed by:

• AWS services (e.g., EC2, Lambda, ECS)
• Another AWS account
• Federated users (via SAML, OpenID Connect)

Key Differences Between IAM Users & Roles:

Feature	IAM User	IAM Role
Credential Type	Password & Access Key	Temporary Security Tokens
Assigned To	Individual Person	AWS Services or Users
Long-Term Access	Yes	No
Best Use Case	Direct user access	Cross-account access, service permissions

Best Practice: Always use IAM roles instead of IAM users for AWS services to avoid hardcoded credentials.

4. IAM Policies

IAM policies define the permissions and rules for IAM users, groups, and roles. These policies are written in JSON format and define who can do what on which resources.

Types of IAM Policies:

1. AWS-Managed Policies:
   • Predefined by AWS for common use cases.
   • Example: AdministratorAccess, ReadOnlyAccess, AmazonS3FullAccess.
2. Customer-Managed Policies:
   • Custom policies created by users for specific needs.
3. Inline Policies:
   • Policies embedded directly into users, groups, or roles.
   • Not reusable across other identities.
4. Service Control Policies (SCPs):
   • Used in AWS Organizations to enforce permission boundaries across multiple accounts.

IAM Policies Deep Dive

• Anatomy of a policy: JSON doc with Effect, Action, Resource, Conditions, Policy Variables
• Explicit DENY has precedence over ALLOW

Sample Policy JSON

{
  "Version": "2012–10–17",
  "Statement": [
    {
      "Sid": "FirstStatement",
      "Effect": "Allow",
      "Action": [
		"ec2:AttachVolume",
		"ec2:DettachVolume"
		]
      "Resource": "arn:aws:ec2:*:*:instance/*",
	  "Condition":{
		"StringsEqual": {"ec2:ResourceTag/Department": "Development"}
	  }
    },
	{
      "Sid": "SecondStatement",
      "Effect": "Allow",
      "Action": [
		"ec2:AttachVolume",
		"ec2:DettachVolume"
		]
      "Resource": "arn:aws:ec2:*:*:volume/*",
	  "Condition":{
		"StringsEqual": {"ec2:ResourceTag/VolumeUser": "${aws:username}"}
	  }
    }
  ]
}

Navigate Examples at:
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html

Additional IAM Components

IAM Identity Center (AWS SSO)

AWS IAM Identity Center (previously AWS SSO) enables centralized access management across multiple AWS accounts and third-party applications.

Use Case:

• Helps manage enterprise-level AWS user access via Active Directory (AD) or SAML-based authentication.
• Supports Single Sign-On (SSO) for multiple AWS accounts.

Best Practice: If managing multiple AWS accounts, use AWS IAM Identity Center for easier user access control.

Comparison Table: IAM Users vs. Groups vs. Roles vs. Policies

Feature	IAM Users	IAM Groups	IAM Roles	IAM Policies
Purpose	Individual Access	Manage user permissions	Provide temporary access	Define permissions
Who Uses It?	People	Groups of users	AWS Services, Federated Users	Users, Groups, Roles
Long-Term Credentials?	Yes	N/A	No	N/A
Best Practice	Use MFA	Assign instead of individual permissions	Use for AWS services	Apply least privilege