Serverless Developer Guide
Tip
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 ﬁreﬁghter's 
hardhat, or a startup CTO's favorite hoodie. Many people can assume the role of a surgeon, 
ﬁreﬁghter, and startup CTO, which identiﬁes them with a certain job function.
One of the most useful things about IAM roles is they can be associated not only with human 
entities, but also with AWS services. These types of roles are known as service roles. This means you 
can assign an IAM role directly to a service. With an IAM role assigned to the service instance, you 
can then associate speciﬁc IAM policies with the instance role, so that the service instance itself can 
access other AWS services. This is extremely useful for automation.
Authorization - PARC
So far we've been talking about principals. Principals represent the authentication component. For 
authorization, you will attach JSON documents called IAM policies to principals.
Principals
As mentioned, principals are the entities that are allowed or denied access.
Actions
Actions are the type of access that is allowed or denied. Actions are commonly AWS service API 
calls that represent create, read, describe, list, update, and delete semantics.
Resources
Resources are the AWS resources the action will act upon.
All AWS resources are identiﬁed by an Amazon Resource Name (ARN) . Because AWS services are 
deployed all over the world, ARNs function like an addressing system to precisely locate a speciﬁc 
component. ARNs have hierarchical structures:
arn:partition:service:region:account-id:resource-id
Fundamentals 40