Provides management of permissions for principals (an entity that can take an action on an AWS resource) in your environments
Principals include IAM users, IAM user groups, IAM roles, and third-party identity providers
Integrates with other AWS services
Uses federated identity management
Provides secure access for applications
Enables permissions to be controlled granularly
Reside within your account, not separate accounts
Have their own credentials (though not by default)
Have permissions granted to them or explicitly blocked from them
Can be replaced with users from identity providers, but they will need to be managed outside of AWS
A group of permissions attached to either a resource or a principal is called an IAM policy.
There are two kinds of IAM policies:
Attached to AWS resources, such as Amazon DynamoDB tables or Amazon S3 Glacier archives
Control actions allowed by a specific principal and what conditions are required
Always inline (there are no managed resource-based policies)
Cannot attach policies to IAM identities even though they are technically AWS resources
Attached to users, groups, or roles
Control actions performed by what it’s attached to, including which resources and what conditions are required
Includes AWS-managed, customer-managed, and inline options for policies
Applications can have their own identities with their own sets of permissions
By placing IAM users into groups, you can manage their permissions as a group, rather than just individually.
Users and groups can each have their own policies attached.
You could group users by role, team, security level, or whatever factor makes the most sense.
When a user needs additional permissions (such as for a special project), you could either attach a new policy to their IAM user or move them into another IAM group, but the most efficient way to do this is with IAM roles.
Like policies, they let you define a set of permissions.
Unlike policies, they are not attached to an IAM user or group. They are their own object.
Roles are assumed by the user or service that needs those permissions.
They are designed to easily attach or detach temporary permissions as needed without having to edit user or group policies repeatedly.
You can assume a role through the AWS Management Console, the AWS CLI, the AssumeRole API call, or AWS Security Token Service (AWS STS).
Providing AWS resources with access to other AWS services
Providing access to externally authenticated users
Providing access to third parties
Switching roles to access resources in:
Your AWS account
Any other AWS account (with cross-account access)