One of the most commonly used principals in AWS is the IAM user. An IAM user typically represents a human who has a username and password they use to authenticate. You can have many IAM users in an AWS account, perhaps each representing a member of your team.
When first creating an AWS account, one usually signs up with an email address and password. This creates a special user associated with that email address and password that has complete access to all AWS services and resources in the account. This identity is the AWS account root user.
We will talk more about the AWS account root user in the AWS Account Administration section.
An IAM role is identical in function to an IAM user, with the important distinction that it is not uniquely associated with one entity, but assumable by many entities. Typically, IAM roles correspond to a job function.
A loose analogy for IAM roles are that of professional uniforms: a surgeon’s scrubs, a firefighter’s hardhat, or a startup CTO’s favorite unwashed hoodie. Many people can assume the role of a surgeon, firefighter, and startup CTO, which identifies them with a certain job function.
It’d be pretty weird if you needed surgery and found out a firefighter would be performing it or awarded a surgeon 20% equity in your company (with a one year cliff and four year vesting schedule, of course) to develop software.
One of the most useful things about IAM roles is they can be associated not only with human entities, like an IAM user, but also with AWS services, like Amazon Elastic Compute Cloud (EC2), AWS’s scalable virtual machine compute service. These types of roles are known as service roles.
This means we can assign an IAM role directly to an EC2 instance. With an IAM role assigned to an EC2 instance, we can associate specific IAM policies with the instance role, so that the EC2 instance itself can access other AWS services. This is extremely useful for automation, for example.