Learning Objectives

• Understand the difference between users and roles
• Learn when to use AWS IAM roles for AWS services and automation
• Grasp the concept of temporary security credentials

The Traveling Merchant

A merchant arrives at your castle gate. He’s not a resident—he doesn’t live here. He just needs temporary access to the marketplace to sell his goods.

You don’t give him a permanent key. You give him a guest pass that expires at sundown.

That’s an AWS IAM role.

Roles are for temporary access. They don’t have permanent credentials like passwords or access keys. Instead, they issue temporary security credentials that expire after a set time (usually 1-12 hours).

When Roles Beat Users

Use roles for:

AWS Services – Your EC2 instance needs to access S3
Cross-Account Access – A partner company needs limited access to your account
Federated Users – Employees logging in through Google Workspace or Okta
CI/CD Pipelines – GitHub Actions deploying infrastructure via Terraform

Never do this: Create an IAM user called “jenkins-bot,” generate access keys, and hardcode them in your pipeline. Those keys live forever and can be stolen.

Do this instead: Create a role, attach it to your EC2 instance or pipeline, and let AWS handle temporary credentials automatically.

The EC2-to-S3 Pattern

This is the most common role scenario in DevOps. Your application runs on EC2 and needs to read files from S3.

First, create the role:

bash

aws iam create-role \
  --role-name ec2-s3-read-role \
  --assume-role-policy-document file://trust-policy.json

The trust policy (saved as trust-policy.json) says “EC2 can assume this role”:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Then attach a permission policy:

bash

aws iam attach-role-policy \
  --role-name ec2-s3-read-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

This single line connects the role to actual permissions—now the role can read S3 buckets.

Finally, attach the role to your EC2 instance. Now your application code can access S3 without storing any credentials in code or environment variables. AWS handles everything behind the scenes.

Why Automation Loves Roles

In modern DevOps, humans rarely deploy infrastructure manually. GitHub Actions, Jenkins, Terraform Cloud—these tools do the work.

If you use IAM users for automation, you’re storing long-lived credentials somewhere. That’s a security risk. Credentials get committed to Git repos, left in CI/CD logs, or accidentally shared in Slack.

Roles solve this. GitHub Actions can assume an AWS role, get temporary credentials, deploy your infrastructure, and then those credentials expire. No secrets to manage.

This is how mature DevOps teams work: humans use users with MFA, machines use roles with temporary credentials.

Reflection: Think about your current setup. Where are you using IAM users that should be roles?