Menu
AWS Identity and Access Management
User Guide

Troubleshooting General Issues

Use the information here to help you diagnose and fix access-denied or other common issues that you might encounter when working with AWS Identity and Access Management (IAM).

I lost my access keys.

Access keys consist of two parts:

  • The access key identifier. This is not a secret, and can be seen in the IAM console wherever access keys are listed, such as on the user summary page.

  • The secret access key. This is provided when you initially create the access key pair. Just like a password, it cannot be retrieved later. If you cannot find your secret access key then you must delete the access key pair and recreate it.

For more information, see Retrieving Your Lost or Forgotten Passwords or Access Keys.

I get "access denied" when I make a request to an AWS service.

Verify that you have permission to call the action and resource that you have requested. If any conditions are set, you must also meet those conditions when you send the request. For information about viewing or modifying policies for an IAM user, group, or role, see Working with Policies.

If you're trying to access a service that has resource-based (or access control) policies, such as Amazon S3, Amazon SNS, or Amazon SQS, verify that the resource policy specifies you as a principal and grants you access. For more information about resource-based policies, see the documentation for that service.

If you are signing requests manually (without using the AWS SDKs), verify that you have correctly signed the request.

I get "access denied" when I make a request with temporary security credentials.

  • Verify that the service accepts temporary security credentials, see Using Temporary Security Credentials to Access AWS.

  • Verify that your requests are being signed correctly and that the request is well-formed. For details, see your toolkit documentation or Using Temporary Security Credentials to Authenticate an AWS Request.

  • Verify that your temporary security credentials haven't expired. For more information, see Using Temporary Security Credentials.

  • Verify that the IAM user or role has the correct permissions. Permissions for temporary security credentials are derived from an IAM user or role, so the permissions are limited to those granted to the IAM user or role. For more information about how permissions for temporary security credentials are determined, see Controlling Permissions for Temporary Security Credentials.

  • If you are accessing a resource that has a resource-based policy by using a role, verify that the policy grants permissions to the role. For example, the following policy allows MyRole from account 111122223333 to access MyBucket.

    Copy
    { "Version": "2012-10-17", "Statement": [{ "Sid": "S3BucketPolicy", "Effect": "Allow", "Principal": {"AWS": ["arn:aws:iam::111122223333:role/MyRole"]}, "Action": ["s3:PutObject"], "Resource": ["arn:aws:s3:::MyBucket/*"] }] }

Policy variables aren't working.

  • Verify that all policies that include variables include the following version number in the policy: "Version": "2012-10-17"Without the correct version number, the variables are not replaced during evaluation. Instead, the variables are evaluated literally. Any policies that don't include variables will still work if you include the latest version number.

    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. A policy version, on the other hand, is created when you make changes to 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 Version. To learn more about policy versions, see Versioning for Managed Policies.

  • Verify that your policy variables are in the right case. For details, see IAM Policy Variables Overview.

Changes that I make are not always immediately visible

As a service that is accessed through computers in data centers around the world, IAM uses a distributed computing model called eventual consistency. Any change that you make in IAM (or other AWS services) takes time to become visible from all possible endpoints. Some of the delay results from the time it takes to send the data from server to server, from replication zone to replication zone, and from region to region around the world. IAM also uses caching to improve performance, but in some cases this can add time; the change might not be visible until the previously cached data times out.

You must design your global applications to account for these potential delays and ensure that they work as expected, even when a change made in one location is not instantly visible at another. Such changes include creating or updating users, groups, roles, or policies. We recommend that you do not include such IAM changes in the critical, high-availability code paths of your application. Instead, make IAM changes in a separate initialization or setup routine that you run less frequently. Also, be sure to verify that the changes have been propagated before production workflows depend on them.

For more information about how some other AWS services are affected by this, consult the following resources: