FAQs for AWS IAM

Q: What is AWS Identity and Access Management (IAM)?
You can use IAM to securely control individual and group access to your AWS resources. You can create and manage user identities ("IAM users") and grant permissions for those IAM users to access your resources. You can also grant permissions for users outside of AWS ("federated users").

Q: How do I get started with IAM?
After you’ve signed up for AWS, you can create users and groups and assign them permissions to access your AWS resources. You can use the IAM console (for web-based access), the IAM command line interface (for command line access), or the API or SDKs (for programmatic access). To grant permissions, you create policy documents that you attach to users, groups, or other entities. See the video, Getting Started with IAM.

Q: What problems does IAM solve?
IAM makes it easy to provide multiple users secure access to your AWS account and resources. IAM enables you to:

• Manage IAM users and their access: You can create users in AWS's identity management system, assign users individual security credentials (such as access keys, passwords, multi-factor authentication devices) or request temporary security credentials to provide users access to AWS services and resources. You can specify permissions to control which operations a user can perform.
• Manage access for federated users: You can request security credentials with configurable expirations for users who you manage in your corporate directory, allowing you to provide your employees and applications secure access to resources in your AWS account without creating an IAM user account for them. You specify the permissions for these security credentials to control which operations a user can perform.

Q: Who can use IAM?
Any AWS customer can use IAM. The service is offered at no additional charge. You will be charged only for use of other AWS services by your users.

Q: What is a user?
A user is a unique identity recognized by AWS services and applications. Similar to a login user in an operating system like Windows or UNIX, a user has a unique name and can identify itself using familiar security credentials such as a password or access key. A user can be an individual, system, or application requiring access to AWS services. IAM supports users (referred to as "IAM users") managed in AWS's identity management system, and it also enables you to grant access to AWS resources for users managed outside of AWS in your corporate directory (referred to as "federated users").

Q: What is a user able to do?
A user is able to place requests to web services such as Amazon S3 and EC2. A user's ability to access web service APIs is under the control of and the responsibility of the AWS account under which it is defined. A user can be permitted to access any or all of the AWS services that have been integrated with IAM and to which the AWS account has subscribed. If permitted, a user has access to all of the resources under the AWS account. In addition, if the AWS account has access to resources from a different AWS account, its users may be able to access data under those AWS accounts. Any AWS resources created by a user are under control of and paid for by its AWS account. A user cannot independently subscribe to AWS services or control resources.

Q: How do users call AWS services?
Users can make requests to AWS services using security credentials. A user's ability to call AWS services is governed by explicit permissions. By default, they have no ability to call service APIs on behalf of the account.

Q: How do I get started with IAM?
To start using IAM, you must subscribe to at least one of the AWS services that has integrated with IAM. You then can create and manage users, groups, and permissions via IAM APIs, the AWS Command Line Interface, or the IAM console, which gives you a point-and-click, web-based interface. You can also use the AWS Policy Generator to create policies.

Q: How are IAM users managed?
IAM supports multiple methods to:

• Create, delete, and list IAM users.
  
• Manage group membership.
  
• Manage user security credentials.
  
• Assign permissions.
  

You can create and manage users, groups, and permissions via IAM APIs, the AWS CLI, or the IAM console, which gives you a point-and-click, web-based interface. You can also use the AWS Policy Generator and AWS Policy Simulator to create and test policies.

Q: What is a group?
A group is a collection of IAM users. Group membership is managed as a simple list:

• Users can be added to or removed from a group.
  
• A user can belong to multiple groups.
  
• Groups cannot belong to other groups.
  
• Groups can be granted permissions using access control policies. This makes it easier to manage permissions for a collection of users, rather than having to manage permissions for each individual user.
  
• Groups do not have security credentials, and cannot access web services directly; they exist solely to make it easier to manage user permissions. For details, see Working with Groups and Users.
  

Q: What kinds of security credentials can IAM users have?
IAM users can have any combination of credentials that AWS supports, such as an AWS access key, X.509 certificate, password for web app logins, or an MFA device. This allows users to interact with AWS in any manner that makes sense for them. An employee might have both an AWS access key and a password; a software system might have only an AWS access key to make programmatic calls; and an outside contractor might have only an X.509 certificate to use the EC2 command-line interface. For details, see Credentials in the IAM documentation.

Q: Which AWS services support IAM users?
The complete list of AWS services that support IAM users can be found in the AWS Services That Support IAM section of the IAM documentation. AWS plans to add support for other services over time.

Q: Can user access be enabled and disabled?
Yes. An IAM user's access keys can be enabled and disabled via the IAM APIs, AWS CLI, or IAM console. Disabling the access keys means the user will not be able to programmatically access the AWS services.

Q: Who is able to manage users for an AWS account?
The AWS account holder can manage users, groups, security credentials, and permissions. In addition, permissions may be granted to individual users to place calls to IAM APIs in order to manage other users. For example, an administrator user may be created to manage users for a corporation—a recommended practice. When a user has been granted permission to manage other users they can do this via the IAM APIs, AWS CLI, or IAM console.

Q: Can a collection of users be structured in a hierarchical way, such as in LDAP?
Yes. Users and groups can be organized under paths, similar to object paths in Amazon S3—for example /mycompany/division/project/joe.

Q: Can users be defined regionally?
Not initially. Users are global entities, like an AWS account is today. No region is required to be specified when defining user permissions. Users are able to use AWS services in any geographic region.

Q: How are MFA devices configured for IAM users?
The AWS account holder can order multiple MFA devices. These devices can then be assigned to individual IAM users via the IAM APIs, AWS CLI, or IAM console.

Q: What kind of key rotation is supported for IAM users?
User access keys and X.509 certificates can be rotated just as they are for an AWS account's root access identifiers. A user's access keys and X.509 certificates can be managed and rotated programmatically via the IAM APIs, AWS CLI, or IAM console.

Q: Can IAM users have individual EC2 SSH keys?
Not in the initial release. IAM does not affect EC2 SSH keys or Windows RDP certificates. This means that although each user has separate credentials for accessing web service APIs, they must share SSH keys that are common across the AWS account under which the user has been defined.

