How to Create Customer-Managed Policies in AWS
When you initially create your AWS (Amazon Web Services) account, only one AWS-managed policy is in place: AdministratorAccess. However, after you create the first user and log in to AWS using your new administrator account, you can access a large number of AWS-managed policies.
Whenever possible, you should use the AWS-managed policies to ensure that the policy receives automatic updates that reflect changes in AWS functionality. When using a customer-managed policy, you must perform any required updates manually. The following steps get you started using customer-managed policies.
- Sign in to AWS using your administrator account.
- Navigate to the IAM Management Console.
- Select Policies in the Navigation pane.
You see the Welcome to Managed Policies page.
- Click Get Started.
You see a list of available AWS-managed policies, as shown. Each of the policy names starts with the word Amazon (to show that it’s an AWS-managed policy), followed by the service name (EC2 in the figure), optionally followed by the target of the permission (such as ContainerRegistry), and ending with the kind of permission granted (such as FullAccess). When creating your own customer-managed policies, it’s good to follow the same practice to make the names easier to use and consistent with their AWS-managed counterparts.
Note that the policy list tells you the number of entities attached to a policy so that you know whether a policy is actually in use. You can also see the policy creation time and the time someone last edited it. The symbol on the left side of the policy shows the policy type, which is a stylized cube for AWS-managed policies.
Before you create a customer-managed policy, make certain no AWS-managed policy exists that serves the same purpose. Using the AWS-managed policy is simpler, less error prone, and provides automatic updates as needed.
- Click Create Policy.
You see the Create Policy page, shown. AWS provides three options for creating a new policy (in order of complexity):
- Copy an AWS Managed Policy: An AWS-managed policy acts as a starting point. You then make changes required to customize the policy for your needs. Because this option helps ensure that you create a usable policy and requires the least work, you should use it whenever possible. This example assumes that you copy an existing AWS-managed policy because you follow this route most often.
- Policy Generator: Relies on a wizardlike interface to either allow or deny actions against an AWS service. You can assign the permission to specific resources (in some cases) using an Amazon Resource Name, ARN, or to all resources (using an *, asterisk). (The discussion describes how to create and use ARNs.) A policy can contain multiple permissions, each of which appears as a statement within the policy. After you define policies, the wizard shows you the policy document, which you can edit manually if desired. The wizard uses the policy document to generate the policy. This is the best option to use when you need a single policy to cover multiple services.
- Create Your Own Policy: Defines a policy completely by hand. All you see is the policy document page, which you must fill in manually using appropriate syntax and grammar. The discussion tells you more about how to create a policy completely manually. You use this option only when necessary because the time involved in creating the document is substantial and the potential for error is high.
- Click Copy an AWS-Managed Policy.
You see a listing of AWS-managed policies.
- Click Select next to the AWS-Managed policy that you want to use as the basis for your customer-managed policy.
The example uses the AmazonEC2FullAccess policy as a starting point, but the same steps apply to modifying other policies. You see the Review Policy page shown.
Starting with a policy that has too many rights and removing the rights you don’t want is significantly easier than starting with a policy that has too few rights and adding the rights you need. Adding rights entails typing new entries into the policy document, which requires a detailed knowledge of policies. Removing rights means highlighting the right statements you don’t want and deleting them.
- Type a new name in the Policy Name field.
The example uses MyCompanyEC2FullAccessNoCloudWatch as the policy name.
- Modify the Description field as needed to define the changes made.
The example adds that the policy doesn’t allow access to CloudWatch.
- Modify the Policy Document field as needed to reflect policy changes.
The example removes the following policy section from the document:
Make certain that you add and remove commas between policies as needed, or the policy won’t work as expected.
- Click Validate Policy.
If the changes you made work as intended, you see a This Policy Is Valid success message at the top of the page. Always validate your policy before you create it.
- Click Create Policy.
You see a success message on the Policies page, plus a new entry for your policy, as shown. Note that your policy doesn’t include a policy type icon. The lack of an icon makes the policy easier to find in the list.