Troubleshoot IAM policies - AWS Identity and Access Management

Troubleshoot IAM policies

A policy is an entity in AWS that, when attached to an identity or resource, defines their permissions. AWS evaluates these policies when a principal, such as a user, makes a request. Permissions in the policies determine whether the request is allowed or denied. Policies are stored in AWS as JSON documents that are attached to principals as identity-based policies or to resources as resource-based policies. You can attach an identity-based policy to a principal (or identity), such as an IAM group, user, or role. Identity-based policies include AWS managed policies, customer managed policies, and inline policies. You can create and edit customer managed policies in the AWS Management Console using both Visual and JSON editor options. When you view a policy in the AWS Management Console, you can see a summary of the permissions that are granted by that policy. You can use the visual editor and policy summaries to help you diagnose and fix common errors encountered while managing IAM policies.

Keep in mind that all IAM policies are stored using syntax that begins with the rules of JavaScript Object Notation (JSON). You do not have to understand this syntax to create or manage your policies. You can create and edit a policy using the visual editor in the AWS Management Console. To learn more about JSON syntax in IAM policies, see Grammar of the IAM JSON policy language .

Troubleshooting IAM Policy Topics

Troubleshoot using the visual editor

When you create or edit a customer managed policy, you can use information in the Visual editor to help you troubleshoot errors in your policy. To view an example of using the visual editor to create a policy, see Controlling access to identities.

Policy restructuring

When you create a policy, AWS validates, processes, and transforms the policy before storing it. When the policy is retrieved, AWS transforms it back to a human-readable format without changing permissions. This can result in differences in what you see in the policy visual editor or JSON tab.

  • Visual editor permission blocks can be added, removed, or reordered, and content within a block can be optimized.

  • In the JSON tab, insignificant white space can be removed, and elements within JSON maps can be reordered. In addition, AWS account IDs within the principal elements can be replaced by the Amazon Resource Name (ARN) of the AWS account root user.

Because of these possible changes, you should not compare JSON policy documents as strings.

When you create a customer managed policy in the AWS Management Console, you can choose to work entirely in the JSON editor. If you never change the policy in the Visual editor and choose Next from the JSON editor, the policy is less likely to be restructured. When you use the Visual editor, IAM might restructure the policy to optimize its appearance. This restructuring exists only in your editing session and is not saved automatically.

If your policy is restructured in your editing session, IAM determines whether to save the restructuring based on the following situations:

Using this editor option If you edit your policy And then choose Next from this tab When you choose Save changes
Visual Edited Visual The policy is restructured
Visual Edited JSON The policy is restructured
Visual Not Edited Visual The policy is restructured
JSON Edited Visual The policy is restructured
JSON Edited JSON The policy structure is not changed
JSON Not Edited JSON The policy structure is not changed

IAM might restructure complex policies or policies that have permission blocks or statements that allow multiple services, resource types, or condition keys.

Choosing a resource ARN in the visual editor

When you create or edit a policy using the visual editor, you must first choose a service, and then choose actions from that service. If the service and actions that you selected support choosing specific resources, then the visual editor lists the supported resource types. You can then choose Add ARN to provide the details about your resource. You can choose from the following options for adding an ARN for a resource type.

  • Use the ARN builder – You might see different fields to build your ARN based on the resource type. You can also choose Any to provide permissions for any value for the specified setting. For example, if you selected the Amazon EC2 Read access level group, then the actions in your policy support the instance resource type. Provide the Region, Account, and InstanceId values for your resource. The policy grants permissions to any instance in your account if you provide your account ID and choose Any for the Region and instance ID.

  • Type or paste the ARN – You can specify resources by their Amazon Resource Name (ARN). You can include a wildcard character (*) in any field of the ARN (between each pair of colons). For more information, see IAM JSON policy elements: Resource.

Denying permissions in the visual editor

By default, the policy that you create using the visual editor allows the actions that you choose. To deny the chosen actions instead, choose Switch to deny permissions. Because requests are denied by default, we recommend that you allow permissions to only those actions and resources that a user needs. You should create a deny statement only if you want to override a permission separately that is allowed by another statement or policy. We recommend that you limit the number of deny permissions to a minimum because they can increase the difficulty of troubleshooting permissions. For more information about how IAM evaluates policy logic, see Policy evaluation logic.

