IAM Roles in AWS: A Practical Guide for Developers

AWS practically runs the modern internet, and as more teams shift their workloads to the cloud, securing access becomes the non-negotiable foundation of any architecture. At the center of AWS security sits IAM - and among all IAM components, IAM roles are the quiet superstars. They let your apps, servers, and users access AWS resources without relying on static passwords or access keys. Everything stays temporary, controlled, and much harder to misuse.

This guide walks you through what IAM roles really are, how they behave under the hood, and how to use them safely and effectively as a developer.

Understanding AWS Identities

Before diving into roles, it's helpful to understand where they sit among AWS identity types.

IAM users are the "old-school" way of giving someone access - permanent credentials, long-lived keys, and therefore a larger attack surface. These still exist, but today they're mostly reserved for rare break-glass scenarios or legacy systems that can't be refactored.

Modern organizations rely heavily on federated identities, where authentication happens outside AWS - through providers like Okta, Azure AD, Google Workspace, GitHub, or GitLab. In these cases, AWS never sees or stores user credentials; instead, it hands out temporary access after the user authenticates with the identity provider.

Sitting right at the center of AWS access control are IAM roles, which don't have permanent credentials at all. Their entire design revolves around AWS STS issuing short-lived access keys. That's why they're the natural fit for secure automation, microservices, serverless systems, workload isolation, and cross-account setups.

Finally, there's IAM Identity Center, the newer, more streamlined way to manage human access. It integrates directly with your organization's identity provider and maps users to permission sets - which, internally, become IAM roles. The best practice today is simple: humans use Identity Center, systems use IAM roles, and IAM users are avoided as much as possible.

Inside an IAM Role: How It Actually Works

Every IAM role is made of two pieces that must perfectly align:

• A trust policy, which defines who is allowed to assume the role.
• A permissions policy, which defines what the role can do once it has been assumed.

A useful analogy: imagine the role is a secure facility.

The trust policy is the people allowed to enter the building.

The permissions policy is the rooms they're allowed to access once inside.

If either one is mismatched, access fails.

A trust policy might allow an EC2 instance to assume the role, while the permissions policy might allow that role to read objects from a specific S3 bucket. Only when both sides match does access go through.

Creating IAM Roles the Right Way

The AWS Console offers a friendly interface for creating roles - useful when you're experimenting or learning. You pick the trusted entity, attach permissions, and name the role. But for production, developers usually reach for the AWS CLI or Terraform so roles can be version-controlled, audited, and deployed consistently.

Using the CLI, you create a role by supplying a trust policy file and then attaching a permissions policy. Terraform takes this a step further by letting you define the entire role - trust policies, inline policies, attachments - in infrastructure-as-code that can be reviewed and deployed like any other code.

Once a role exists, any supported AWS service can use it. EC2 instances can attach IAM instance profiles, Lambda functions can run with execution roles, ECS tasks can use task roles, and external systems can assume roles across accounts.

Creating IAM Roles

Using AWS Console

1. Go to IAM → Roles → Create role.
2. Choose the trusted entity type (AWS service, another account, or IdP).
3. Attach permissions policies.
4. Name and create the role.

This is fine for quick setups, but automation tools like the CLI or Terraform are recommended for production.

Using the AWS CLI

Save your trust policy as trust.json.

Create the role:

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

Attach a permissions policy:

aws iam attach-role-policy \
  --role-name DemoEC2Role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

Using Terraform