Q: Do IAM user names have to be email addresses?
No, but they can be. User names are just ASCII strings that are unique within a given AWS account. The AWS account holder can assign names using any naming convention they choose, including email addresses.

Q: What character sets can I use for IAM user names?
IAM entities support only ASCII characters.

Q: Are user attributes other than user name supported?
Not at this time.

Q: How are user passwords set?
An initial password can be set for an IAM user via the IAM console, AWS CLI, or IAM APIs. User passwords never appear in clear text after the initial provisioning, and are never displayed or returned via an API call. IAM users can manage their passwords via the My Password page in the IAM console. Users access this page by selecting the Security Credentials option in the AWS Management Console dropdown list in the upper right-hand corner.

Q: Can I define a password policy for my user’s passwords?
Yes, you can enforce strong passwords, like requiring minimum length or at least one number. You can also enforce automatic password expiration, prevent re-use of old passwords, and require a password reset upon next AWS sign in. For details, see Setting an Account Policy Password for IAM Users.

Q: Can I set usage quotas on IAM users?
No. All limits are on the AWS account as a whole. For example, if your AWS Account has a limit of 20 Amazon EC2 instances, IAM users with EC2 permissions can start instances up to the limit. You cannot limit what an individual user can do.

Q: What is an IAM role?
A role is an AWS Identity and Access Management (IAM) entity that defines a set of permissions for making AWS service requests. IAM roles are not associated with a specific user or group. Instead, roles are assumed by trusted entities, such as IAM users, applications or AWS services like EC2.

Q: What problems do IAM roles solve?
IAM roles allow you to delegate access with defined permissions to trusted entities without having to share long-term access keys. You can use IAM roles to delegate access to IAM users managed within your account, to IAM users under a different AWS account, or to an AWS service like EC2.

Q: How do I get started with IAM roles?
You create a role in a way similar to how you create a user—name the role and attach a policy to it. For details, see Creating IAM Roles.

Q: How do I assume an IAM role?
You assume an IAM role by calling the AWS Security Token Service (STS) AssumeRole APIs (in other words, AssumeRole, AssumeRoleWithWebIdentity, and AssumeRoleWithSAML). These APIs return a set of temporary security credentials that applications can then use to sign requests to AWS service APIs.

Q: How many IAM roles can I assume?
There is no limit to the number of IAM roles you can assume, but you can only act as one IAM role when making requests to AWS services.

Q: Who can use IAM roles?
Any AWS customer can use this feature.

Q: How much do IAM roles cost?
IAM roles are free of charge. You will continue to pay for any resources a role in your AWS account consumes.

Q: How are IAM roles managed?
You can create and manage IAM roles via the IAM APIs, AWS CLI, or IAM console, which gives you a point-and-click, web-based interface.

Q: What is the difference between an IAM role and an IAM user?
An IAM user has permanent long-term credentials and is used to directly interact with AWS services. An IAM role does not have any credentials and cannot make direct requests to AWS services. IAM roles are meant to be assumed by authorized entities, such as IAM users, applications, or an AWS service like EC2.

Q: What is the difference between an IAM role and an IAM group?
An IAM group is a collection of IAM users that share the same permissions. An IAM group is primarily a management convenience to manage the same set of permissions for a set of IAM users. An IAM role is an IAM entity with permissions to make AWS service requests. IAM roles cannot make direct requests to AWS services; they are meant to be assumed by authorized entities, such as IAM users, applications, or AWS services like EC2.

Q: When should I use an IAM user, IAM group or IAM role?
An IAM user has permanent long-term credentials and is used to directly interact with AWS services. An IAM group is primarily a management convenience to manage the same set of permissions for a set of IAM users. An IAM role is an AWS Identity and Access Management (IAM) entity with permissions to make AWS service requests. IAM roles cannot make direct requests to AWS services, they are meant to be “assumed” by authorized entities, such as IAM users, applications or AWS services like EC2. IAM roles are used to delegate access within or between AWS accounts.

Q: Can an IAM role be added to an IAM group?
Not at this time.

Q: How many policies can be attached to an IAM role?
You can add as many policies as needed to an IAM role, as long as the total size of all the policies doesn't exceed 10 KB.

Q: How many IAM roles can I create?
You are limited to 250 IAM roles under your AWS account. If you need more roles, submit the IAM limit increase request form with your use case and your IAM role increase will be considered.

Q: Which services can an IAM role make service calls to?
Your application can make requests to all AWS services that support role sessions.

Q: What is IAM roles for EC2 instances?
IAM roles for EC2 instances enables your applications running on EC2 to make requests to AWS services such as Amazon S3, Amazon SQS, and Amazon SNS without you having to copy AWS access keys to every instance. For details, see Using IAM Roles to Delegate Permissions to Applications that Run on Amazon EC2.

Q: What are the features of IAM roles for EC2 instances?

IAM roles for EC2 instances provides the following features:

• AWS temporary security credentials to use when making requests from running EC2 instances to AWS services.
• Automatic rotation of the AWS temporary security credentials.
• Granular AWS service permissions for applications running on EC2 instances.
  

Q: What problem does IAM roles for EC2 instances solve?
IAM roles for EC2 instances simplifies management and deployment of AWS access keys to EC2 instances. Using this feature, you associate an IAM role with an instance. Then your EC2 instance will provide the temporary security credentials to applications running on the instance, and the applications can use these credentials to securely make requests to the AWS service resources defined in the role.

Q: How do I get started with IAM roles for EC2 instances?
To get started with IAM roles for EC2 instances you:

1. Create a role in IAM.
2. Launch your EC2 instances with the role as an input parameter.
3. Use the roles’ AWS access keys made available on the EC2 instance in your application when making requests to AWS services.

For more details about IAM roles, see Using Roles to Delegate Permissions and Federate Identities in the Using IAM guide. For more details about using IAM roles with EC2, see IAM Roles for Amazon EC2 in the Amazon EC2 User Guide.

Q: Can I use the same IAM role on multiple EC2 instances?
Yes.

Q: Can I change the IAM role on a running EC2 instance?
No, at this time you cannot change the IAM role on a running EC2 instance. You can change the permissions on the IAM role associated with a running instance, and the updated permissions will take effect almost immediately.

Q: Can I associate an IAM role with an already running EC2 instance?
No. You can associate only one IAM role with an EC2 instance.