Note

By default, only the AWS account root user has access to all the resources in that account. So if you are not signed in as the root user, you must have permissions granted by a policy.

Specifying multiple services in the visual editor

When you use the visual editor to construct a policy, you can select only one service at a time. This is a best practice because the visual editor then allows you to choose from the actions for that one service. You then choose from the resources supported by that service and the selected actions. This makes it easier to create and troubleshoot your policy.

You can also use a wildcard character (*) to manually specify multiple services. For example, type Code* to provide permissions for all services beginning with Code, such as CodeBuild and CodeCommit. However, you must then type the actions and resource ARNs to complete your policy. Additionally, when you save your policy, it might be restructured to include each service in a separate permission block.

Alternatively, to use JSON syntax (such as wildcards) for services, create, edit, and save your policy using the JSON editor option.

Reducing the size of your policy in the visual editor

When you use the visual editor to create a policy, IAM creates a JSON document to store your policy. You can view this document by switching to the JSON editor option. If this JSON document exceeds the size limit of a policy, the visual editor displays an error message. You will not be able to review and save the policy. To view the IAM limitation on the size of a managed policy, see IAM and STS character limits.

To reduce the size of your policy in the visual editor, edit your policy or move permission blocks to another policy. The error message includes the number of characters that your policy document contains. You can use this information to help you reduce the size of your policy.

Fixing unrecognized services, actions, or resource types in the visual editor

You might see a warning in the visual editor that your policy includes an unrecognized service, action, or resource type.

Note

IAM reviews service names, actions, and resource types for services that support policy summaries. However, your policy summary might include a resource value or condition that does not exist. Always test your policies with the policy simulator.

If your policy includes unrecognized services, actions or resource types, one of the following errors has occurred:

  • Preview service – Services that are in preview do not support the visual editor. If you are participating in the preview, you must manually type the actions and resource ARNs to complete your policy. You can ignore any warnings and continue. Alternatively, you can choose the JSON editor option to type or paste a JSON policy document.

  • Custom service – Custom services do not support the visual editor. If you are using a custom service, you must manually type the actions and resource ARNs to complete your policy. You can ignore any warnings and continue. Alternatively, you can choose the JSON editor option to type or paste a JSON policy document.

  • Service does not support the visual editor – If your policy includes a generally available (GA) service that does not support the visual editor, you must manually type the actions and resource ARNs to complete your policy. You can ignore any warnings and continue. Alternatively, you can choose the JSON editor option to type or paste a JSON policy document.

    Generally available services are services that are released publicly and are not preview or custom services. If an unrecognized service is generally available and the name is spelled correctly, then the service does not support the visual editor. To learn how to request visual editor or policy summary support for a GA service, see Service does not support IAM policy summaries.

  • Action does not support the visual editor – If your policy includes a supported service with an unsupported action, you must manually type the actions and resource ARNs to complete your policy. You can ignore any warnings and continue. Alternatively, you can choose the JSON editor option to type or paste a JSON policy document.

    If your policy includes a supported service with an unsupported action, then the service does not fully support the visual editor. To learn how to request visual editor or policy summary support for a GA service, see Service does not support IAM policy summaries.

  • Resource type does not support the visual editor – If your policy includes a supported action with an unsupported resource type, you can ignore the warning and continue. However, IAM cannot confirm that you have included resources for all of your selected actions, and you might see additional warnings.

  • Typo – When you manually type a service, action, or resource in the visual editor, you can create a policy that includes a typo. We recommend that you use the visual editor by selecting from the list of services and actions. Then, complete the resource section according to the prompts. If a service does not fully support the visual editor, you might have to manually type parts of your policy.

    If you are certain that your policy contains none of the errors above, then your policy might include a typo. Check for the following issues:

    • Misspelled service, action, and resource type names, such as s2 instead of s3 or ListMyBuckets instead of ListAllMyBuckets

    • Unnecessary text in ARNs, such as arn:aws:s3: : :*

    • Missing colons in actions, such as iam.CreateUser

    You can evaluate a policy that might include typos by choosing Next to review the policy summary. Then, confirm whether the policy provides the permissions you intended.

Troubleshoot with policy summaries

You can diagnose and resolve issues related to policy summaries.

Missing policy summary

