AWS Identity and Access Management FAQs

General

IAM User Management

IAM Role Management

Temporary Security Credentials

Identity Federation

Billing

Permissions

Login

Additional Questions



General

Q: What is AWS Identity and Access Management (IAM)?
AWS Identity and Access Management (IAM) enables you to securely control access to AWS services and resources for your users. IAM enables you to create and manage users in AWS's identity management system (referred to as "IAM users"), 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"). IAM offers greater security, flexibility, and control when using AWS.
Q: What problem 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 (i.e. Access Keys, password, Multi Factor Authentication devices) or request temporary security credentials to provide them access to AWS services and resources. You can manage permissions to control which operations a user can perform.
  • Manage access for federated users - You can request security credentials with configurable expirations for users that you manage in your corporate directory, allowing you to provide your employees and applications secure access to resources in your AWS account, without creating them an IAM user. 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 are the main features of IAM?
IAM supports the ability to:
  • Create IAM user identities - Add IAM users to your AWS account.
  • Organize IAM users in groups - Create groups to easily manage permissions for multiple IAM users under your AWS account.
  • Centralize control of user access - Control which operations your users can perform, such as accessing specific AWS service APIs and resources.
  • Conditional user access - Add conditions to control how your users can use AWS, such as time of day, their originating IP address, or whether they are using SSL.
  • Create and assign security credentials - Assign security credentials to your IAM users, and rotate and/or revoke these credentials as desired.
  • Create temporary security credentials - Request temporary security credentials with configurable expiration and permissions for your IAM users, federated users or applications.
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 managed in AWS's identity management system (referred to as "IAM users"), 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 like Amazon S3 and EC2. A user's ability to access web service APIs is under the control of and is 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 which 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, then 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 will 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. Then you can create and manage users, groups and permissions via IAM APIs, Command Line Tools, or via the IAM console which gives you a point-and-click, web-based interface. You can also use the AWS Policy Generator to create policies.

IAM User Management