resource "aws_iam_role" "demo" {
  name = "demo_role"

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

resource "aws_iam_role_policy_attachment" "attach" {
  role       = aws_iam_role.demo.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
}

How Roles Are Assumed

Assuming a role is simply the process of asking AWS STS for temporary credentials. Once granted, you act as that role, with its exact permissions, for a limited time.

Developers do this in multiple ways:

• In the AWS Console, humans can "switch roles" to move between accounts or permission sets.
• In the AWS CLI, profiles reference role ARNs, letting you run commands using the role's permissions.
• In code, libraries like Boto3 call sts.assume_role() to obtain temporary keys for automation.

For sensitive or privileged roles, MFA protection can be added to the trust policy, forcing users to verify their identity before the role can be assumed.

Types of IAM Roles in Real Projects

Roles aren't one-size-fits-all. You'll encounter several categories:

• Service Roles - used by AWS services like EC2, Lambda, ECS, Glue, etc., so they can perform actions on your behalf.
• Service-Linked Roles - created automatically by AWS when services need them; you cannot customize the trust policy.
• Web Identity Roles - used when external workloads authenticate via OIDC, such as GitHub Actions or Kubernetes service accounts in EKS.
• SAML Roles - used for enterprise SSO setups via providers like Okta or Azure AD.

Understanding the role type helps you design secure and predictable workloads.

Advanced Concepts Developers Should Know

IAM roles come with deeper mechanics that matter in real-world architectures.

Session duration determines how long temporary credentials last. While roles can theoretically grant up to 12 hours, role chaining limits this to 1 hour.

In cross-account setups, the trust policy becomes extremely important because it determines which external AWS accounts or IAM principals are allowed to assume a role.

Permission boundaries act like guardrails that cap the maximum privileges a role (or user) can ever receive - even if someone tries attaching an overly powerful policy.

And using an External ID prevents confused-deputy attacks, ensuring that only the intended third-party system can assume a role meant for them.

Key Takeaways

IAM roles are not just a security best practice; they're the fundamental building blocks of modern AWS architectures. They reduce risk by eliminating static credentials, enforce least privilege, and enable secure automation everywhere - from EC2 to CI/CD pipelines to cross-account access.

If you're building anything serious on AWS, mastering IAM roles is one of the most important skills you can develop.

Expanded Common Questions

1. Are IAM roles actually more secure than IAM users?
Yes - and not just a little. IAM users rely on long-term access keys, which can leak, be accidentally pushed to GitHub, or get stolen without anyone noticing. IAM roles don't store keys at all. They issue temporary, auto-expiring credentials. Even if someone intercepts them, the window of misuse is tiny. Roles also integrate naturally with zero-trust and least-privilege models, making them safer by design.

2. Can IAM roles be used across AWS accounts?
Absolutely. In fact, cross-account roles are one of the most powerful features in AWS security. Instead of sharing keys between accounts, you simply configure one account to trust another. Pipelines, auditors, security tools, or human operators can jump between accounts without ever needing long-term credentials. It's cleaner, safer, and scales beautifully in multi-account environments.

3. How do I find out who assumed a role and when?
AWS CloudTrail logs every role assumption event, including the source account, principal, session name, and IP address. Searching for AssumeRole events gives you a complete record of who accessed what and how they used it. This becomes incredibly valuable during security reviews, compliance checks, or incident investigations.

4. Why do some roles require MFA and others don't?
MFA-protected roles add an extra layer of identity verification for sensitive operations. If a role can modify infrastructure, manage users, or access confidential data, MFA ensures that even if a password or session token leaks, attackers can't assume the role. Developers usually protect admin, finance, or break-glass roles with MFA.

5. Why do we need trust policies and permission policies? Isn't one enough?
Think of it as a two-lock system. The trust policy ensures only the right actors can "enter the building." The permissions policy ensures that once inside, they can only perform approved actions. Removing either one opens the risk of privilege escalation. AWS's dual-policy structure is like a built-in firewall that forces least privilege from both directions.

6. Why can't we just give an EC2 instance access keys instead of using a role?
Technically you could, but it's a horrible practice. Hard-coding access keys into EC2 means those keys live somewhere on disk - in environment variables, config files, AMI templates, or app code. Anyone with access to that instance can copy the keys and use them outside AWS, completely bypassing your network controls. IAM roles solve this elegance by letting EC2 fetch short-lived credentials automatically through the instance metadata service. No keys to rotate, no keys to store, and no keys to leak - which is why roles are practically mandatory for all compute resources.

7. Why do temporary credentials expire, and can I stop them from expiring?
Temporary credentials expire to limit blast radius. If someone steals them, they only work for a short window. AWS intentionally prevents you from making them permanent - expiring credentials is part of the security model. You can extend session duration up to 12 hours for certain roles, but there is no way to create a non-expiring session. If your workflow needs uninterrupted access, the correct fix is automation that refreshes credentials, not longer credential lifetimes.

8. What happens internally when a role is assumed?
Behind the scenes, the AWS Security Token Service checks three things:

• whether the caller is allowed by the trust policy,
• whether the caller presented valid authentication, and
• whether conditions like MFA or External ID match.

If everything checks out, STS generates a temporary access key ID, secret access key, and session token. These credentials inherit only the permissions defined in the role's policies - nothing from the caller carries over. That's why even an admin user can assume a very restricted role and instantly operate with reduced permissions.

9. What's the difference between a service role and a service-linked role?
A normal service role is one you create for an AWS service to use. You decide the trust policy and permissions. A service-linked role, on the other hand, is created automatically by AWS when a service needs a very specific role to function. You can view the policy but not alter the trust relationship. Services like Amazon Lex, GuardDuty, and AWS Organizations rely on service-linked roles to guarantee correct operation without misconfiguration from your side.

10. How does an external provider like GitHub Actions assume a role using OIDC?
GitHub doesn't use AWS access keys. Instead, GitHub signs an OIDC token when your workflow runs. AWS validates that token using the GitHub OIDC identity provider you configure. If the token's conditions (repo name, branch, environment, etc.) match your IAM trust policy, AWS STS issues temporary credentials to the GitHub workflow. This allows pipelines to deploy securely with zero stored secrets - one of the cleanest CI/CD patterns available today.