Managed policies and inline policies
When you set the permissions for an identity in IAM, you must decide whether to use an Amazon managed policy, a customer managed policy, or an inline policy. The following topics provide more information about each of the types of identity-based policies and when to use them.
The following table outlines these policies:
| Policy Type | Description | Who manages the policy? | Modify permissions? | Number of principals applied to policy? |
|---|---|---|---|---|
| Amazon managed policies | Standalone policy created and administered by Amazon. | Amazon | No | Many |
| Customer managed policies | Policy you create for specific use cases, and you can change or update them as often as you like. | You | Yes | Many |
| Inline policies | Policy created for a single IAM identity (user, group, or role) that maintains a strict one-to-one relationship between a policy and an identity. | You | Yes | One |
Topics
Amazon managed policies
An Amazon managed policy is a standalone policy that is created and
administered by Amazon. A standalone policy means that the policy has its
own Amazon Resource Name (ARN) that includes the policy name. For example,
arn:aws-cn:iam::aws:policy/IAMReadOnlyAccess is an Amazon managed policy. For
more information about ARNs, see IAM ARNs. For a list of Amazon managed policies for Amazon Web Services services,
see Amazon managed policies.
Amazon managed policies make it convenient for you to assign appropriate permissions to users, IAM groups, and roles. It is faster than writing the policies yourself, and includes permissions for many common use cases.
You cannot change the permissions defined in Amazon managed policies. Amazon occasionally updates the permissions defined in an Amazon managed policy. When Amazon does this, the update affects all principal entities (IAM users, IAM groups, and IAM roles) that the policy is attached to. Amazon is most likely to update an Amazon managed policy when a new Amazon service is launched or new API calls become available for existing services. For example, the Amazon managed policy called ReadOnlyAccess provides read-only access to all Amazon Web Services services and resources. When Amazon launches a new service, Amazon updates the ReadOnlyAccess policy to add read-only permissions for the new service. The updated permissions are applied to all principal entities that the policy is attached to.
Full access Amazon managed policies: These define permissions for service administrators by granting full access to a service. Examples include:
Power-user Amazon managed policies: These provide full access to Amazon Web Services services and resources, but do not allow managing users and IAM groups. Examples include:
Partial-access Amazon managed policies: These provide specific levels of access to Amazon Web Services services without allowing permissions management access level permissions. Examples include:
Job function Amazon managed policies: These policies align closely with commonly used job functions in the IT industry and facilitate granting permissions for these job functions. One key advantage of using job function policies is that they are maintained and updated by Amazon as new services and API operations are introduced. For example, the AdministratorAccess job function provides full access and permissions delegation to every service and resource in Amazon. We recommend that you use this policy only for the account administrator. For power users that require full access to every service except limited access to IAM and Amazon Organizations, use the PowerUserAccess job function. For a list and descriptions of the job function policies, see Amazon managed policies for job functions.
The following diagram illustrates Amazon managed policies. The diagram shows three Amazon managed policies: AdministratorAccess, PowerUserAccess, and AmazonCloudTrail_ReadOnlyAccess. Notice that a single Amazon managed policy can be attached to principal entities in different Amazon Web Services accounts, and to different principal entities in a single Amazon Web Services account.
Customer managed policies
You can create standalone policies in your own Amazon Web Services account that you can attach to principal entities (IAM users, IAM groups, and IAM roles). You create these customer managed policies for your specific use cases, and you can change and update them as often as you like. Like Amazon managed policies, when you attach a policy to a principal entity, you give the entity the permissions that are defined in the policy. When you update permissions in the policy, the changes are applied to all principal entities that the policy is attached to.
A great way to create a customer managed policy is to start by copying an existing Amazon managed policy. That way you know that the policy is correct at the beginning and all you need to do is customize it to your environment.
The following diagram illustrates customer managed policies. Each policy is an entity in IAM with its own Amazon Resource Name (ARN) that includes the policy name. Notice that the same policy can be attached to multiple principal entities—for example, the same DynamoDB-books-app policy is attached to two different IAM roles.
For more information, see Define custom IAM permissions with customer managed policies
Inline policies
An inline policy is a policy created for a single IAM identity (a user, user group, or role). Inline policies maintain a strict one-to-one relationship between a policy and an identity. They are deleted when you delete the identity. You can create a policy and embed it in an identity, either when you create the identity or later. If a policy could apply to more than one entity, it’s better to use a managed policy.
The following diagram illustrates inline policies. Each policy is an inherent part of the user, group, or role. Notice that two roles include the same policy (the DynamoDB-books-app policy), but they are not sharing a single policy. Each role has its own copy of the policy.