Q: How are IAM users managed?
IAM supports multiple methods to create, delete and list IAM users, manage group membership, manage user security credentials, and assign permissions. You can create and manage users, groups and permissions via IAM APIs, Command Line Tools, or via 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: 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.
Q: What kinds of security credentials can IAM users have?
An IAM user can have any combination of credentials that AWS supports - AWS Access Key, X.509 certificate, password for web app logins, or Multi Factor Authentication (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.
Q: What AWS services support IAM users?
The complete list of AWS services that support IAM users can be found in the Integrating with Other AWS Products section of the IAM documentation. AWS plans to add support for other services over time.
Q: Can user access be enabled/disabled?
Yes. An IAM user's Access Keys can be enabled and disabled via the IAM APIs, Command Line Tools, or via the 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, permission 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, Command Line Tools, or via the 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, etc.
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, Command Line Tools, or via the 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, Command Line Tools, or via the 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: Are international user names supported?
No. Currently IAM user names are ASCII only.
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, Command Line Tools, or via the 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 drop down in the upper right hand corner.
Q: Can I define a password policy for my user’s passwords?
Yes you can define a password policy using the IAM console, Command Line Tools, or via the IAM APIs . You can define the following criteria:
  • Minimum password length
  • Complexity requirements (any combination of):
    • Minimum one lowercase letter.
    • Minimum one uppercase letter.
    • Minimum one number.
    • Minimum one symbol.
The password policy will be enforced the next time an IAM user changes their password. It applies to all users created under your AWS Account. See the Managing an IAM Password Policy section in the IAM documentation for details.
Q: Can I set usage quotas on IAM users?
No. It is currently not possible to set usage quotas on IAM users. All quotas are on the AWS Account. For example, an AWS Account today has a limit of 20 EC2 instances, and the account has a limit of 20 EC2 instances after using IAM to create users. The number of instances is associated with the AWS Account not the individual users defined under the account.

IAM Role Management

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 problem does IAM roles solve?
An IAM role allows 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?
To get started with IAM roles you:
  • Create a role in IAM.
  • Assign permissions to the role by attaching an IAM policy
  • Define which trusted entity can assume the role.
  • After you’ve defined the role, an application that makes AWS service calls can assume the role, which returns temporary credentials. The application can then use the temporary AWS credentials when accessing AWS services.
For more details on IAM roles, see Delegating API Access by Using Roles in the Using IAM guide.
Q: How do I assume an IAM role?
You assume an IAM role by calling the AWS Security Token Service (STS) AssumeRole API. The API returns a set of temporary security credentials. The application can then sign requests to AWS service APIs using the role’s credentials.
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 does IAM roles cost?
IAM roles is 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, Command Line Tools, or via 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 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.
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 are limited to a total aggregate policy size of 10,240 characters per role. That means you can have as many policies as you want for a given IAM role as long as the sum size of the policies doesn’t exceed 10,240 characters.
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: What services can an IAM role make service calls to?
Your application can make requests to all AWS services that support role sessions. For a complete list of these services, see Using Temporary Security Credentials to Access AWS.
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, Amazon SNS (and others) without you having to copy AWS access keys onto every instance your application is deployed to.
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 AWS Identity and Access Management (IAM) role with an instance. Then your EC2 instance will provide the roles’ AWS access keys to applications running on the instance, and the applications can use these keys to securely make requests to AWS services.
Q: How do I get started with IAM roles for EC2 instances?
To get started with IAM roles for EC2 instances you:
  • Create a role in IAM.
  • Launch your EC2 instances with the role as an input parameter.
  • Use the roles’ AWS access keys made available on the EC2 instance in your application when making requests to AWS services.
For more details on IAM roles please see Working with Roles in the Using IAM guide. For more details on using IAM roles with EC2 please see Using IAM roles with Amazon EC2 Instances in the Amazon EC2 User Guide.
Q: What features does IAM roles for EC2 instances provide?
IAM roles for EC2 instances provides the following features:
  • AWS access keys to use when making requests to AWS services are automatically made available on running EC2 instances.
  • Automatic rotation of the AWS access Keys made available on the EC2 instances.
  • Granular AWS service permissions for applications running on EC2 instances that make requests to AWS services.
Q: Can I use the same IAM role on multiple EC2 instances?
Yes, you can associate the same IAM role with multiple EC2 instances.
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, at this time you cannot associate an IAM role with an already running EC2 instance.
Q: Can I disassociate an IAM role from a running EC2 instance?
No, at this time you cannot disassociate an IAM role from a running 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 the Auto Scaling Developer Guide.
Q: Can I associate more than one IAM role to 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?
If you delete an IAM role that is associated with a running EC2 instance, all applications executing on that instance that are using the IAM roles AWS security credentials will almost immediately be denied access when making requests to AWS service APIs.
Q: Can I control which IAM roles an IAM user can associate with an EC2 instance?
Yes, you can control what IAM roles an IAM user can use when launching an instance.
Q: What 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.
See Working with Roles in the Using IAM guide for details.
Q: What happens if I change the permissions of an IAM role that is associated with a running EC2 instance?
If you change permissions on an IAM role that is associated with a running EC2 instance, the change will take effect almost immediately. The application running on the instance associated with the IAM role will almost immediately have the new permissions when making requests to other AWS services.
Q: Who can access the access keys on the EC2 instance?
Any local user on the instance can access the access keys associated for 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 then you don’t need to do anything. 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 then you can retrieve the access keys from the EC2 Instance Metadata Service. You can retrieve the access keys by doing a HTTP GET, replacing [role] in the example below with the name of the IAM role that the instance has been launched with:

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/[role]

This returns a JSON response containing among other things an access key ID, secret access key, security token and an expiry timestamp. See the Using Temporary Security Credentials guide for details on how to make calls with temporary security credentials.
Q: How do I rotate the access keys on the EC2 instance?
The AWS access keys associated with an IAM role are automatically rotated multiple times a day. New access keys are made available no later than 5 minutes before the existing access keys expire.
Q: Do I have to fetch new credentials from the EC2 metadata service when the old credentials expire?
If your application is developed with the AWS SDK, then this is taken care of automatically for you and is transparent to your application. Otherwise your application will have to retrieve new credentials from the EC2 Instance Metadata Service before the old ones have expired.
Q: Does IAM roles for EC2 instances work for all instance types?
Yes, IAM roles for EC2 instances is supported for all instance types.
Q: Does IAM roles for EC2 instances work for all AMIs?
Yes, AWS security credentials will be made available on all instances that have been launched with an IAM role, regardless of which AMI, Windows or Linux, was used when launching the instance.
Q: Does IAM roles for EC2 instances work with instances launched in VPC?
Yes, you can launch instances in VPC with an IAM role as an input parameter.
Q: Does IAM roles for EC2 instances work with spot and reserved instances?
Yes, you can launch a spot or reserved instance with an IAM role as an input parameter.

Temporary Security Credentials

Q: What are temporary security credentials?
Temporary security credentials consist of Access Key Id, Secret Access Key and token. They 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 which you manage in your own corporate directory.
Q: How can I request temporary security credentials for federated users?
You can request temporary security credentials for federated users by using an IAM user or the root AWS account to calling the AWS Security Token Service GetFederationToken API, passing:
  • Name - a text label representing the federated user.
  • Policy - an AWS Access Policy, specifying the permissions granted to the holder of the temporary security credential. For help creating access policies please see the AWS Policy Generator. Note that the permissions of the token cannot exceed the permissions of the IAM user who requests the token.
  • Duration - the time for which the temporary security credentials are valid. The default is 12 hours, the minimum is 1 hour, and the maximum is 36 hours. Temporary security credentials created by the root account are valid for 1 hour.
You will be returned:
  • Access Key id - the Access Key identifier for the temporary security credential.
  • Secret Access Key - the key used to sign requests associated with the temporary security credential.
  • Token - the security token.
Q: How can I request temporary security credentials for IAM users?
IAM users can request temporary security credentials for their own use by calling the AWS Security Token Service GetSessionToken API and passing:
  • Duration - the time for which the temporary security credentials are valid. The default is 12 hours, the minimum is 1 hour, and the maximum is 36 hours. Temporary security credentials created by the root account are valid for 1 hour.
You will be returned:
  • Access Key id - the Access Key identifier for the temporary security credential.
  • Secret Access Key - the key used to sign requests associated with the temporary security credential.
  • Token the security token.
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. There are no changes to AWS service APIs - simply:
  • 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: What are the benefits of temporary security credentials?
Temporary security credentials enable:
  • Federated users to access AWS service APIs - temporary security credentials enable you to extend your internal user directories to AWS, enabling your employees and applications to more securely access AWS service APIs, without needing to create an AWS identity for them.
  • Unlimited scale - you can request temporary security credentials for an unlimited number of federated users.
  • Improved security - you can 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. You can also integrate AWS Multi-Factor Authentication (MFA) into your applications to better secure sensitive AWS APIs and resources. Users requesting access must first have authenticated with their assigned MFA device.
Q: Which AWS services accept temporary security credentials?
For a list of supported services, see the temporary security credentials documentation. Other AWS services will add support over time.
Q: What datacenter regions support temporary security credentials?
Customers can request tokens from the AWS Security Token Service, which currently is supported in the US-East datacenter region. We plan to deploy the AWS Security Token Service to other AWS datacenter regions in upcoming months. Tokens can be used to access AWS services that support token-based authentication in all AWS datacenter regions.
Q: What is the maximum size of the access policy that can be specified during the GetFederationToken call?
450 bytes compressed. The compression may vary for individual policies. Note that the permissions of the token cannot exceed the permissions of the IAM user who requested it, so you can further control the permissions of the token by controlling the permissions of the IAM user requesting the token.
Q: Can a temporary security credential be revoked prior to its expiration?
No. It is for this reason that we recommend you set the duration when creating temporary security credential to a value that is appropriate for your application. In situations where there is an immediate need to invalidate a temporary session credential, 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. Since root account permissions cannot be restricted we recommend that you use an IAM user and not the root account for creating temporary security credentials.
Q: Can the expiration of an active temporary security credential be extended?
No. You cannot extend the expiration of a temporary security credential.
Q: Can an expired temporary security credential be reactivated?
No. You cannot reactivate an expired temporary security credential.
Q: Can a new temporary security credential be requested prior to the existing one expires?
Yes. It is a good practice to request a new temporary security credential before the old one expires.
Q: What are the best practices for using temporary security credentials?
We recommend the following best practices:
  • Once requested, temporary security credentials can be used for the length of their duration to call AWS service APIs - you do not need to request a new token for each API call.
  • You should choose the duration for how long the temporary security credential is valid that best fits your use case.
  • Request a new temporary security credential before the old one expires so that calls to AWS services are not interrupted due to an expired token.
  • Follow the security principle of least privilege - grant the temporary security credential only the level of permissions required for the task that needs to be performed.
  • While we support the creation of temporary security credentials by a root AWS account for consistency, we strongly recommend using an IAM user instead.

Identity Federation

Q: What is identity federation?
Identity federation is when one system trusts the users from another system. IAM enables you to request temporary security credentials for your corporate identities, enabling identity federation from your enterprise corporate directory to the AWS Management Console and AWS service APIs, without having to create IAM users for all of your corporate identities.
Q: What are federated users?
Federated users are users that are managed outside of AWS in your corporate directory. They differ from IAM users, which are created and maintained in AWS's identity directory.
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.
Q: Can federated users access the AWS Management Console?
Yes. You can programmatically request temporary security credentials for your federated users and include them as part of the sign-in request to the AWS Management Console. This will allow the user to access the console without having to sign in with a username and password. For more details 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 can I configure identity federation from my corporate directory?
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 and AWS service APIs. For a detailed description see the Using Temporary Security Credentials guide.
Q: How does identity federation to the AWS Management console work?
Identity federation to the console uses temporary security credentials as described in the Giving Federated Users Direct Access to the AWS Management Console section in the Using Temporary Security Credentials guide. After you have authenticated a user and granted them temporary security credentials, you can generate a sign-in token that can be used for the AWS single sign-on endpoint. This provides them access to the AWS Management Console. The user’s actions in the console are limited to the access control policy you have embedded in the temporary credential.
Q: How do I get started with identity federation to the AWS Management Console?

To get started with identity federation to the console, you’ll need two components: a session-granting proxy and a sign-in web page of your own.

The session-granting proxy connects your existing identity management system with AWS. It calls your identity management system to validate that a user should have access to AWS and also specifies the permissions you want enforced for the user when he/she interacts with AWS. The session-granting proxy calls the AWS Security Token Service (STS) to request temporary security credentials for the user.

Your web page (i.e. a corporate intranet portal) redirects the user to the AWS Management Console federation endpoint using a sign-in token generated from the temporary security credentials. The token grants the user access to the AWS Management Console without requiring the user to provide username and password.

For more detailed description on how to get started, see the Using Temporary Security Credentials guide.

Q: Do you support SAML or OAuth?
Not at this time, however we will evaluate adding support for federation standards in a subsequent release.
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, you provide the access control policy that will control their AWS permissions. That policy applies 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?
You can specify a session limit between 1-36 hours, 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 a new token.
Q: What happens when the identity federation session times out?
The user will be presented with a message stating that the 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.
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.

Billing

Q: Will AWS Billing provide aggregated usage and cost breakdowns by user?
Not initially. This is planned for a future release.
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 is responsible for paying for all usage incurred by users defined under it. An individual user has no payment or billing configuration of its own and can't individually subscribe to AWS services.
Q: Will billable user activity be logged in AWS usage data?
Not currently. This is planned for a future release.
Q: Who controls and is responsible for data or resources created by users?
The AWS Account controls and is responsible for all data and resources such as S3 objects and EC2 instances created by users defined under it. The AWS Account both pays for usage, and controls the access policies on resources. Resources created by an individual user will look as though they were created by the AWS Account. Resource listing will be performed per the AWS Account - that is, when users call S3.ListAllMyBuckets, they will see all buckets under control of the AWS Account under which the users are defined.
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. You can create separate and distinct IAM users for business and technical purposes. You can grant your business users access to the Account Activity and/or Usage Reports pages of the AWS website to allow them to access billing and usage data without giving them access to the operational aspects of AWS. Check out Controlling User Access to your AWS Accounts billing information for more details.

Permissions

Q: How will user permissions work?
By default, upon creation, IAM users are not able to perform any actions. The account administrator has to explicitly grant user permissions for the user to gain access to any resource within AWS. IAM provides the ability to centrally manage permissions that control which AWS service APIs a user can access. Permissions are expressed using the AWS Access Policy Language, a flexible access control language. These permissions are enforced in requests made to AWS services. In addition, for services that support resource-based access control, centrally managed permissions may also control which resources a user can access using coarse rules - for example, a policy may state, logically, allow Joe to read Amazon S3 objects from the corporate bucket as long as the objects are under some path.
Q: How will group-based permissions work?
IAM provides the ability to manage permissions for a collection of users (a group), in addition to an individual user. Any security policy that can grant permissions to a single user can also grant permissions to a group. Group permissions are applied by checking membership - if a group has been granted permission to perform an action and a user is in that group, then the user may perform that action. It is easier to manage permissions for a group, than to apply identical permissions to each user.
Q: How do user and role permissions work in conjunction with Amazon S3 Access Control (ACLs)?
The AWS access policies managed via IAM are evaluated in conjunction with Amazon S3 ACLs. AWS access policies and Amazon S3 ACLs both answer the same question - can the user/role access the requested resource? These policies are evaluated together against the user/role - if either policy grants access (without explicitly denying it), the action is allowed. In addition, users and roles may be referenced in Amazon S3 ACLs, providing data-level restrictions over users. Root control over ACLs will remain with the AWS Account, as it is today.
Q: How do user and role permissions work in conjunction with SQS access controls?
The AWS Access policies managed via IAM will be evaluated in conjunction with Amazon SQS AWS access policies. These policies are evaluated together against the user/role - if either policy grants access (without explicitly denying it), the action is allowed. In addition, users/roles defined via AWS Identity and Access Management may be referenced in Amazon SQS access policies, providing data-level restrictions over users. Root control over Amazon SQS AWS access policies will remain with the parent AWS Account, as it is today.
Q: How do user and role permissions work in conjunction with Amazon SNS access controls?
The AWS access policies managed via IAM are evaluated in conjunction with Amazon SNS AWS access policies. These policies are evaluated together against the user/role - if either policy grants access (without explicitly denying it), the action is allowed. In addition, users/roles defined via AWS Identity and Access Management may be referenced in Amazon SNS AWS access policies and grants, providing data-level restrictions over users. Root control over Amazon SNS AWS access policies will remain with the parent AWS Account, as it is today.
Q: Will administrative permissions in AWS Portal be supported?
Not currently. This is planned for a future release.
Q: Who is able to view user Access Keys/Secret Keys?
Users can access their own Access Key only if permitted. The AWS Account holder is able to see the public Access Keys of users - this is to support provisioning of keys for users who cannot login interactively, such as software systems. A user can also be granted permission to manage their own or other users' Access Keys via an IAM policy.
Q: Will users be able to create or access data under AWS Accounts other than the account under which they are defined?
Yes, if cross account API access using IAM roles has been enabled. For details, see Delegating API Access by Using Roles.
Q: Can access control policies include variables?
Yes. You can create policies that include variables that will be interpolated at the time of evaluation using context from the authenticated user’s session. Any of the AWS keys you use to define conditions in a policy statement (e.g., originating IP address, or whether the principal has authenticated with a Multi-Factor Authentication device) can be used as a variable. Variables allow defining general purpose policies without explicitly listing all the components of the policy. For example, you could lock down users’ access to a specific S3 folder or allow those users to manage their own access keys or signing certificates using variable keys such as ${aws:username}. For more details, please see the Policy Variables section of the IAM User guide.

Login

Q: How does a user sign in?
A user must sign in using a sign in URL provided by the AWS Account's system administrator. Users belonging to an AWS Account sign in using a URL that is specific for that account. The URL can either contain the Account ID or an alias. The alias is a name the system administrator defines to make it more convenient to identify the account. The URL looks something like this:

https://account-identifier.signin.aws.amazon.com/console/ec2

where you replace the account-identifier with either the 12 digit account number for the account, or the alias you have created for the account. The alias is optional. If you don't want to create an alias then you can use your Account ID. You can always create the alias at a later stage if you want to.

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. The alias is optional and is not required to support a user to sign in.
Q: Does the user always have to use the sign in URL?
The first time a user signs in they must use the account-specific URL. After this, the account-specific URL will be stored as a preference in the user's browser cookie. 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, then they must use the account-specific URL.
Q: How do I know what the URL is that my users need to use to sign in?
The sign in URL is built of two pieces of information, an identifier for the account, and a fixed part. The overall structure of the URL looks like this:

https://account-identifier.signin.aws.amazon.com/console/ec2

where you replace the account-identifier with either the 12 digit AWS Account number for the account, or the account alias. The URL is also available on the IAM console dashboard.

Q: What AWS sites can my users access?
Users can sign in to the AWS Management Console and AWS Forums.
Q: Do users work with AWS Forums?
Yes, users are enabled for the AWS Forums.
Q: Can users login to the AWS Management Console?
Yes, they can sign in and manage the services the AWS Account holder has signed up for, and for which they have been granted permission.
Q: Can users login to the AWS Portal?
Yes. Users can sign in to the AWS Portal, however you can't grant users permissions to view or update account details. This is planned for a future release.
Q: Can users login to Amazon retail websites?
No. Users created with IAM are only recognized by AWS services and applications.
Q: Can users login to third-party websites?
No. This capability is planned for a future release.
Q: Is there an Authenticate 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 reflected in customer instances in EC2. Identities on customer EC2 instances are the customer's responsibility.

Additional Questions

Q: Will my existing applications still work when I start using IAM?
Yes. All applications that run today should continue to work as normal. To take advantage of the new access provided with IAM you need to update the application to use Access Keys for a user created with IAM instead of the Access Keys for the AWS Account.
Q: What happens if a user tries to access a service that has not yet been integrated with IAM?
When a user tries to access a service which has not yet integrated with IAM, the service will return Access Denied.
Q: Will AWS Identity and Access Management administrative actions be logged to an audit trail?
No. This is planned for a future release.
Q: Will user actions in AWS services be logged to an audit trail?
No. This is planned for a future release.
Q: How are users identified?
Every IAM user has a user name that is unique under the AWS Account where it is defined. Every user also has a unique ID assigned to it upon creation. This is a globally unique ID assigned to it by the IAM system, and is unique across the whole AWS space. A user can always be identified by this ID alone, for example, in an access policy.
Q: Can a user name be reused?
Yes, a user name can be reused. The name is only unique with the AWS Account where the user has been created. Each user is identified by a unique ID. This allows the user name to be changed without having to create a new user. When you delete a user you can create a new user with the same user name and the new user will have a new set of credentials that are different from the previous user with the same name.
Q: Is there any distinction between people and software agents as AWS user identities?
No, both of these look like users, with security credentials and with granted permissions. The things that might differ are what kinds of credentials each has, such as interactive password.
Q: How will service resource limits work (e.g., 100 bucket or 20 instance limit)?
AWS service resource limits will continue to be defined per AWS Account as they are today. The number of users defined for an account doesn't affect this, and all usage by users will consume resources against the account's resource limits.
Q: Will Describe or List APIs in AWS services reflect the user that created a resource on behalf of an account?
Not initially. This is planned for a future release.
Q: Do IAM users work with AWS Support and Trusted Advisor?
Yes, IAM users have the ability to create and modify support cases as well as use Trusted Advisor. However, the account under which the IAM user exists must have Business or Enterprise level support. IAM user access to cases under Developer or Basic support tiers are planned for a future release.
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 detailed information regarding these quotas, please see the Limitations on IAM Entities section of the IAM user guide for more information. Please note these quotas are subject to change. If you require an increase you can always use the IAM Limit Increase Contact Us Form.
©2013, Amazon Web Services, Inc. or its affiliates. All rights reserved.