The IAM console includes policy summary tables that describe the access level, resources, and conditions that are allowed or denied for each service in a policy. Policies are summarized in three tables: the policy summary, the service summary, and the action summary. The policy summary table includes a list of services and summaries of the permissions that are defined by the chosen policy. You can view the policy summary for any policies that are attached to an entity on the Policy details page for that policy. You can view the policy summary for managed policies on the Policies page. If AWS is unable to render a summary for a policy, you will see the JSON policy document and the following error:

A summary for this policy cannot be generated. You can still view or edit the JSON policy document.

If your policy does not include a summary, one of the following errors has occurred:

  • Unsupported policy element – IAM does not support generating policy summaries for policies that include one of the following policy elements:

    • Principal

    • NotPrincipal

    • NotResource

  • No policy permissions – If a policy does not provide any effective permissions, then the policy summary cannot be generated. For example, if a policy includes a single statement with the element "NotAction": "*", then it grants access to all actions except "all actions" (*). This means it grants Deny or Allow access to nothing.

    Note

    Be careful when using these policy elements such as NotPrincipal, NotAction, and NotResource. For information about using policy elements, see IAM JSON policy element reference.

    If you provide mismatched services and resources, you can create a policy that does not provide effective permissions. This can occur when you specify actions in one service and resources from another service. In this case, the policy summary does appear. The only indication that there is a problem is that the resource column in the summary can include a resource from a different service. If this column includes a mismatched resource, then you should review your policy for errors. Test your policies with the policy simulator to better understand the policy.

Policy summary includes unrecognized services, actions, or resource types

In the IAM console, if a policy summary includes a warning symbol ( Warning hazard sign icon with yellow triangle background. ), then the policy might include an unrecognized service, action, or resource type. To learn about warnings within a policy summary, see Policy summary (list of services).

Note

IAM reviews service names, actions, and resource types for services that support policy summaries. However, your policy summary might include a resource value or condition that does not exist. Always test your policies with the policy simulator.

If your policy includes unrecognized services, actions or resource types, one of the following errors has occurred:

  • Preview service – Services that are in preview do not support policy summaries.

  • Custom service – Custom services do not support policy summaries.

  • Service does not support summaries – If your policy includes a generally available (GA) service that does not support policy summaries, then the service is included in the Unrecognized services section of the policy summary table. Generally available services are services that are released publicly and are not preview or custom services. If an unrecognized service is generally available and the name is spelled correctly, then the service does not support IAM policy summaries. To learn how to request policy summary support for a GA service, see Service does not support IAM policy summaries.

  • Action does not support summaries – If your policy includes a supported service with an unsupported action, then the action is included in the Unrecognized actions section of the service summary table. To learn about warnings within a service summary, see Service summary (list of actions).

  • Resource type does not support summaries – If your policy includes a supported action with an unsupported resource type, then the resource is included in the Unrecognized resource types section of the service summary table. To learn about warnings within a service summary, see Service summary (list of actions).

  • Typo – AWS checks that the JSON is syntactically correct, and that the policy does not include typos or other errors as part of policy validation.

Note

As a best practice, we recommend that you use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions. We recommend that you open your existing policies and review and resolve any policy validation recommendations.

Service does not support IAM policy summaries

It is possible for the IAM policy summaries or the visual editor to not support a generally available (GA) service or action. Generally available services are services that are released publicly and are not previewed or custom services. If an unrecognized service is generally available and the name is spelled correctly, then the service does not support these features. If your policy includes a supported service with an unsupported action, then the service does not fully support IAM policy summaries.

To request that a service add IAM policy summary or visual editor support
  1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.

  2. Locate the policy that includes the unsupported service:

    • If the policy is a managed policy, choose Policies in the navigation pane. In the list of policies, choose the name of the policy that you want to view.

    • If the policy is an inline policy attached to the user, choose Users in the navigation pane. In the list of users, choose the name of the user whose policy you want to view. In the table of policies for the user, expand the header for the policy summary that you want to view.

  3. In the left side on the AWS Management Console footer, choose Feedback. In the Feedback for IAM box, type I request that the <ServiceName> service add support for IAM policy summaries and the visual editor. If you want more than one service to support summaries, type I request that the <ServiceName1>, <ServiceName2>, and <ServiceName3> services add support for IAM policy summaries and the visual editor.

