Roles
A role is a stable IAM identity without its own long-term access keys; assuming it produces temporary session credentials. These role labels describe how a role is used; they do not create different authorization engines.
Role distinctions
- A service role is assumed by an AWS service to perform configured work. Trust the correct service principal and constrain its permissions.
- A service-linked role has a service-defined trust/permission lifecycle. Remove dependent resources before requesting deletion and inspect the deletion-task result.
- A cross-account role trusts authorized external principals. Trust alone does not necessarily authorize an originating IAM caller; evaluate both sides and any session/organization restrictions.
- An EC2 instance profile delivers role credentials to a workload. A profile is a container for the role, not an independent permission grant.
- A Lambda execution role authorizes function activity, not invocation by a client. Invocation permission is a different policy.
- An ECS task role authorizes application calls; its execution role authorizes supported startup operations such as image pull/log delivery. Do not put application permissions only in the execution role.
Role handoff map
caller principal → role trust policy → STS temporary session
└→ role permissions + guardrails
EC2 instance → instance profile → attached role
Lambda service → function execution role
ECS agent/startup → task execution role
ECS application → task roleFor each integration, identify who assumes the role and which operation the resulting session performs. An EC2 instance role is supplied through an instance profile; a Lambda execution role enables function code and service setup to call permitted AWS APIs; an ECS task execution role helps startup, while the task role reaches AWS services from the application. A cross-account role needs both a trust entry and source/destination authorization checks. A service-linked role has a service-defined lifecycle and can usually be removed only after its dependent resources are gone.
Trust versus permission test
Begin with IAM and evaluation rules. For a disposable role, have an administrator inspect its trust policy and attached policies. Try an authorized AssumeRole request, then one from a principal excluded by trust; expect the latter to fail before target actions can execute.
Use external IDs for applicable third-party delegation; an external ID is not a secret credential. Record the session identity through STS and audit session attribution in CloudTrail. Remove the lab role only after dependent resources and sessions have been considered.
Operational safeguards
Scope PassRole to the exact intended role/service; it is not permission to call AssumeRole. Avoid wildcards in trust principals without deliberate conditions. Never paste temporary credentials into notes or logs. Permission boundaries/guardrails are upper bounds, not permission grants.