IAM Role
An IAM Role is an AWS identity with temporary, automatically rotating credentials, designed for services and applications rather than humans. EC2 instances, Lambda functions, and ECS tasks assume a role to access other AWS services, receiving short-lived credentials that expire on their own — eliminating the risk of long-lived access keys sitting exposed on disk indefinitely.
A payments backend attaches an IAM Role to its EC2 fleet instead of running aws configure with a developer's personal keys; the SDK fetches temporary credentials from the instance metadata service automatically, valid for a few hours, with nothing sensitive ever written to disk.
Trust Policy
Every role has a trust policy defining exactly which principal is allowed to assume it — an EC2 service principal, a Lambda service principal, or another AWS account for cross-account access.
Cross-Account Access: Two Patterns
- Role assumption — you switch identities; your original account's permissions pause while assumed
- Resource-based policy — the target resource invites you in; your original permissions stay active
Common MistakeRunning
aws configureon an EC2 instance with personal access keys. This is one of the most common paths to an AWS account compromise — attach a role instead.
Frequently Asked Questions
Why do IAM roles replace long-lived access keys for services like EC2 and Lambda?
A role has no permanent credentials at all — when an EC2 instance or Lambda function assumes it, AWS's Security Token Service issues temporary credentials (typically valid for up to an hour, automatically refreshed) via the instance metadata service or Lambda's execution environment. This means there's no access key sitting in a config file or environment variable that could leak in a git commit or log line, since the credentials expire on their own within hours.
What's the most common mistake teams make when scoping IAM role permissions?
Attaching AdministratorAccess or overly broad managed policies to a role because it's faster than writing a scoped policy, then never revisiting it. This violates least privilege and turns a single compromised Lambda or EC2 instance into a path to the whole account. Best practice: start with a minimal policy covering only the actions and resources the workload actually calls, and use IAM Access Analyzer to identify unused permissions over time.