Q: Can I use an IAM role with other services that launch EC2 instances?
Yes. Auto Scaling and AWS CloudFormation also support IAM roles. Other services will add support over time.

Q: Can I associate an IAM role with an Auto Scaling group?
Yes. You can add an IAM role as an additional parameter in an Auto Scaling launch configuration and create an Auto Scaling group with that launch configuration. All EC2 instances launched in an Auto Scaling group that is associated with an IAM role will be launched with the role as an input parameter. For more details, see What Is Auto Scaling? in the Auto Scaling Developer Guide.

Q: Can I associate more than one IAM role with an EC2 instance?
No. You can only associate one IAM role with an EC2 instance at this time.

Q: What happens if I delete an IAM role that is associated with a running EC2 instance?
Any application running on that instance that's using the role will be denied access immediately.

Q: Can I control which IAM roles an IAM user can associate with an EC2 instance?
Yes. For details, see Using IAM Roles to Delegate Permissions to Applications that Run on Amazon EC2.

Q: Which permissions are required to launch EC2 instances with an IAM role?
An IAM user must be granted two distinct permissions to successfully launch EC2 instances with roles:

• Permission to launch EC2 instances.
• Permission to associate an IAM role with EC2 instances.

Q: Who can access the access keys on the EC2 instance?
Any local user on the instance can access the access keys associated with the IAM role.

Q: How do I use the IAM role with my application on the EC2 instance?
If you develop your application with the AWS SDK, the AWS SDK will automatically use the AWS access keys that have been made available on the EC2 instance. If you are not using the AWS SDK, you can retrieve the access keys from the EC2 Instance Metadata Service. For details see Using IAM Roles to Delegate Permissions to Applications that Run on Amazon EC2.

Q: How do I rotate the temporary security credentials on the EC2 instance?
The AWS temporary security credentials associated with an IAM role are automatically rotated multiple times a day. New temporary security credentials are made available no later than five minutes before the existing temporary security credentials expire.

Q: Can I use IAM roles for EC2 instances with any instance type or AMI?
Yes. IAM roles for EC2 instances also work in Amazon Virtual Private Cloud (VPC), with spot and reserved instances.

Q: What are temporary security credentials?
Temporary security credentials consist of the AWS acccess key ID, secret access key, and security token. Temporary security credentials are valid for a specified duration and for a specific set of permissions. Temporary security credentials are sometimes simply referred to as tokens. Tokens can be requested for IAM users or for federated users you manage in your own corporate directory. For more information, see Scenarios for Granting Temporary Access.

Q: What are the benefits of temporary security credentials?
Temporary security credentials allow you to:

• Extend your internal user directories to enable federation to AWS, enabling your employees and applications to securely access AWS service APIs without needing to create an AWS identity for them.
• Request temporary security credentials for an unlimited number of federated users.
• Configure the time period after which temporary security credentials expire, offering improved security when accessing AWS service APIs through mobile devices where there is a risk of losing the device.

Q: How can I request temporary security credentials for federated users?
You can call the GetFederationToken or an AssumeRole STS APIs.

Q: How can IAM users request temporary security credentials for their own use?
IAM users can request temporary security credentials for their own use by calling the AWS STS GetSessionToken API. The default expiration for these temporary credentials is 12 hours; the minimum is 1 hour, and the maximum is 36 hours.

Temporary credentials can be also used with Multi-Factor Authentication (MFA) Protected API Access.

Q: How can temporary security credentials be used to call AWS service APIs?
Temporary security credentials are designed to require minimal code changes to applications that call AWS service APIs. No changes are required to AWS service APIs:

• Use the AccessKeyID and SecretAccessKey to sign AWS service API requests as before.
• Pass the token as an additional parameter for every request made to AWS service APIs. For Amazon S3: via the "x-amz- security-token" HTTP header. For other AWS services: via the SecurityToken parameter.

Q: Which AWS services accept temporary security credentials?
For a list of supported services, see AWS Services that Support AWS Security Token Service (STS).

Q: What is the maximum size of the access policy that can be specified when requesting temporary security credentials (either GetFederationToken or AssumeRole)?
450 bytes compressed.

Q: Can a temporary security credential be revoked prior to its expiration?
No. When requesting temporary credentials we recommend the following:

• When creating temporary security credentials, set the expiration to a value that is appropriate for your application.
• Because root account permissions cannot be restricted, use an IAM user and not the root account for creating temporary security credentials. You can revoke permissions of the IAM user that issued the original call to request it. This action will almost immediately revoke privileges for all temporary security credentials issued by that IAM user
  

Q: Can temporary security credentials be reactivated or have their expiration extended?
No. It is a good practice to actively check the expiration and request a new temporary security credential before the old one expires. This rotation process is automatically managed for you when temporary security credentials are used in roles for EC2 instances.

Q: Are temporary security credentials supported in all regions?
Customers can request tokens from AWS STS endpoints in all regions, including AWS GovCloud (US) and China (Beijing) regions. Temporary credentials from AWS GovCloud (US) and China (Beijing) can be used only in the region from which they originated. Temporary credentials requested from any other region such as US East or EU (Ireland) can be used in all regions except AWS GovCloud (US) and China (Beijing).

Q: Can I restrict the use of temporary security credentials to a region or a subset of regions?

No. You cannot restrict the temporary security credentials to a particular region or subset of regions, except the temporary security credentials from AWS GovCloud (US) and China (Beijing), which can be used only in the respective regions from which they originated.

Q: What do I need to do before I can start using an AWS STS endpoint?

AWS STS endpoints in US East, AWS GovCloud (US), and China (Beijing) regions are always active and you can start using them without any further actions. For other AWS STS endpoints in regions such as US West (Oregon) or EU (Ireland), an account administrator must first activate the AWS STS region for the AWS account from the Account Settings page found in the IAM console.

Q: What happens if I try to use a regional AWS STS endpoint that has not been activated for my AWS account?

If you attempt to use a regional AWS STS endpoint that has not yet been activated for your AWS account, you will see an AccessDenied exception from AWS STS with the following message: “AWS STS is not activated in this region for account: accountId. Your account administrator can activate AWS STS in this region using the IAM console.”

