# Managed policies and inline policies


When you set the permissions for an identity in IAM, you must decide whether to use an AWS 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? | 
| --- | --- | --- | --- | --- | 
| [AWS managed policies](#aws-managed-policies) | Standalone policy created and administered by AWS. | AWS | No | Many | 
| [Customer managed policies](#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](#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**
+ [

## AWS managed policies
](#aws-managed-policies)
+ [

## Customer managed policies
](#customer-managed-policies)
+ [

## Inline policies
](#inline-policies)
+ [

# Choose between managed policies and inline policies
](access_policies-choosing-managed-or-inline.md)
+ [

# Convert an inline policy to a managed policy
](access_policies-convert-inline-to-managed.md)
+ [

# Deprecated AWS managed policies
](access_policies_managed-deprecated.md)

## AWS managed policies


An *AWS managed policy* is a standalone policy that is created and administered by AWS. A *standalone policy* means that the policy has its own Amazon Resource Name (ARN) that includes the policy name. For example, `arn:aws:iam::aws:policy/IAMReadOnlyAccess` is an AWS managed policy. For more information about ARNs, see [IAM ARNs](reference_identifiers.md#identifiers-arns). For a list of AWS managed policies for AWS services, see [AWS managed policies](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/policy-list.html).

AWS 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 AWS managed policies. AWS occasionally updates the permissions defined in an AWS managed policy. When AWS does this, the update affects all principal entities (IAM users, IAM groups, and IAM roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API calls become available for existing services. For example, the AWS managed policy called **ReadOnlyAccess** provides read-only access to all AWS services and resources. When AWS launches a new service, AWS 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 AWS managed policies*: These define permissions for service administrators by granting full access to a service. Examples include:
+ [AmazonDynamoDBFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess.html)
+ [IAMFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/IAMFullAccess.html)

*Power-user AWS managed policies*: These provide full access to AWS services and resources, but do not allow managing users and IAM groups. Examples include:
+ [AWSCodeCommitPowerUser](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodeCommitPowerUser.html) 
+ [AWSKeyManagementServicePowerUser](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSKeyManagementServicePowerUser.html)

*Partial-access AWS managed policies*: These provide specific levels of access to AWS services without allowing [permissions management](access_policies_understand-policy-summary-access-level-summaries.md#access_policies_access-level) access level permissions. Examples include:
+ [AmazonMobileAnalyticsWriteOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonMobileAnalyticsWriteOnlyAccess.html)
+ [AmazonEC2ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ReadOnlyAccess.html) 

*Job function AWS 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 AWS as new services and API operations are introduced. For example, the [AdministratorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html) job function provides full access and permissions delegation to every service and resource in AWS. 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 AWS Organizations, use the [PowerUserAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/PowerUserAccess.html) job function. For a list and descriptions of the job function policies, see [AWS managed policies for job functions](access_policies_job-functions.md).

The following diagram illustrates AWS managed policies. The diagram shows three AWS managed policies: **AdministratorAccess**, **PowerUserAccess**, and **AWSCloudTrail\$1ReadOnlyAccess**. Notice that a single AWS managed policy can be attached to principal entities in different AWS accounts, and to different principal entities in a single AWS account.

![\[Diagram of AWS managed policies\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/policies-aws-managed-policies.diagram.png)


## Customer managed policies


You can create standalone policies in your own AWS 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 AWS 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 AWS 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)](reference_identifiers.md#identifiers-arns) 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](access_policies_create.md)

![\[Diagram of customer managed policies\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/policies-customer-managed-policies.diagram.png)


## 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.

![\[Diagram of inline policies\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/policies-inline-policies.diagram.png)


# Choose between managed policies and inline policies
Choose between managed or inline policies

Consider your use cases when deciding between managed and inline policies. In most cases, we recommend that you use managed policies instead of inline policies.

**Note**  
You can use both managed and inline policies together to define common and unique permissions for a principal entity.

Managed policies provide the following features:

**Reusability**  
A single managed policy can be attached to multiple principal entities (users, groups, and roles). You can create a library of policies that define useful permissions for your AWS account, and then attach these policies to principal entities as needed.

**Central change management**  
When you change a managed policy, the change is applied to all principal entities that the policy is attached to. For example, if you want to add permission for a new AWS API, you can update a customer managed policy or associate an AWS managed policy to add the permission. If you're using an AWS managed policy, AWS updates the policy. When a managed policy is updated, the changes are applied to all principal entities that the managed policy is attached to. In contrast, to change an inline policy, you must individually edit each identity that contains the inline policy. For example, if a group and a role both contain the same inline policy, you must individually edit both principal entities to change that policy. 

**Versioning and rolling back**  
When you change a customer managed policy, the changed policy doesn't overwrite the existing policy. Instead, IAM creates a new version of the managed policy. IAM stores up to five versions of your customer managed policies. You can use policy versions to revert a policy to an earlier version as needed.   
A policy version is different from a `Version` policy element. The `Version` policy element is used within a policy and defines the version of the policy language. To learn more about policy versions, see [Versioning IAM policies](access_policies_managed-versioning.md). To learn more about the `Version` policy element see [IAM JSON policy elements: Version](reference_policies_elements_version.md).

**Delegating permissions management**  
You can allow users in your AWS account to attach and detach policies while maintaining control over the permissions defined in those policies. To do this, designate some users as full administrators—that is, administrators that can create, update, and delete policies. You can then designate other users as limited administrators. Those limited administrators can attach policies to other principal entities, but only the policies that you have allowed them to attach.  
For more information about delegating permissions management, see [Controlling access to policies](access_controlling.md#access_controlling-policies). 

**Larger policy character limits**  
The maximum character size limit for managed policies is greater than the character limit for group inline policies. If you reach the inline policy's character size limit, you can create more IAM groups and attach the managed policy to the group.  
For more information on quotas and limits, see [IAM and AWS STS quotas](reference_iam-quotas.md). 

**Automatic updates for AWS managed policies**  
AWS maintains AWS managed policies and updates them when necessary, for example, to add permissions for new AWS services, without you having to make changes. The updates are automatically applied to the principal entities that you have attached the AWS managed policy to. 

## Get started with managed policies


We recommend using policies that [grant least privilege](access_policies.md#grant-least-priv), or granting only the permissions required to perform a task. The most secure way to grant least privilege is to write a customer managed policy with only the permissions needed by your team. You must create a process to allow your team to request more permissions when necessary. It takes time and expertise to [create IAM customer managed policies](access_policies_create-console.md) that provide your team with only the permissions they need.

To get started adding permissions to your IAM identities (users, groups of users, and roles), you can use [AWS managed policies](access_policies_managed-vs-inline.md#aws-managed-policies). AWS managed policies don't grant least privilege permissions. You must consider the security risk of granting your principals more permissions than they need to do their job.

You can attach AWS managed policies, including job functions, to any IAM identity. For more information, see [Adding and removing IAM identity permissions](access_policies_manage-attach-detach.md).

To switch to least privilege permissions, you can run AWS Identity and Access Management and Access Analyzer to monitor the principals with AWS managed policies. After learning which permissions they are using, then you can write or generate a customer managed policy with only the required permissions for your team. This is less secure, but provides more flexibility as you learn how your team is using AWS. For more information, see [IAM Access Analyzer policy generation](access-analyzer-policy-generation.md).

AWS managed policies are designed to provide permissions for many common use cases. For more information about AWS managed policies that are designed for specific job functions, see [AWS managed policies for job functions](access_policies_job-functions.md).

For a list of AWS managed policies, see [AWS Managed Policy Reference Guide](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/about-managed-policy-reference.html).

## Using inline policies


Inline policies are useful if you want to maintain a strict one-to-one relationship between a policy and the identity to which it is applied. For example, if you want to be sure that the permissions in a policy are not inadvertently assigned to an identity other than the one they're intended for. When you use an inline policy, the permissions in the policy cannot be inadvertently attached to the wrong identity. In addition, when you use the AWS Management Console to delete that identity, the policies embedded in the identity are deleted as well because they are part of the principal entity.

# Convert an inline policy to a managed policy
Convert inline policy to managed

If you have inline policies in your account, you can convert them to managed policies. To do this, copy the policy to a new managed policy. Next, attach the new policy to the identity that has the inline policy. Then delete the inline policy. 

## Converting an inline policy to a managed policy


**To convert an inline policy to a managed policy**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **User groups**, **Users**, or **Roles**.

1. In the list, choose the name of the user group, user, or role that has the policy you want to remove.

1. Choose the **Permissions** tab.

1. For IAM groups, select the name of the inline policy that you want to remove. For users and roles, choose **Show *n* more**, if necessary, and then expand the inline policy that you want to remove.

1. Choose **Copy** to copy the JSON policy document for the policy.

1. In the navigation pane, choose **Policies**.

1. Choose **Create policy** and then choose the **JSON** option.

1. Replace the existing text with your JSON policy text, and then choose **Next**.

1. Enter a name and optional description for your policy and choose **Create policy**.

1. In the navigation pane, choose **User groups**, **Users**, or **Roles**, and again choose the name of the user group, user, or role that has the policy you want to remove.

1. Choose the **Permissions** tab and then choose **Add permissions**.

1. For IAM groups, select the checkbox next to the name of your new policy, choose **Add permissions**, and then choose **Attach policy**. For users or roles, choose **Add permissions**. On the next page, choose **Attach existing policies directly**, select the checkbox next to the name of your new policy, choose **Next**, and then choose **Add permissions**.

   You are returned to the **Summary** page for your user group, user, or role.

1. Select the checkbox next to the inline policy that you want to remove and choose **Remove**.

# Deprecated AWS managed policies


To simplify the assignment of permissions, AWS provides [managed policies](access_policies_managed-vs-inline.md)—predefined policies that are ready to be attached to your IAM users, groups, and roles.

Sometimes AWS needs to add a new permission to an existing policy, such as when a new service is introduced. Adding a new permission to an existing policy does not disrupt or remove any feature or ability.

However, AWS might choose to create a *new* policy when the needed changes could impact customers if they were applied to an existing policy. For example, removing permissions from an existing policy could break the permissions of any IAM entity or application that depended upon it, potentially disrupting a critical operation.

Therefore, when such a change is required, AWS creates a completely new policy with the required changes and makes it available to customers. The old policy is then marked *deprecated*. For more information, see [Deprecated AWS managed policies](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/about-managed-policy-reference.html#deprecated-managed-policies) in *AWS Managed Policy Reference Guide*.