AWS IAM Basics: Managing Access and Permissions

AWS Identity and Access Management (IAM) is the foundation of security in AWS. It controls who can access your AWS resources and what they can do with them. Understanding IAM is essential for any AWS deployment.

What is AWS IAM?

IAM lets you manage access to AWS services and resources securely. You can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.

Key Concepts:

• Users: Individual accounts that represent people or applications
• Groups: Collections of users with shared permissions
• Roles: Temporary credentials for services or users
• Policies: Documents that define permissions (JSON format)

Core Components

1. IAM Users

IAM users represent a person or application that needs to interact with AWS. Each user has:

• A unique name
• Security credentials (password and access keys)
• Permissions attached via policies

Best Practice: Don't use your root account for daily tasks. Create IAM users instead.

2. IAM Groups

Groups are collections of IAM users. You can:

• Assign permissions to groups instead of individual users
• Add or remove users from groups
• Simplify permission management

Example Groups: Developers, Admins, ReadOnlyUsers

3. IAM Roles

Roles are similar to users, but:

• No permanent credentials
• Assumed temporarily by users or services
• Perfect for EC2 instances, Lambda functions, and cross-account access

4. IAM Policies

Policies are JSON documents that define permissions. Two types:

• Identity-based policies: Attached to users, groups, or roles
• Resource-based policies: Attached to resources (like S3 buckets)

Creating Your First IAM User (AWS Console)

Step 1: Navigate to IAM

1. Log in to AWS Console
2. Search for "IAM" in the services menu
3. Click on "IAM" to open the dashboard

Step 2: Create a User

1. Click "Users" in the left sidebar
2. Click "Create user"
3. Enter username (e.g., "spring-boot-developer")
4. Select "Provide user access to the AWS Management Console" if needed
5. Set password policy (auto-generated or custom)
6. Click "Next"

Step 3: Set Permissions

You have three options:

Option A: Add user to group

• Create a group (e.g., "Developers")
• Attach policies to the group
• Add user to the group

Option B: Copy permissions from existing user

• Select a user to copy permissions from

Option C: Attach policies directly

• Select policies (e.g., "AmazonEC2FullAccess", "AmazonS3FullAccess")

Recommended: Use groups for better management.

Step 4: Review and Create

1. Review the user details
2. Click "Create user"
3. Save the access key ID and secret access key securely (if programmatic access was enabled)

Creating IAM Policies

Policies define what actions are allowed or denied. Here's a basic policy structure:

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

Policy Elements:

• Version: Policy language version (always use "2012-10-17")
• Effect: "Allow" or "Deny"
• Action: Specific AWS API actions
• Resource: ARN of the resource to apply the policy to

Example: EC2 Read-Only Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:Describe*", "ec2:Get*"],
      "Resource": "*"
    }
  ]
}

Using IAM Roles for EC2 Instances

Instead of storing access keys on EC2 instances, use IAM roles:

Step 1: Create a Role

1. In IAM console, click "Roles"
2. Click "Create role"
3. Select "AWS service" → "EC2"
4. Click "Next"

Step 2: Attach Policies

1. Search for and select policies (e.g., "AmazonS3ReadOnlyAccess")
2. Click "Next"
3. Name the role (e.g., "ec2-s3-readonly-role")
4. Add description
5. Click "Create role"

Step 3: Attach Role to EC2 Instance

1. In EC2 console, select your instance
2. Click "Actions" → "Security" → "Modify IAM role"
3. Select the role you created
4. Click "Update IAM role"

Now your EC2 instance can access S3 without storing credentials!

IAM Best Practices

1. Follow the Principle of Least Privilege

Grant only the minimum permissions needed. Don't give full admin access unless absolutely necessary.

2. Use Groups for Permission Management

Instead of attaching policies directly to users, attach them to groups and add users to groups.

3. Enable MFA for Root Account

Multi-factor authentication adds an extra layer of security.

4. Use IAM Roles Instead of Access Keys

For EC2, Lambda, and other AWS services, use roles instead of storing access keys.

5. Regularly Rotate Credentials

• Rotate access keys every 90 days
• Use different keys for different applications
• Disable unused keys immediately

6. Monitor IAM Activity

• Enable CloudTrail to log IAM API calls
• Review IAM Access Analyzer findings
• Set up CloudWatch alarms for suspicious activity

7. Use Policy Conditions

Add conditions to policies for additional security:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

This policy only allows uploads from specific IP addresses.

Common IAM Use Cases

Use Case 1: Developer Access to EC2 and S3

Scenario: A developer needs to manage EC2 instances and read S3 buckets.

Solution:

1. Create group "Developers"
2. Attach policies: "AmazonEC2FullAccess", "AmazonS3ReadOnlyAccess"
3. Add developer user to the group

Use Case 2: Application Accessing S3

Scenario: A Spring Boot application running on EC2 needs to read/write S3.

Solution:

1. Create IAM role "ec2-s3-application-role"
2. Attach custom policy with S3 permissions
3. Attach role to EC2 instance
4. Application uses AWS SDK without credentials

Use Case 3: Lambda Function Accessing DynamoDB

Scenario: Lambda function needs to read/write DynamoDB table.

Solution:

1. Create IAM role "lambda-dynamodb-role"
2. Attach "AmazonDynamoDBFullAccess" or custom policy
3. Attach role to Lambda function

IAM Limits and Quotas

Be aware of IAM limits:

• Users per account: 5,000
• Groups per account: 300
• Roles per account: 1,000
• Managed policies per account: 1,500
• Policy size: 2,048 characters (6,144 for managed policies)

For most applications, these limits are more than sufficient.

Troubleshooting Common Issues

Issue: "Access Denied" Error

Check:

1. Does the user/role have the required permissions?
2. Is the policy attached correctly?
3. Are there any Deny policies overriding Allow policies?
4. Is the resource ARN correct?

Issue: EC2 Instance Can't Access S3

Check:

1. Is an IAM role attached to the instance?
2. Does the role have S3 permissions?
3. Is the instance role correctly configured?

Issue: Too Many Policies

Solution: Consolidate policies, use groups, and review unused permissions regularly.

Security Best Practices Summary

1. ✅ Never use root account for daily operations
2. ✅ Enable MFA for all privileged users
3. ✅ Use IAM roles instead of access keys when possible
4. ✅ Follow principle of least privilege
5. ✅ Use groups for permission management
6. ✅ Regularly audit and rotate credentials
7. ✅ Monitor IAM activity with CloudTrail
8. ✅ Use policy conditions for additional security
9. ✅ Tag resources for better organization
10. ✅ Review permissions regularly

IAM is the foundation of AWS security. Start with basic users and groups, then move to roles as you scale. Always follow the principle of least privilege, and regularly review your IAM configuration.

Next Steps:

• Practice creating users, groups, and roles
• Experiment with custom policies
• Set up IAM roles for your EC2 instances
• Explore IAM Access Analyzer for security insights