Q: What permissions are required to activate or deactivate AWS STS regions from the Account Settings page?

Only users with at least iam:* permissions can activate or deactivate AWS STS regions from the Account Settings page in the IAM console. Note that the AWS STS endpoints in US East, AWS GovCloud (US), and China (Beijing) regions are always active and cannot be deactivated.

Q: Can I use the API or CLI to activate or deactivate AWS STS regions?

No. There is no API or CLI support at this time to activate or deactivate AWS STS regions. We plan to provide API and CLI support in a future release.

Q: What is identity federation?
Web identity federation allows you to create AWS-powered mobile apps that use public identity providers (such as Amazon Cognito, Login with Amazon, Facebook, Google or any OpenID Connect compatible provider) for authentication. With web identity federation, you have an easy way to integrate sign-in from public identity providers into your apps without having to write any server-side code and without distributing long-term AWS security credentials with the app.

For more information about web identity federation and to get started, please see Creating Temporary Security Credentials for Mobile Apps Using Public Identity Providers in the AWS STS guide.

Q: What are federated users?
Federated users are users that are managed outside of AWS in your corporate directory, but are granted access to your AWS account using temporary security credentials. They differ from IAM users, which are created and maintained in your AWS account.

Q: Do you support SAML?
Yes, AWS supports the Security Assertion Markup Language (SAML) 2.0.

Q: What SAML profiles does AWS support?
The AWS single sign-on (SSO) endpoint supports the identity provider initiated HTTP-POST binding WebSSO SAML Profile. This enables a federated user to log into to the AWS Management Console using a SAML assertion. A SAML assertion can also be used to request temporary security credentials using the AssumeRoleWithSAML API. For more information see Creating Temporary Security Credentials for SAML Federation.

Q: Can federated users access AWS APIs?
Yes. You can programmatically request temporary security credentials for your federated users to provide them secure and direct access to AWS APIs. We have provided a sample application that demonstrates how you can enable identity federation, providing users maintained by Microsoft Active Directory access to AWS service APIs. For more information see Using Temporary Security Credentials.

Q: Can federated users access the AWS Management Console?
Yes. Giving federated access to the console uses temporary security credentials as described in the Giving Federated Users Direct Access to the AWS Management Console and Giving Federated Users Direct Access to the AWS Management Console section in the Using Temporary Security Credentials guide. There are a couple ways to achieve this.

One way is by programmatically requesting temporary security credentials (e.g., GetFederationToken or AssumeRole) for your federated users and including those credentials as part of the sign-in request to the AWS Management Console. After you have authenticated a user and granted them temporary security credentials, you generate a sign-in token that is used by the AWS single sign-on (SSO) endpoint. The user’s actions in the console are limited to the access control policy associated with the temporary security credentials.