To request that a service add IAM policy summary support for a missing action
  1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.

  2. Locate the policy that includes the unsupported service:

    • If the policy is a managed policy, choose Policies in the navigation pane. In the list of policies, choose the name of the policy that you want to view.

    • If the policy is an inline policy attached to the user, choose Users in the navigation pane. In the list of users, choose the name of the user whose policy you want to view. In the table of policies for the user, choose the name of the policy that you want to view to expand the policy summary.

  3. In the policy summary, choose the name of the service that includes an unsupported action.

  4. In the left side on the AWS Management Console footer, choose Feedback. In the Feedback for IAM box, type I request that the <ServiceName> service add IAM policy summary and the visual editor support for the <ActionName> action. If you want to report more than one unsupported action, type I request that the <ServiceName> service add IAM policy summary and the visual editor support for the <ActionName1>, <ActionName2>, and <ActionName3> actions.

To request that a different service includes missing actions, repeat the last three steps.

My policy does not grant the expected permissions

To assign permissions to a user, group, role, or resource, you create a policy, which is a document that defines permissions. The policy document includes the following elements:

  • Effect – whether the policy allows or denies access

  • Action – the list of actions that are allowed or denied by the policy

  • Resource – the list of resources on which the actions can occur

  • Condition (Optional) – the circumstances under which the policy grants permission

To learn about these and other policy elements, see IAM JSON policy element reference.

To grant access, your policy must define an action with a supported resource. If your policy also includes a condition, that condition must include a global condition key or must apply to the action. To learn which resources are supported by an action, see the AWS documentation for your service. To learn which conditions are supported by an action, see Actions, Resources, and Condition Keys for AWS Services.

Check whether your policy defines an action, resource, or condition that does not grant permissions. View the policy summary for your policy using the IAM console at https://console.aws.amazon.com/iam/. You can use policy summaries to identify and correct problems in your policy.

There are several reasons why an element might not grant permissions despite being defined in the IAM policy:

To view examples of policy summaries that include warnings, see Policy summary (list of services).

An action is defined without an applicable resource

The policy below defines all ec2:Describe* actions and defines a specific resource. None of the ec2:Describe actions are granted because none of these actions support resource-level permissions. Resource-level permissions mean that the action supports resources using ARNs in the policy's Resource element. If an action does not support resource-level permissions, then that statement in the policy must use a wildcard (*) in the Resource element. To learn which services support resource-level permissions, see AWS services that work with IAM.

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "arn:aws:ec2:us-east-2:ACCOUNT-ID:instance/*" }] }

This policy does not provide any permissions, and the policy summary includes the following error:

This policy does not grant any permissions. To grant access, policies must have an action that has an applicable resource or condition.

To fix this policy, you must use * in the Resource element.

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }] }

A resource is defined without an applicable action

The policy below defines an Amazon S3 bucket resource but does not include an S3 action that can be performed on that resource. This policy also grants full access to all Amazon CloudFront actions.

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "cloudfront:*", "Resource": [ "arn:aws:cloudfront:*", "arn:aws:s3:::amzn-s3-demo-bucket" ] }] }

This policy provides permissions for all CloudFront actions. But because the policy defines the S3 amzn-s3-demo-bucket resource without defining any S3 actions, the policy summary includes the following warning:

This policy defines some actions, resources, or conditions that do not provide permissions. To grant access, policies must have an action that has an applicable resource or condition.

To fix this policy to provide S3 bucket permissions, you must define S3 actions that can be performed on a bucket resource.

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "cloudfront:*", "s3:CreateBucket", "s3:ListBucket*", "s3:PutBucket*", "s3:GetBucket*" ], "Resource": [ "arn:aws:cloudfront:*", "arn:aws:s3:::amzn-s3-demo-bucket" ] }] }

Alternately, to fix this policy to provide only CloudFront permissions, remove the S3 resource.

A condition is defined without an applicable action

The policy below defines two Amazon S3 actions for all S3 resources, if the S3 prefix equals custom and the version ID equals 1234. However, the s3:VersionId condition key is used for object version tagging and is not supported by the defined bucket actions. To learn which conditions are supported by an action, see Actions, Resources, and Condition Keys for AWS Services and choose the service to view service documentation for condition keys.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucketVersions", "s3:ListBucket" ], "Resource": "*", "Condition": { "StringEquals": { "s3:prefix": [ "custom" ], "s3:VersionId": [ "1234" ] } } } ] }

