AWS IAM Explained - Identity and Access Management

-

AWS Identity and Access Management (IAM) is the backbone of AWS security. It allows you to control who can access your AWS resources and what actions they can perform. IAM is a global service, meaning it protects your entire AWS account regardless of region.

This guide covers IAM concepts such as users, groups, roles, policies, access keys, and Identity Center — with real-world analogies and Spring Boot examples.

What is AWS IAM?

AWS Identity and Access Management (IAM) is a centralized service that controls access to AWS resources like EC2, S3, Lambda, DynamoDB, and more. IAM defines:

  • Who can access AWS
  • What they can do
  • Which services they can use

IAM is essential before deploying any production workload.

Real-World Analogy of IAM

Imagine a company where employees receive access cards, computer accounts, and tool permissions. The security team decides who gets access to rooms, tools, and systems.

IAM works exactly like that, but in the cloud. Instead of physical doors or computers, it controls access to AWS cloud services such as:

  • EC2 instances (servers)
  • S3 buckets (storage)
  • Billing dashboards
  • Lambda functions

IAM Users: Human and Programmatic

An IAM User is an identity inside your AWS account. There are two types:

  • Console Users: Humans who log in with username and password. MFA should be enabled.
  • Programmatic Users: Applications that use Access Key ID and Secret Access Key for AWS CLI and SDKs.

When a new IAM user is created, they have zero permissions until a policy is attached.

Console Access vs Programmatic Access

Console Access allows users to log in to the AWS Management Console using a password. This is typically used by developers, DevOps, and administrators.

Programmatic Access uses access keys required for:

  • AWS CLI
  • AWS SDKs
  • Application code

For example, a Spring Boot application can use access keys to upload files to an S3 bucket. Keys must be handled securely and rotated regularly.

IAM Policies and Permissions

IAM Policies are JSON documents that define:

  • Actions (e.g., s3:ListBucket, ec2:StartInstances)
  • Resources (specific S3 buckets, EC2 instances, etc.)
  • Conditions (optional restrictions)

Example Policy Structure:

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

Amazon provides managed policies such as AmazonEC2FullAccess and AmazonS3FullAccess that you can attach directly to users or groups.

IAM Groups for Team-Based Permissions

As your team grows, assigning permissions one-by-one becomes inefficient. IAM Groups allow you to manage permissions collectively.

Example workflow:

  • Create a group named developers.
  • Attach policies: EC2, S3, Lambda access.
  • Add users to the group so they inherit permissions automatically.

Updating group policies updates permissions for all members.

IAM Roles and Temporary Access

An IAM Role is an identity that users or AWS services can assume temporarily. Unlike IAM users, roles do not require a password or access keys.

Practical Example: Billing Access

  • Create a Billing ReadOnly role.
  • Allow trusted IAM users to assume it.
  • Users switch roles only when they need billing data.

This keeps daily permissions minimal while allowing temporary elevated access.

Trusted Entities and AssumeRole

A role includes a trusted entity configuration defining who can assume the role. It may trust:

  • IAM users in the same account
  • Another AWS account
  • AWS services like EC2 or Lambda

To assume a role, a user must have permission to call sts:AssumeRole and can switch roles via the AWS console.

IAM Access Keys for Applications

For programmatic access, IAM users can generate access keys. These keys are used by:

  • Local development (AWS CLI)
  • Spring Boot applications
  • Automated deployment pipelines

Best Practice: Do not use long-term access keys in production. Instead, assign IAM Roles to EC2 instances, ECS tasks, or Lambda functions so they automatically receive temporary credentials.

IAM Identity Center vs IAM Users

AWS IAM Identity Center (formerly AWS SSO) is recommended for organizations with many users. It provides:

  • Centralized user management
  • Single sign-on
  • Integration with identity providers (Azure AD, Google Workspace)

IAM users are better for:

  • Small teams
  • Demos
  • Legacy systems

Key Takeaways for Developers

  • Use IAM users and groups for human access.
  • Use IAM roles for temporary or service-based access.
  • Grant least-privilege permissions to avoid risks.
  • Avoid long-lived access keys — prefer roles.
  • Use Identity Center for managing large teams.

Understanding IAM—users, roles, groups, policies, and Identity Center—will help you design secure access patterns for your AWS and Spring Boot applications.

Comments

Post a Comment