The Four Types of AWS IAM Roles – What They Actually Do

Clear definitions + production-grade patterns used by mature organizations today
eclipsos.com | Intermediate to Advanced

If you design or secure AWS environments, you already know roles are better than users. But do you truly understand the four distinct categories AWS gives us — and which one to use when?

Let’s fix that right now.

1. AWS Service Roles

“AWS service roles allow AWS services to access resources in other AWS services on your behalf.”
“AWS Service Roles are associated with AWS Service Resources, for example, an EC2 instance. They allow us to safely delegate access to one or more AWS resources from an EC2 instance.”
— AWS official documentation & training

What they are: Roles that AWS services (Lambda, EC2, ECS, Step Functions, Glue, etc.) assume to call other AWS services on your behalf.

Why they exist: So you never have to put long-term access keys inside code, AMIs, or containers.

Real-world examples in 2025:

• A Lambda function that reads from S3 and writes to DynamoDB
• An ECS task that sends metrics to CloudWatch
• A CodeBuild project that deploys to an S3 website bucket

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject","s3:PutObject"],
      "Resource": "arn:aws:s3:::prod-company-data-${AWS_ACCOUNT_ID}/*",
      "Condition": { "StringEquals": { "aws:SourceArn": "arn:aws:lambda:*:*:function:process-orders-v42" }}
    }
  ]
}

2025 best practice: always add aws:SourceArn (or aws:SourceVpc) conditions.

2. Cross-Account Access Roles

“Roles that can only be assumed by IAM users who belong to a different AWS account.”
— Amazon Web Services for Mobile Developers & AWS official documentation

What they are: Roles that live in Account B but can be assumed by principals (users, roles, or services) in Account A.

Why they exist: Secure delegation in multi-account AWS Organizations — the foundation of landing zones and Control Tower.

Real-world examples in 2025:

• Central logging account receiving CloudTrail from 50+ workload accounts
• Security tooling account running GuardDuty or Inspector across the organization
• Shared services account hosting a golden AMI pipeline

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111111111111:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "org-wide-2025" },
        "Bool": { "aws:MultiFactorAuthPresent": "true" }
      }
    }
  ]
}

3. Identity Provider Access Roles (Federation Roles)

“Identity Federation Roles can grant single sign-on access to resources for users authenticated by a number of OpenID providers or identity services that support SAML 2.0.”
— Introduction to Architecting Amazon Web Services course

What they are: Roles assumed by users or workloads after they authenticate to an external identity provider (Okta, Azure AD, Google, GitHub Actions, etc.).

Why they exist: To give your employees, contractors, and CI/CD systems temporary AWS access without creating IAM users.

Real-world examples in 2025:

• Developers logging into the AWS console via Okta SSO
• GitHub Actions deploying to production without storing secrets
• On-prem servers using IAM Roles Anywhere with corporate X.509 certificates

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Federated": "arn:aws:iam::111111111111:oidc-provider/token.actions.githubusercontent.com" },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:sub": "repo:myorg/infra:ref:refs/heads/main"
        }
      }
    }
  ]
}

4. Service-Linked Roles

“Service-linked roles are predefined service roles out of the box.”
— AWS Certified Solutions Architect – Professional Exam Guide

What they are: Pre-defined roles that AWS services create and manage for you. You usually don’t create them manually; the service does it the first time you enable a feature.

Why they exist: Some services need very specific permissions that change over time (e.g., Elastic Load Balancing creating ENIs in your VPC). Service-linked roles let AWS update permissions automatically.

Common service-linked roles you already have:

• AWSServiceRoleForAutoScaling
• AWSServiceRoleForElasticLoadBalancing
• AWSServiceRoleForGuardDuty
• AWSServiceRoleForOrganizations

In Q3 2025, a major breach chain started with a low-privilege user who escalated to AWSServiceRoleForOrganizations to detach accounts from the organization.

Defend them with Control Tower guardrails and CloudTrail alerts.

2025 Comparison Matrix – Which Role When?

IAM Role Types by Use Case

Use Case	Service Role	Cross-Account	Federation	Service-Linked
Lambda → S3	Yes	No	No	No
Account A reads bucket in Account B	No	Yes	No	No
Developer logs in via Okta	No	No	Yes	No
GitHub Actions deploys	No	No	Yes (OIDC)	No
Elastic Load Balancing creates ENIs	No	No	No	Yes

Your 2025 IAM Role Checklist

• All service roles use aws:SourceArn or aws:SourceVpc conditions
• All cross-account roles require MFA + ExternalId
• All human access goes through federation (no IAM users)
• All CI/CD uses OIDC
• Every role (except service-linked) has a permission boundary
• Service-linked roles are protected by Control Tower or SCPs