This policy provides permissions for the s3:ListBucketVersions action and the s3:ListBucket action if the bucket name includes the custom prefix. But because the s3:VersionId condition is not supported by any of the defined actions, the policy summary includes the following error:

This policy does not grant any permissions. To grant access, policies must have an action that has an applicable resource or condition.

To fix this policy to use S3 object version tagging, you must define an S3 action that supports the s3:VersionId condition key.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucketVersions", "s3:ListBucket", "s3:GetObjectVersion" ], "Resource": "*", "Condition": { "StringEquals": { "s3:prefix": [ "custom" ], "s3:VersionId": [ "1234" ] } } } ] }

This policy provides permissions for every action and condition in the policy. However, the policy still does not provide any permissions because there is no case where a single action matches both conditions. Instead, you must create two separate statements that each include only actions with the conditions to which they apply.

To fix this policy, create two statements. The first statement includes the actions that support the s3:prefix condition, and the second statement includes the actions that support the s3:VersionId condition.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucketVersions", "s3:ListBucket" ], "Resource": "*", "Condition": { "StringEquals": { "s3:prefix": "custom" } } }, { "Effect": "Allow", "Action": "s3:GetObjectVersion", "Resource": "*", "Condition": { "StringEquals": { "s3:VersionId": "1234" } } } ] }

Troubleshoot policy management

You can diagnose and resolve issues relating to policy management.

Attaching or detaching a policy in an IAM account

Some AWS managed policies are linked to a service. These policies are used only with a service-linked role for that service. In the IAM console, when you view the Policy details page, the page includes a banner to indicate that the policy is linked to a service. You cannot attach this policy to a user, group, or role within IAM. When you create a service-linked role for the service, this policy is automatically attached to your new role. Because the policy is required, you cannot detach the policy from the service-linked role.

Changing policies for your IAM identities based on their activity

You can update policies for your IAM identities (users, groups, and roles) based on their activity. To do this, view your account's events in CloudTrail Event history. CloudTrail event logs include detailed event information that you can use to change the policy's permissions.

A user or role is attempting to perform an action in AWS and that request is denied.

Consider whether the user or role should have permission to perform the action. If so, you can add the action and even the ARN of the resource that they attempted to access to their policy.

A user or role has permissions that they are not using.

Consider removing those permissions from their policy. Make sure that your policies grant the least privilege that is needed to perform only the necessary actions.

For more information about using CloudTrail, see Viewing CloudTrail Events in the CloudTrail Console in the AWS CloudTrail User Guide.

Troubleshoot JSON policy documents

You can diagnose and resolve issues relating to JSON policy documents.

Validate your policies

When you create or edit a JSON policy, IAM can perform policy validation to help you create an effective policy. IAM identifies JSON syntax errors, while IAM Access Analyzer provides additional policy checks with recommendations to help you further refine your policies. To learn more about policy validation, see IAM policy validation. To learn more about IAM Access Analyzer policy checks and actionable recommendations, see IAM Access Analyzer policy validation.

I don't have permissions for policy validation in the JSON editor

In the AWS Management Console, you might receive the following error if you do not have permissions to view IAM Access Analyzer policy validation results:

You need permissions. You do not have the permissions required to perform this operation. Ask your administrator to add permissions.

To fix this error, ask your administrator to add the access-analyzer:ValidatePolicy permission for you.

More than one JSON policy object

An IAM policy must consist of only one JSON object. You denote an object by placing { } braces around it. You can nest other objects within a JSON object by embedding additional { } braces within the outer pair. A policy must contain only one outermost pair of { } braces. The following example is incorrect because it contains two objects at the top level (called out in red):

{ "Version": "2012-10-17", "Statement": { "Effect":"Allow", "Action":"ec2:Describe*", "Resource":"*" } } { "Statement": { "Effect": "Allow", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*" } }

You can, however, meet the intention of the previous example with the use of correct policy grammar. Instead of including two complete policy objects each with its own Statement element, you can combine the two blocks into a single Statement element. The Statement element has an array of two objects as its value, as shown in the following example (called out in bold):

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource":" *" }, { "Effect": "Allow", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*" } ] }

