|Did this page help you? Yes | No | Tell us about it...|
This section provides an introduction to IAM.
AWS Identity and Access Management is a web service that enables Amazon Web Services (AWS) customers to manage users and user permissions in AWS. The service is targeted at organizations with multiple users or systems that use AWS products such as Amazon EC2, Amazon SimpleDB, and the AWS Management Console. With IAM, you can centrally manage users, security credentials such as access keys, and permissions that control which AWS resources users can access.
Without IAM, organizations with multiple users and systems must either create multiple AWS accounts, each with its own billing and subscriptions to AWS products, or employees must all share the security credentials of a single AWS account. Also, without IAM, you have no control over the tasks a particular user or system can do and what AWS resources they might use.
IAM addresses this issue by enabling organizations to create multiple users (each user is a person, system, or application) who can use AWS products, each with individual security credentials, all controlled by and billed to a single AWS account. With IAM, each user is allowed to do only what they need to do as part of the user's job.
In the following video you'll learn the basics of using IAM to manage access to specific resources in your organization's AWS account. This video uses the AWS Management Console to show you how to create groups of users, set permissions for each group, generate a password, and use a sign-in URL to sign in to the console as an IAM user.
IAM includes the following features:
Central control of users and security credentials—You can control creation, rotation, and revocation of each user's AWS security credentials (such as access keys)
Central control of user access—You can control what data in the AWS system users can access and how they access it
Shared AWS resources—Users can share data for collaborative projects
Permissions based on organizational groups—You can restrict users' AWS access based on their job duties (for example, admin, developer, etc.) or departments. When users move inside the organization, you can easily update their AWS access to reflect the change in their role
Central control of AWS resources—Your organization maintains central control of the AWS data the users create, with no breaks in continuity or lost data as users move around within or leave the organization
Control over resource creation—You can help make sure that users create AWS data only in sanctioned places
Networking controls—You can help make sure that users can access AWS resources only from within the organization's corporate network, using SSL
Single AWS bill—Your organization's AWS account gets a single AWS bill for all your users' AWS activity
IAM is integrated with many AWS products. For information about which products are integrated with IAM, see AWS Services that Support IAM. As AWS products integrate with IAM, they will be added to the list on that page.
If you're an existing AWS account owner, you should know that the APIs for these products do not change because of their integration with IAM. Products that integrate with IAM have no new API actions related to access control.
If the users in your AWS account make API calls to any AWS products other than those that are integrated with IAM, they'll get an error. However, the AWS account itself (the umbrella entity above all the users) can call any AWS product the AWS account is signed up for.
Regarding IAM and Amazon DevPay:
Users in your AWS account can't create or sign up for products that use Amazon DevPay; only the AWS account can
If your AWS account purchases an Amazon EC2 paid Amazon Machine Image (AMI), the AWS account's users can launch and use instances of the AMI (assuming they have an IAM policy giving them permission to use the necessary Amazon EC2 actions)
If your AWS account purchases an Amazon S3 product that uses Amazon DevPay, the AWS account's users can't use the product; only the AWS account can
If your organization already uses AWS, migrating to IAM can be easy or potentially more challenging, depending on how your organization currently allocates its AWS resources. Here are the three scenarios.
Your organization has just a single AWS account. In this case, you can easily migrate to using IAM, because all the organization's AWS resources are already together under a single AWS account.
Your organization has multiple AWS accounts, with each AWS account belonging to a division in the organization. If these divisions don't need to share resources or users, then migrating is easy. Each division can keep its own AWS account and use IAM separately from the other divisions. You could also use Consolidated Billing, which would allow your organization to get a single bill across the AWS accounts (see IAM and Consolidated Billing).
Your organization has multiple AWS accounts that don't represent logical boundaries between divisions. If you need the AWS accounts to share their resources and have common users, migrating to IAM will be more of a challenge. You will need to move the resources that need to be shared so they're under the ownership of a single AWS account. However, there's no automatic way to transfer the AWS resources from one AWS account to another. You need to create those resources again under the single AWS account.
There's no change to how an AWS account functions in terms of its login/password, security credentials, payment method, AWS account activity page, usage report, and so on. At this time, the AWS account activity page does not show a breakdown by user.
AWS offers a billing feature called Consolidated Billing that is complementary to IAM. Consolidated Billing lets you receive a single bill for multiple AWS accounts. (For more information, go to the AWS Consolidated Billing Guide.) Compare this to IAM, which gives you a single bill across all the users in an AWS account.
Your organization could use both Consolidated Billing and IAM together. You might do this if your organization has multiple large divisions, and you want to isolate the users and AWS resources in each division from the other divisions. You could have a separate AWS account for each division, and use IAM in each division to create users and control their access to the division's AWS resources. You could then use Consolidated Billing to get a single bill across all the AWS accounts. The following diagram illustrates the concept.
With Consolidated Billing, one AWS account becomes the paying account, and pays for its own charges plus the charges of any linked AWS accounts. Each linked AWS account doesn't need to maintain a payment method with AWS, only the paying account does. Each month, AWS charges the paying account only. The paying account still functions like a normal AWS account; it could have its own users and AWS resources. Just as with the other AWS accounts, the users and resources in the paying account are isolated from the users and resources in the divisions' AWS accounts. The following diagram shows the paying account with its own users and AWS resources.