Alternatively, you can post a SAML assertion directly to AWS sign-in (https://signin.aws.amazon.com/saml). The user’s actions in the console will be limited to the access control policy associated with the IAM role that is assumed using the SAML assertion. For more details see Giving Console Access Using SAML.

Using either approach will allow a federated user to access the console without having to sign in with a username and password. We have provided a sample application that demonstrates how you can enable identity federation, providing users maintained by Microsoft Active Directory access to the AWS Management Console. For more details also see the Giving Federated Users Direct Access to the AWS Management Console section in the Using Temporary Security Credentials guide.

Q: Which AWS services accept federated users?
Most AWS services now support access for federated users. For a complete list please see the Using Temporary Security Credentials guide. Additional AWS services will add support for federated users over time.

Q: How do I control what a federated user is allowed to do when signed into the console?
When you request temporary security credentials for your federated user using an AssumeRole API, you can optionally include an access policy with the request. The federated user’s privileges will be the intersection of permissions granted by the access policy passed with the request and the access policy attached to the IAM role that was assumed. The access policy passed with the request cannot elevate the privileges associated with the IAM role being assumed. When you request temporary security credentials for your federated user using the GetFederationToken API, you must provide an access control policy with the request. The federated user’s privileges will be the intersection of the permissions granted by the access policy passed with the request and the access policy attached to the IAM user that was used to make the request. The access policy passed with the request cannot elevate the privileges associated with the IAM user used to make the request.These federated user permissions apply to both API access and actions taken within the AWS Management Console.

Q: What permissions does a federated user need to use the console?
A user will require permissions to the AWS service APIs called by the AWS Management Console. Common permissions required to access AWS services are documented in the Using Temporary Security Credentials guide.

Q: How do I control how long a federated user has access to the console?
Depending on the API used to create the temporary security credentials, you can specify a session limit between 15 min to 36 hours (for GetFederationToken and GetSessionToken) and 15-60 min (for AssumeRole APIs), during which time the federated user can access the console. When the session expires, the user will need to request a new session by returning to your web page where you may grant them access.

Q: What happens when the identity federation console session times out?
The user will be presented with a message stating that the console session has timed out and that they need to request a new session. You can specify a URL to direct users to your local intranet web page where they can request a new session. You add this URL when you specify an Issuer parameter as part of your sign in request. For more information see Giving Federated Users Direct Access to the AWS Management Console.

Q: How many federated users can I give access to the AWS Management Console?
There is no limit on the number of federated users who may have access to the console.

Q: What is web identity federation?
Web identity federation allows you to create cloud-backed mobile apps that use public identity providers such as Amazon Cognito, Login with Amazon, Facebook, or Google for authentication. With web identity federation, you have an easy way to integrate Amazon.com, Facebook, or Google sign-in into your apps without having to write any server-side code and without distributing long-term AWS security credentials with the app.

For more information about web identity federation and to get started, please see Creating Temporary Security Credentials for Mobile Apps Using Public Identity Providers in the AWS STS guide.

Q: Which identity providers does web identity federation support?
Web identity federation supports Amazon Cognito, Login with Amazon, Facebook, Google, and any OpenID Connect compatible provider.

Q: Do you support OpenID Connect?
Yes, AWS supports OpenID Connect.

Q: How do I enable identity federation with accounts from public identity providers?
Here are the basic steps to enable identify federation using one of the supported web identity providers:

1. You sign up as a developer with the identity provider.
2. In AWS, you create one or more IAM roles. For OpenID Connect compatible providers, you also have to create an identity provider in IAM.
3. In your application, you authenticate your users using the public identity provider.
4. In your app, you make an unsigned call to the AssumeRoleWithWebidentity API to request temporary security credentials.
5. Using the temporary security credentials you get in the AssumeRoleWithWebidentity response, your app makes signed requests to AWS APIs.
6. Your app caches the temporary security credentials so that you do not have to get new ones each time the app needs to make a request to AWS.

For more detailed steps, please see the Process for Using Web Identity Federation for Mobile Apps section of the AWS STS guide.

Q: How does identity federation using the AWS Directory Service differ from using a 3rd party identity management solution?

If you only want your federated users to be able to access the AWS Management Console, using the AWS Directory Service provides similar capabilities compared to using a 3rd party identity management solution. End-users are able to log in using their existing corporate credentials and access the AWS Management Console. As AWS Directory Service is a managed service, customers do not need to set up or manage federation infrastructure and simply need to create an AD Connector directory to integrate with their on-premises directory. If you are interested in providing your federated users access AWS APIs, for example using the AWS Command Line Interface (CLI), you will need to use a 3rd party offering or deploy your own proxy server.

Q: Does AWS Billing provide aggregated usage and cost breakdowns by user?
No, this is not currently supported.

Q: Does the IAM service cost anything?
No, this is a feature of your AWS Account provided at no additional charge.

Q: Who pays for usage incurred by users under an AWS Account?
The AWS account owner controls and is responsible for all usage, data, and resources under the account.

Q: Is billable user activity logged in AWS usage data?
Not currently. This is planned for a future release.

Q: How does IAM compare with Consolidated Billing?
IAM and Consolidated Billing are complementary features. Consolidated Billing enables you to consolidate payment for multiple Amazon Web Services (AWS) accounts within your company by designating a single paying account. The scope of IAM is not related to Consolidated Billing. A user exists within the confines of an AWS Account and does not have permissions across linked accounts. For more details on see the AWS Consolidated Billing Guide.

Q: Can a user access the AWS Accounts billing information?
Yes, but only if you let them. In order for IAM users to access billing information, you must first grant access to the Account Activity and/or Usage Reports. See “Controlling User Access to your AWS Accounts billing information.”

Q: How do permissions work?

Use policies to assign permissions to IAM users, groups, and roles. By default, IAM users, groups, and roles have no permissions; the account owner or an IAM user with sufficient permissions must use a policy to grant permissions to an IAM user, group, or role.

Q: How do I assign permissions using a policy?

You can assign permissions using the AWS Management Console, the IAM API, or the AWS CLI. The account owner and IAM users who have been granted the necessary permissions can create policies and assign them to IAM users, groups, and roles. There are two types of policies in IAM: inline policies and managed policies. You can use both types to assign permissions to IAM users, groups, and roles. For more information about managed and inline policies, see Managed Policies and Inline Policies.

Q: What are inline policies?

Inline policies are policies that you create along with an IAM user, group, or role. To edit an inline policy, you must edit all of the IAM users, groups, and roles in which it is embedded. For information about inline policies, including use cases, see Managed Policies and Inline Policies.

Q: What are managed policies?

Managed policies are standalone policies that you can create, edit, and manage separately from the IAM users, groups, and roles to which they are attached. After you attach a managed policy to multiple IAM users, groups, or roles, you can update that policy in one place and the permissions apply to all attached entities. Managed policies are managed either by you (these are called customer managed policies) or by AWS (these are called AWS managed policies). For more information about managed policies, see Managed Policies and Inline Policies.

Q: How do I easily define commonly used permissions?

AWS provides a set of commonly used permissions that you can attach to IAM users, groups, and roles in your account. These are called AWS managed policies. One example is read-only access for Amazon S3. When AWS updates these policies, the permissions are automatically applied to the users, groups, and roles to which the policy is attached. AWS managed policies automatically appear in the Policies section of the IAM console. When you assign permissions, you can use an AWS managed policy or you can create a new customer managed policy based on an existing AWS managed policy. This functionality is only available for managed policies and replaces the policy template feature. When you create an inline policy, you can use the policy generator or write a policy by hand.

Q: How do group-based permissions work?

You can use IAM groups to assign the same set of permissions to multiple IAM users.

Q: What is the difference between assigning permissions using IAM groups and assigning permissions using managed policies?

You can use IAM groups to collect IAM users and define common permissions for those users. You can use managed policies to share permissions across IAM users, groups, and roles. For example, if you want a group of users to be able to launch an Amazon EC2 instance and you also want the role on that instance to have the same permissions as the users in the group, you can create a managed policy and assign it to the group of users and to the role on that Amazon EC2 instance.

Q: How are IAM policies evaluated in conjunction with Amazon S3, Amazon SQS, Amazon SNS, and AWS KMS resource-based policies?

IAM policies are evaluated together with the service’s resource-based policies. When a policy of any type grants access (without explicitly denying it), the action is allowed. For more information about the policy evaluation logic, see IAM Policy Evaluation Logic. 

Q: Can I use managed policies as a resource-based policy?

Managed policies can be attached only to IAM users, groups, or roles, and cannot be used as resource-based policies.

Q: Can I grant IAM users permission to access or change account-level information (for example, payment instrument, contact email address, and billing history)?

Yes, you can delegate the ability for an IAM user or a federated user to view AWS billing data and modify AWS account information. For more information about controlling access to your billing information, see Controlling Access to Your Billing Information. 

Q: Who can create and manage access keys in an AWS account?

Only the AWS account owner can manage the access keys for the root account. The account owner and IAM users or roles that have been granted the necessary permissions can manage access keys for IAM users.

Q: Can users in one AWS account access resources owned by another AWS account?
Yes. Using IAM roles, IAM users and federated users can access resources in another AWS account via the AWS Management Console, the AWS CLI, or the APIs. See Manage IAM Roles for more information.

Q: What is the IAM policy simulator?
The IAM policy simulator is a tool that enables you to test the effects of IAM access control policies before committing them into production.

Q: What problem does the policy simulator solve?
The policy simulator makes it easier to verify and troubleshoot permissions. Previously, you had to write policies and put them into production before you could test their effects.

Q: Who can use the policy simulator?
The policy simulator is available to all AWS customers.

Q: How much does the policy simulator cost?
The policy simulator is available at no extra cost.

Q: How do I get started?
Go to https://policysim.aws.amazon.com or click the link on the IAM console under “More to Explore”. Choose or enter the policy that you’d like to evaluate, select actions from the list of AWS services, and click a button to simulate whether the policy will allow or deny permissions to the selected actions. To learn more about the IAM policy simulator, watch our Getting Started video or jump straight into the documentation.

Q: What kinds of policies are supported in the policy simulator?
The policy simulator supports testing of newly entered policies and existing policies attached to users, groups, or roles. You can also simulate whether resource-level policies grant access to a particular resource. The policy simulator does not support resource-based policies, i.e. policies that are attached directly to S3 buckets, SQS queues, and SNS topics.

Q: If I change a policy in the policy simulator, do those changes persist in production?
No. To apply changes to production, copy the policy that you’ve modified in the policy simulator and attach it to the desired IAM user, group, or role.

Q: Will the policy simulator be integrated into the console?
Yes, that is planned for a future release.

Q: How does a user sign in?
A user must sign in to the account's signin URL by using their IAM user name and password. This signin URL is located in the Dashboard of the IAM console and must be communicated by the AWS account's system administrator to the IAM user.

Q: What is an AWS Account Alias?
The account alias is a name you define to make it more convenient to identify your account. You can create an alias using the IAM APIs, Command Line Tools, or via the IAM console. You can have one alias per AWS Account.

Q: Does the user always have to use the direct link?
The first time users sign in, they must use the account-specific URL. After this, the account-specific URL will be stored as a preference as a cookie in user's browser. This allows a user to return to http://aws.amazon.com and click the Sign in to the AWS Management Console link to sign in. If the user clears their browser cookies or uses a different browser, he or she must use re-enter the account-specific URL.

Q: What AWS sites can my users access?
Users can sign in to the following AWS sites:

• AWS Management Console
• AWS Forums
• AWS Support
• AWS Marketplace
  

Q: Can users login to Amazon retail websites?
No. Users created with IAM are only recognized by AWS services and applications.

Q: Is there an authentication API to verify user logins?
No. There is no programmatic way to verify user logins.

Q: Can users SSH to EC2 instances using their AWS user name/password?
No. User security credentials created with IAM are not supported for direct authentication to customer EC2 instances. Managing EC2 SSH credentials is the customer’s responsibility within the EC2 console.

Q: What happens if a user tries to access a service that has not yet been integrated with IAM?
The service will return an “access denied” error.

Q: Are AWS Identity and Access Management actions logged for auditing purposes?
Yes. You can log IAM actions, STS actions, and AWS Management Console sign-ins by activating AWS CloudTrail. You can learn more about AWS logging by visiting the CloudTrail page.

Q: Is there any distinction between people and software agents as AWS entities?
No, both of these entities are treated like users with security credentials and permissions. However, people are the only ones to use a password in the AWS Management Console.

Q: Do users work with AWS Support Center and Trusted Advisor?
Yes, IAM users have the ability to create and modify support cases as well as use Trusted Advisor.

Q: Are there any default quota limits associated with IAM?
Yes, by default your AWS account has initial quotas set for all IAM-related entities. For details see “Limitations on IAM Entities.”

These quotas are subject to change. If you require an increase, you can use the Service Limit Increase form on the Contact Us page and select “AWS IAM groups and users”.

Q. What is AWS MFA?
AWS Multi-Factor Authentication (AWS MFA) provides an extra level of security that you can apply to your AWS environment. You can enable AWS MFA for your AWS account and for individual AWS Identity and Access Management (IAM) users you have created under your account.

Q. How does AWS MFA work?
AWS MFA uses an authentication device that continually generates random, six-digit, single-use authentication codes. There are two primary ways to authenticate using an AWS MFA device:

AWS Management Console users: With AWS MFA enabled, when a user signs in to an AWS website, they will be prompted for their username and password (the first factor – what they know), as well as for an authentication code from their AWS MFA device (the second factor – what they have). All AWS websites that require sign in, such as the AWS Management Console, are integrated with AWS MFA. You can also use AWS MFA together with Amazon S3 Secure Delete for additional protection of your Amazon S3 stored versions.

AWS API users: You can enforce MFA authentication by adding MFA-related restrictions in IAM policies. To access APIs and resources protected in this way, developers can use temporary security credentials and pass optional MFA parameters in their AWS Security Token Service (STS) API requests (the service that grants temporary security credentials. MFA-validated temporary security credentials can be used to call MFA-protected APIs and resources.

Q. How do I get AWS MFA?
You follow two easy steps:

Get an authentication device. You have two options:

- You can purchase a hardware device that is compatible with AWS MFA from Gemalto, a third party provider.
- You can install a virtual AWS MFA compatible application on a device such as your smartphone.

Visit the MFA page for details on how to acquire a hardware or virtual MFA device.

Once you have the authentication device you must activate it. You active an AWS MFA device for your AWS account or your IAM users in the IAM Console. You can also use the IAM CLI to activate it for an IAM user.

Q. Is there a fee associated with using AWS MFA?
AWS does not charge any additional fees for the use of AWS MFA with your AWS account. However, if you want to use a physical authentication device then you will need to purchase an authentication device that is compatible with AWS MFA from Gemalto, a third party provider. For more details, please visit Gemalto’s website.

Q. Can I have multiple authentication devices active for my AWS account?
Yes. With the introduction of AWS Identity and Access Management (IAM), each IAM user can have its own authentication device.

Q. Can I use my authentication device with multiple AWS accounts?
No. The authentication device is bound to an individual AWS account or IAM user. If you have a TOTP compatible application installed on your smartphone, you can create multiple virtual MFA devices on the same smartphone. Each one of the virtual MFA devices is bound to an individual AWS account or IAM user, just like a hardware device. If you dissociate (deactivate) the authentication device, you can then reuse it with a different AWS account or IAM user. The authentication device cannot be used with more than one AWS account or IAM user simultaneously.

Q. I already have a hardware authentication device from my place of work or from another service I use, can I re-use this device with AWS MFA?
No. AWS MFA relies on knowing a unique secret associated with your authentication device in order to support its use. Because of security constraints that mandate such secrets never be shared between multiple parties, AWS MFA cannot support the use of your existing hardware authentication device. Only a compatible hardware authentication device purchased from Gemalto can be used with AWS MFA.

Q. I’m having a problem with an order for an authentication device using the third party provider Gemalto’s website. Where can I get help?
Gemalto’s customer service will be happy to assist you.

Q. I received a defective or damaged authentication device from the third party provider Gemalto. Where can I get help?
Gemalto’s customer service will be happy to assist you.

Q. I just received an authentication device from the third party provider Gemalto. What should I do?
You simply need to activate the authentication device to enable AWS MFA for your AWS account. Click here to use the IAM Console to perform this task.

Q. What is a virtual MFA device?
A virtual MFA device is an entry created in a TOTP compatible software application that can generate six-digit authentication codes. The software application can run on any hardware device, such as a smartphone.

Q. What are the differences between a virtual MFA device and physical MFA devices?
Virtual MFA devices use the same protocols as the physical MFA devices. Virtual MFA devices are software based and can run on your existing devices such as smartphones. Most virtual MFA applications also allow you to enable more than one virtual MFA device which makes them more convenient than physical MFA devices.

Q. What virtual MFA applications are supported with AWS MFA?
Applications that generate TOTP compliant authentication codes, such as the AWS Virtual MFA application can be used with AWS MFA. We support provisioning virtual MFA devices either automatically scanning a QR code with the devices camera or via manual seed entry in the virtual MFA application.

Visit the MFA page for a list of supported virtual MFA applications.

Q. What is a QR code?
QR code is an abbreviation of Quick Response code and is a two-dimensional barcode that is readable by dedicated QR barcode readers and most camera telephones. The code consists of black modules arranged in square patterns on a white background. The QR code contains the required security configuration information to provision a virtual MFA device in your virtual MFA application.

Q. How do I provision a new virtual MFA device?
A new virtual MFA device can be configured in the IAM console for your IAM users as well as for your AWS account. You can also use the iam-virtualmfadevicecreate command in the IAM CLI or the CreateVirtualMFADevice API to provision new virtual MFA devices under your account. The iam-virtualmfadevicecreate and the CreateVirtualMFADevice API returns the required configuration information, called a seed, to bootstrap the virtual MFA device in your AWS MFA compatible application. You can either grant your IAM users the permissions to call this API directly or perform the initial provisioning for them.

Q. How should I handle and distribute the seed material for virtual MFA devices?
You should treat seed material like any other secret (for example the AWS secret keys and passwords).

Q. How can I enable an IAM user to manage virtual MFA devices under my account?
Grant the IAM user the permission to call the CreateVirtualMFADevice API. This API can be used to provision new virtual MFA devices.

Q. Where do I enable AWS MFA?
You can enable AWS MFA for an AWS account and your IAM users in the IAM console, the IAM CLI, or via direct API calls.

Q. What information will I need to activate my authentication device?
If you are activating the MFA device with the IAM console then you only need the device. If you are using the IAM CLI or the IAM API then you will need the following:

1. The serial number of the authentication device. The serial number is different for a hardware device or a virtual device:

- Hardware MFA device: The serial number on the bar-coded label on the back of the device.
- Virtual MFA device: The serial number is the value returned when running the iam-virtualmfadevicecreate command in the IAM CLI. or when calling the CreateVirtualMFADevice API.

2. Two consecutive authentication codes displayed by the authentication device.

Q. My authentication device seems to be working normally, but I am not able to activate it. What should I do?
Please contact us for help.

Q. If I enable AWS MFA for my AWS account or my IAM users, do they always need to use an authentication code to sign in to all AWS properties?
Yes. AWS supports Single Sign-On (SSO) which means that when you sign in to any AWS site you sign in to all AWS sites. This means that if your AWS account or any of your IAM users has an MFA device assigned to them, then they are required to always use this device when they sign in.

Q. If I enable AWS MFA for my AWS account or my IAM users, do they always need to use an authentication code to sign in to the AWS Portal or AWS Management Console?
Yes. The AWS account and your IAM users will need to have their MFA device with them any time they need to sign in any AWS site.

If the authentication device associated with the AWS account is damaged, lost, stolen, or stops working, you will need to contact us for help with disabling AWS MFA for the account. This will allow you to temporarily sign in to AWS using just the user name and password for the AWS account.

If your IAM users lose or damage their authentication device, it is stolen, or it stops working, you can disable AWS MFA yourself using the IAM console or the IAM CLI.

Q. If I enable AWS MFA for my AWS account or my IAM users, do they always need to enter an MFA code to directly call AWS APIs?
No, it’s optional. However, you will need to enter an MFA code if you plan to call APIs secured by MFA-protected API access.

If you are calling AWS APIs using your root account or IAM user access keys you do not need to enter an MFA code. For security reasons, AWS recommends that remove access keys from your root account and instead call AWS APIs with IAM users.

Q. How do I sign in to the AWS Portal and AWS Management Console using my authentication device?
Follow these two steps:

If you are signing in as an AWS account, sign in as usual with your user name and password when prompted. To sign in as an IAM user, use the account-specific URL and provide your user name and password when prompted.

On the next page, enter the six-digit authentication code that appears on your authentication device.

Q. Does AWS MFA affect how I access AWS Service APIs?
AWS MFA changes the way IAM users access AWS Service APIs only if the account administrator(s) choose to enable MFA-protected API access. Administrators may enable this feature to add an extra layer of security over access to sensitive APIs by requiring that callers authenticate with an AWS MFA device. For more information, see the MFA-protected API access documentation in more detail.

Other exceptions include S3 PUT Bucket versioning, GET Bucket versioning and DELETE Object APIs, which allows you to require that deleting or changing the versioning state of your bucket use an additional authentication code. For more information see the S3 documentation discussing Configuring a Bucket with MFA Delete in more detail.

For all other cases, AWS MFA does not currently change the way you access AWS service APIs.

Q. Can I use a given authentication code more than once?
No. For security reasons, each authentication code can be used only once.

Q. I was recently asked to re-sync my authentication device because my authentication codes were being rejected. Should I be concerned?
No, this can happen occasionally. AWS MFA relies on the clock in your authentication device being in sync with the clock on our servers. Sometimes, due to environmental factors such as temperature, humidity, and pressure, these clocks can drift apart. If this happens, when you use the authentication device to sign in to access secure pages on the AWS website or the AWS Management Console, we will automatically attempt to re-sync the authentication device by requesting that you provide two consecutive authentication codes (just as you did during activation).

Q. My authentication device seems to be working normally, but I am not able to use it to sign in to the AWS Portal or AWS Management Console. What should I do?
We suggest you try re-syncing the authentication device using this link if your MFA device protects your root credentials (requires signin), or this link for your IAM user's credentials. If you have already tried to re-sync and are still having trouble signing in, please contact us for help.

Q. My authentication device is lost, is damaged, or has been stolen and now I can’t sign in to the AWS Portal or AWS Management Console. What should I do?
If the authentication device is associated with an AWS account, follow these steps:

Contact us for help with disabling AWS MFA so you can temporarily access secure pages on the AWS website and the AWS Management Console using just your user name and password.

Change your Amazon password in case an attacker has stolen your authentication device and may also have your current password.

Purchase a new authentication device from the third party provider Gemalto using their website or provision a new virtual MFA device under your account using the IAM console.

Once you have completed the steps above, use the IAM console to activate the authentication device to re-enable AWS MFA for your AWS account.

If the authentication device is associated with an IAM user, you can use the IAM console, IAM CLI or IAM API to remove the MFA device for the IAM user.

Q. My physical authentication device has stopped working and now I can’t sign in to the AWS Portal or AWS Management Console. What should I do?
If the physical authentication device is associated with an AWS account, follow these steps:

Contact us for help with disabling AWS MFA so you can temporarily access secure pages on the AWS website and the AWS Management Console using just your user name and password.

Contact the third party provider Gemalto for further assistance with the authentication device.

Once you have another authentication device, come back to the AWS website and activate the authentication device to re-enable AWS MFA for your AWS account, just as before.

If the authentication device is associated with an IAM user, you should contact the person who gave you the user name and password for the IAM user.

Q. How do I disable AWS MFA?
To disable AWS MFA for your AWS account, you need to deactivate your authentication device using the Security Credentials page. To disable AWS MFA for your IAM users, you need to use the IAM console or the IAM CLI. Currently, IAM users cannot disable AWS MFA themselves.

Q. Can I use AWS MFA in GovCloud?
Yes, you can use AWS virtual MFA in GovCloud. AWS does not currently support hardware MFA devices in GovCloud.

Q. What is MFA-protected API access?
MFA-protected API access is optional functionality that lets account administrators enforce additional authentication for customer-specified APIs by requiring that users prove physical possession of an MFA device. Specifically, it enables administrators to include conditions in their IAM policies that require MFA authentication for selected APIs. Users making calls to those APIs must first have entered a valid MFA code shown on their device.

Q. What problem does MFA-protected API access solve?
Previously, customers could require MFA for access to the AWS Management Console, but could not enforce MFA requirements on developers and applications interacting directly with AWS service APIs. MFA-protected API access ensures that IAM policies are universally enforced regardless of access path. As a result, you can now develop your own application that uses AWS and prompts the user for MFA authentication before calling powerful APIs or accessing sensitive resources.

Q. How do I get started with MFA-protected API access?
You can get started in two simple steps:

1. Assign an MFA device to your IAM users. You can purchase a hardware key fob or download a free TOTP-compatible application for your smart phone, tablet, or computer. See the MFA detail page for more information on AWS MFA devices.
   
2. Enable MFA-protected API access by creating access policies for the IAM users and/or IAM groups that you want to require MFA authentication from. This can be accomplished in the IAM Console, the IAM Command Line Interface (CLI), or the IAM API. To learn more about access policy language syntax, see the access policy language documentation.

Q. How do developers and users access APIs and resources secured with MFA-protected API access?
Developers and users interact with MFA-protected API access both in the AWS Management Console and at the APIs.

In the AWS Management Console, any MFA-enabled IAM user must authenticate with their device in order to sign in. Users that do not have MFA will not receive access to MFA-protected APIs and resources.

At the API level, developers can integrate AWS MFA into their applications to prompt users to authenticate using their assigned MFA devices before calling powerful APIs or accessing sensitive resources. Developers enable this functionality by adding optional MFA parameters (serial number and MFA code) to requests to obtain temporary security credentials (such requests are also referred to as “session requests”). If the parameters are valid, temporary security credentials which track MFA status will be returned. See the temporary security credentials documentation for more information.

Q. Who can use MFA-protected API access?
MFA-protected API access is available for free to all AWS customers.

Q. Which services will MFA-protected API access work with?
MFA-protected API access is supported by all AWS services that support temporary security credentials. For a list of supported services, see the temporary security credentials documentation.

Q. What happens if a user passes in incorrect MFA device information when requesting temporary security credentials?
The request to issue temporary security credentials will fail. Temporary security credential requests that specify MFA parameters must provide the correct serial number of the device linked to the IAM user as well as a valid MFA code.

Q. Does MFA-protected API access control API access for root accounts?
No, MFA-protected API access only controls access for IAM users. Root accounts are not bound by IAM policies, which is why AWS recommends that you create IAM users to interact with AWS service APIs rather than use root account credentials.

Q. Do users have to have an MFA device assigned to them in order to use MFA-protected API access?
Yes, a user must first be assigned a unique virtual or hardware MFA device.

Q. Is MFA-protected API access compatible with S3 objects, SQS queues, and SNS topics?
Yes.

Q. How does MFA-protected API access interact with existing MFA use cases such as S3 MFA Delete?
MFA-protected API access and S3 MFA Delete do not interact with each other. S3 MFA Delete currently does not support temporary security credentials. Instead, calls to the S3 MFA Delete API must be made using long-term access keys.

Q. Does MFA-protected API access work in GovCloud?
Yes.

Q. Does MFA-protected API access work for federated users?
Customers will not be able to use MFA-protected API access to control access for federated users. The GetFederatedSession API does not accept MFA parameters. Since federated users can’t authenticate with AWS MFA devices, they will be unable to access resources designated using MFA-protected API access.