More than one JSON statement element

This error might at first appear to be a variation on the previous section. However, syntactically it is a different type of error. The following example has only one policy object as denoted by a single pair of { } braces at the top level. However, that object contains two Statement elements within it.

An IAM policy must contain only one Statement element, consisting of the name (Statement) appearing to the left of a colon, followed by its value on the right. The value of a Statement element must be an object, denoted by { } braces, containing one Effect element, one Action element, and one Resource element. The following example is incorrect because it contains two Statement elements in the policy object (called out in red):

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }, "Statement": { "Effect": "Allow", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*" } }

A value object can be an array of multiple value objects. To solve this problem, combine the two Statement elements into one element with an object array, as shown in the following example (called out in bold):

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource":"*" }, { "Effect": "Allow", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*" } ] }

The value of the Statement element is an object array. The array in this example consists of two objects, each of which is by itself is a correct value for a Statement element. Each object in the array is separated by commas.

More than one effect, action, or resource element in a JSON statement element

On the value side of the Statement name/value pair, the object must consist of only one Effect element, one Action element, and one Resource element. The following policy is incorrect because it has two Effect elements in the Statement:

{ "Version": "2012-10-17", "Statement": { "Effect": "Deny", "Effect": "Allow", "Action": "ec2:* ", "Resource": "*" } }
Note

The policy engine does not allow such errors in new or edited policies. However, the policy engine continues to permit policies that were saved before the engine was updated. The behavior of existing policies with the error is as follows:

  • Multiple Effect elements: only the last Effect element is observed. The others are ignored.

  • Multiple Action elements: all Action elements are combined internally and treated as if they are a single list.

  • Multiple Resource elements: all Resource elements are combined internally and treated as if they are a single list.

The policy engine does not allow you to save any policy with syntax errors. Correct the errors in the policy before saving. Review and correct any policy validation recommendations for your policies.

In each case, the solution is to remove the incorrect extra element. For Effect elements, this is straightforward: if you want the previous example to deny permissions to Amazon EC2 instances, then you must remove the line "Effect": "Allow", from the policy, as follows:

{ "Version": "2012-10-17", "Statement": { "Effect": "Deny", "Action": "ec2:* ", "Resource": "*" } }

However, if the duplicate element is Action or Resource, then the resolution can be more complicated. You might have multiple actions that you want to allow (or deny) permission to, or you might want to control access to multiple resources. For example, the following example is incorrect because it has multiple Resource elements (called out in red):

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*" } }

Each of the required elements in a Statement element's value object can be present only once. The solution is to place each value in an array. The following example illustrates this by making the two separate resource elements into one Resource element with an array as the value object (called out in bold):

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ] } }

Missing JSON version element

A Version policy element is different from a policy version. The Version policy element is used within a policy and defines the version of the policy language. In comparison, a policy version is created when you change a customer managed policy in IAM. The changed policy doesn't overwrite the existing policy. Instead, IAM creates a new version of the managed policy. To learn more about the Version policy element see IAM JSON policy elements: Version. To learn more about policy versions, see Versioning IAM policies.

As AWS features evolve, new capabilities are added to IAM policies to support those features. Sometimes, an update to the policy syntax includes a new version number. If you use newer features of the policy grammar in your policy, then you must tell the policy parsing engine which version you are using. The default policy version is "2008-10-17." If you want to use any policy feature that was introduced later, then you must specify the version number that supports the feature you want. We recommend that you always include the latest policy syntax version number, which is currently "Version": "2012-10-17". For example, the following policy is incorrect because it uses a policy variable ${...} in the ARN for a resource. But it fails to specify a policy syntax version that supports policy variables (called out in red):

{ "Statement": { "Action": "iam:*AccessKey*", "Effect": "Allow", "Resource": "arn:aws:iam::123456789012:user/${aws:username}" } }

Adding a Version element at the top of the policy with the value 2012-10-17, the first IAM API version that supports policy variables, solves this problem (called out in bold):

{ "Version": "2012-10-17", "Statement": { "Action": "iam:*AccessKey*", "Effect": "Allow", "Resource": "arn:aws:iam::123456789012:user/${aws:username}" } }