Apart from users and groups, policies and roles are the most basic building blocks of AWS IAM.
IAM policies are JSON permission documents that define what actions are allowed or denied, on which AWS resources and under which conditions. Policies can be thought of as rule sets.
Roles, on the other hand, are identities that can be assumed—by users, groups, or services. Roles can have policies attached to them, and include trust policies that defined who can assume them. Unlike users, roles do not have long-term credentials and are thus safer to use for services.
Every IAM policy document is built from one or more statements, and each statement answers four key questions:
Effect is either Allow or Deny and determines whether the statement grants permissions or explicitly blocks them (explicit denies always win).
Action lists the API operations that are being controlled, usually in the form service:Operation such as s3:GetObject (wildcards like s3:* are possible but should be used carefully).
Resource specifies what the actions apply to by using ARNs (AWS Resource Names—unique resource identifiers), for example a specific bucket or object path, and can also use wildcards to match multiple resources.
Condition adds extra rules that must be true for the statement to apply, such as requiring a specific AWS region, source IP range, MFA present, or enforcing tags, which lets you scope the same actions and resources more safely.
Below is an example IAM policy:
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAllAwsReourcesOutsideAccountExceptAmazonS3",
"Effect": "Deny",
"NotAction": [
"s3:GetObject",
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"111122223333"
]
}
}
},
{
"Sid": "DenyAllS3ResourcesOutsideAccountExceptDataExchange",
"Effect": "Deny",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"111122223333"
]
},
"ForAllValues:StringNotEquals": {
"aws:CalledVia": [
"dataexchange.amazonaws.com"
]
}
}
}
]
}
You can see that the policy above:
111122223333, and111122223333(the account number 111122223333 is of course a placeholder).
As mentioned in previous section, AWS offers a lot of policies that it manages for users. These cannot be modified by users and usually provide access to particular services or actions. Many principals can be applied to managed policies.
Users can also create policies of their own and store them within the IAM system. These have to follow the syntax demonstrated above and can define actions, effects on resources under whatever conditions that users define. The advantage of defining your own policies is that they can be tailored for particular service needs. Unlike managed policies, user-defined policies can be modified.
<aside> ☝
An important advantage of user-defined IAM policies is that modifying the policy has immediate effect on any identity it’s attached to. That is a major advantage in dealing with adjusting permissions across multiple resources.
</aside>
Inline policies are the policies that map 1-to-1 to a given identity. For example, while creating a user an IAM policy can be manually specified and immediately attached to it. Inline policies can be modified, but can only ever be attached to one particular identity.
IAM roles are the preferred way to grant permissions to AWS compute and to enable controlled access between identities and services.
EC2 instance roles attach a role to an instance via an instance profile, so applications can retrieve short-lived credentials automatically from the instance metadata service (IMDS) instead of storing access keys on disk. Instance profiles can only contain one role.
<aside> ☝
AWS instance profiles can have their roles replaced, but it’s a slow process. It takes about an hour or so for an EC2 instance to pick up a role. It’s best to replace an instance profile instead.
</aside>
For cross-service access, AWS services can assume roles to act on your behalf, such as Lambda writing to S3 or EventBridge putting messages on an SQS queue, which keeps permissions scoped to exactly what that service needs. More generally, role assumption (via STS AssumeRole) lets a user, application, or service switch into a different set of permissions temporarily, including across accounts, based on the role’s trust policy and any session conditions like MFA or session tags.
A trust policy is a special IAM policy document that is attached to a role and defines who or what is allowed to assume that role and under which conditions. Unlike permission policies, which describe what actions are allowed on which resources, trust policies focus on the principal (an AWS account, IAM user or role, or an AWS service like EC2 or Lambda) that can call STS AssumeRole (or related actions) to obtain temporary credentials. Trust policies are commonly scoped using a Principal and Action (for example sts:AssumeRole) and can add Condition keys such as requiring MFA, restricting source IPs, or enforcing session tags, which helps keep role assumption tightly controlled.
Below is an example trust policy that allows the EC2 service to assume a role (typical for an instance role):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowEC2AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*
Built with ❤️ by the HackYourFuture community · Thank you, contributors
Found a mistake or have a suggestion? Let us know in the feedback form.