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 when you work 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 lost your secret access key, then you must create a new access key pair. If you already have the maximum number of access keys, you must delete an existing pair before you can create another.

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

I Need to Access an Old Account

When you first created your AWS account, you provided an email address and password. These are your AWS account root user credentials. If you have an old AWS account that you can no longer access because you have lost or forgotten the password, you can recover the password. For more information, see Resetting Your Lost or Forgotten Passwords or Access Keys.

If you no longer have access to the email, you should first try to recover access to the email. If that doesn't work, you can contact AWS Customer Service.

You can try to recover access to your email using one of the following options:

  • If you own the domain where the email address is hosted, you can add the email address back to your email server. Alternatively, you can set up a catch-all for your email account. The catch-all setting on your domain "catches all" messages that are sent to email addresses that do not exist in the mail server. It redirects those messages to a specific email address. For example, assume that your AWS account root user email address is, but you changed your only domain email address to In that case, you could set your new email as the catch-all. That way, when someone like AWS sends a message to or any other, you receive that message at

  • If the email address on the account is part of your corporate email system, we recommend that you contact your IT system administrators. They might be able to help you regain access to the email address.

If you’re still not able to access your AWS account, you can find alternate support options at Contact us by expanding the I'm an AWS customer and I'm looking for billing or account support menu. When you contact AWS Support, you must provide the following information:

  • All the details that are listed on the account, including your full name, phone number, address, email address, and last four digits of the credit card. You might need to create a new AWS account for the purpose of contacting AWS Support. This is necessary to assist in the investigation of your request.

  • The reason that you're unable to access the email account to receive password reset instructions.

  • After you recover your account, close any accounts that you are not using. It’s a good idea not to have open accounts in your name that could result in charges to you. For more information, see Closing an Account in the Billing and Cost Management User Guide.

I Can't Sign in to My Account

When you first created your AWS account, you provided an email address and password. These are your AWS account root user credentials. If you can no longer access your account because you have lost or forgotten your password, you can recover that password. For more information, see Resetting Your Lost or Forgotten Passwords or Access Keys.

If you provided your account email address and password, AWS sometimes requires you to provide a one-time verification code. To retrieve the verification code, check the email that is associated with your AWS account for a message from Amazon Web Services. The email address ends in or Follow the directions in the message. If you don't see the message in your account, check your spam folder. If you no longer have access to the email, see I Need to Access an Old Account.

I Get "Access Denied" When I Make a Request to an AWS Service

  • Verify that you have the identity-based policy 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 Managing IAM Policies.

  • Are you trying to access a service that supports resource-based policies, such as Amazon S3, Amazon SNS, or Amazon SQS? If so, verify that the policy specifies you as a principal and grants you access. If you make a request to a service within your account, either your identity-based policies or the resource-based policies can grant you permission. If you make a request to a service in a different account, then both your identity-based policies and the resource-based policies must grant you permission. To view the services that support resource-based policies, see AWS Services That Work with IAM.

  • If your policy includes a condition with a key–value pair, review it carefully. Examples include the aws:RequestTag/tag-key global condition key, the AWS KMS kms:EncryptionContext:encryption_context_key, and the ResourceTag/tag-key condition key supported by multiple services. Make sure that the key name does not match multiple results. Because condition key names are not case sensitive, a condition that checks for a key named foo matches foo, Foo, or FOO. If your request includes multiple key–value pairs with key names that differ only by case, then your access might be unexpectedly denied. For more information, see IAM JSON Policy Elements: Condition.

  • If you have a permissions boundary, verify that the policy that is used for the permissions boundary allows your request. If your identity-based policies allow the request, but your permissions boundary does not, then the request is denied. A permissions boundary controls the maximum permissions that a principal entity (user or role) can have. Resource-based policies are not limited by permissions boundaries. Permissions boundaries are not common. For more information about how AWS evaluates policies, see Policy Evaluation Logic.

  • 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

  • First, make sure that you are not denied access for a reason that is unrelated to your temporary credentials. For more information, see I Get "Access Denied" When I Make a Request to an AWS Service.

  • Verify that the service accepts temporary security credentials, see AWS Services That Work with IAM.

  • 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 Request Access to AWS Resources.

  • Verify that your temporary security credentials haven't expired. For more information, see 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. As a result, the permissions are limited to those that are granted to the role whose temporary credentials you have assumed. For more information about how permissions for temporary security credentials are determined, see Controlling Permissions for Temporary Security Credentials.

  • If you assumed a role, your role session might be limited by session policies. When you request temporary security credentials programmatically using AWS STS, you can optionally pass inline or managed session policies. Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary credential session for a role. You can pass a single JSON inline session policy document using the Policy parameter. You can use the PolicyArns parameter to specify up to 10 managed session policies. The resulting session's permissions are the intersection of the role's identity-based policies and the session policies. Alternatively, if your administrator or a custom program provides you with temporary credentials, they might have included a session policy to limit your access.

  • If you are a federated user, your session might be limited by session policies. You become a federated user by signing in to AWS as an IAM user and then requesting a federation token. For more information about federated users, see GetFederationToken—Federation Through a Custom Identity Broker. If you or your identity broker passed session policies while requesting a federation token, then your session is limited by those policies. The resulting session's permissions are the intersection of your IAM user identity-based policies and the session policies. For more information about session policies, see Session Policies.

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

    { "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 IAM JSON Policy Elements: Version. To learn more about policy versions, see Versioning IAM Policies.

  • Verify that your policy variables are in the right case. For details, see IAM Policy Elements: Variables and Tags.

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

I Am Not Authorized to Perform: iam:DeleteVirtualMFADevice

You might receive the following error when you attempt to assign or remove a virtual MFA device for yourself or others:

User: arn:aws:iam::123456789012:user/Diego is not authorized to perform: iam:DeleteVirtualMFADevice on resource: arn:aws:iam::123456789012:mfa/Diego with an explicit deny

This could happen if someone previously began assigning a virtual MFA device to a user in the IAM console and then cancelled the process. This creates an MFA device for the user in IAM but never activates it. You must delete the existing MFA device before you can associate a new device with the user.

AWS recommends a policy that allows a user to delete their own virtual MFA device only if they are authenticated using MFA. For more information, see AWS: Allows MFA-Authenticated IAM Users to Manage Their Own Credentials on the My Security Credentials Page.

To fix this issue, an administrator should not edit policy permissions. Instead, the administrator must use the AWS CLI or AWS API to remove the existing but deactivated device.

To delete an existing but deactivated MFA device

  1. View the virtual MFA devices in your account.

  2. In the response, locate the ARN of the virtual device for the user you are trying to fix.

  3. Delete the device.