So far we’ve been discussing IAM principals. These represent the authentication component of accessing AWS. We authorize principals by attaching JSON documents to them called IAM policies. Policies define elements you can remember by the mnemonic PARC.


As mentioned, principals are the entities that are allowed or denied access. Commonly these are IAM users and IAM roles.


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 are the AWS resources the action will act upon. All AWS resources are identified by an Amazon Resource Name (ARN). Because AWS is deployed all over the world, ARNs function like an addressing system to precisely locate which specific part of AWS we are referring to. ARNs have these hierarchical structures:

  • Here arn means this string is an ARN,
  • partition is one of the three AWS paritions: AWS regions, AWS China regions, or AWS GovCloud (US) regions,
  • service is the specific AWS service like EC2,
  • region is the AWS region like us-east-1 (North Virginia),
  • account-id is the AWS account ID, and
  • resource-id is the unique resource ID. Other forms for resource IDs like resource-type/resource-id, are used by services like IAM where IAM users have resource-type of user and resource-id a username like Falcor.

Conditions are specific rules for which the access is valid.

Other Elements

All IAM policies have an Effect field which either either Allow or Deny.

The Version field defines which IAM service API version to use when evaluating the policy. At the time of this writing the latest version of IAM is 2012-10-17.

Finally, the Statement field consists of one or many JSON objects that contain the specific Action, Effect, Resource, and Condition fields described above.


    "Version": "2012-10-17",
    "Statement": [
            "Effect": "Allow",
            "Action": [
            "Resource": "*",
            "Condition" :  {
                 "IpAddress" : {
                    "aws:SourceIp" : ""

Let’s break this down.

  • First notice there is no Principal element in the policy. This is because attaching a policy to a principal implicitly specifies the principal the policy applies to. Since policies can exist apart from principals, this allows us to reuse common policies amongst many users, roles, services, etc.

  • The Effect is Allow, so this is a policy that explicitly grants access. This is the most common type of policy. You can write policies that explicitly Deny access as well.

  • The Action is an array of multiple actions that permit using EC2 to run instances and describe instance metadata. Actions can be a single action, or multiple actions in an array like depicted here.

  • There is no specific ARN in the Resource field, but instead *, which is a wildcard character that means this policy applies to all resources.

  • Finally, we have a Condition set that applies this policy only if the caller’s IP address matches exactly Conditions are optional, and do not need to be specified if the policy is to be applied unconditionally.

    The /32 is part of CIDR notation, which allows us to specify ranges of IP addresses in a compact way. You don’t need to understand CIDR notation for this workshop, but in this case, the /32 means this IP address is not a range, but that every number in the IP address is to be matched exactly.

So if, for example, an IAM user named Falcor had this IAM policy attached and was attempting to run an EC2 instance and retrieve metadata about it, calling the EC2 API from their laptop that has an IP address of, they would be allowed to do so.

It can go a lot further than this. IAM policies can be combined each with varying degrees of sensitivity and specificity, the net effect of which allows for fine-grained access control to every resource in an AWS account.

How Policies are Evaluated

For IAM principals, like an IAM user or IAM role, all requests to AWS are implicitly denied. This means that if no policies are attached to a principal, IAM’s default behavior is to deny access.

Next, if the principal does have an attached policy, and there is an explicit allow, the implicit deny is overriden. However, an explicit deny in any policy overrides any allows.

Diagrammatically, IAM evaluates policies like so:

Root User Access

Important: Actions taken by the AWS account root user are always implicitly allowed. The root user is special in this regard and is the only AWS principal that has this type of access.