AWS IAM Study Note

2 min readSep 16, 2019

Identity-Based Policies and Resource-Based Policies

Policy is an object in AWS. When creating a permission policy, you choose identity-based or resource-based policy.

Identity-based policies:

Attached to IAM user, group or role.
Controls what actions an entity can perform on which resources under what condition.
Can be managed or inline.

Managed policies

Standalone identity-based policies that can attach to multiple entities in your AWS Account. You can use two types of managed policies:

AWS managed policies:
Managed policies that are created and managed by AWS.
Customer managed policies:
Managed policies that you create and manage in your AWS account which provide more precise control over your policies than AWS managed policies.

Inline policies

Policies that you create and managed and are embedded directly into a single user, group or role.

Using inline Policies

Inline policies are useful if you want to maintain a strict one-to-one relationship between a policy and the applied entity.

Resource-based policies:

Attached to resource.
Controls who has access to the resource and what actions are allowed.
Inline only, not managed.

Resource-Level Permission:

Refers to the ability to specify which resources users are allowed to perform actions on. Such as controlling what action user can perform under what condition or specific resources user is allowed to use. For example, you can grant users permissions to launch instances, but only of a specific type, and only using a specific AMI.

How IAM Roles Differ from Resource-based Policies

For AWS services that support resourced-based policies, you can grant cross-account access to your resources. Unlike user-based policy, resourced-based policies specifies who, in form of AWS account ID, can access the resource.

Cross-account access with a resource-based policy has some advantages over a role. With a resource that is accessed through a resource-based policy, the user still works in the trusted account and does not have to give up his or her user permissions in place of the role permissions.

In other words, the user continues to have access to resources in the trusted account at the same time as he or she has access to the resource in the trusting account.