IAM Policies and Permissions

In AWS, IAM policies and permissions control who can perform which actions on which resources. Applying the Principle of Least Privilege—granting only the access needed to perform a task—helps secure your environment.

Principle of Least Privilege

Grant users and roles only the permissions they require. In this example, Sarah creates three groups:

Admins (Bob and Susan): full management rights across AWS services.
Developers: access limited to a specific Sales folder.
Test (Kathy and Alan): no access to the Sales folder.

The image illustrates a diagram for implementing the Principle of Least Privilege, showing different user groups (Admins, Developers, Test) and their access permissions to AWS Services and a Sales Folder.

Note

Applying least privilege minimizes the blast radius if credentials are compromised.

Defining Permissions

A permission is a fine-grained control that authorizes an action on an AWS resource. Common permission examples:

ec2:StartInstances – start an EC2 instance
s3:GetObject – download an object from an S3 bucket
sqs:CreateQueue – create a new SQS queue
sns:DeleteTopic – delete an SNS topic

A policy is a collection of one or more permissions.

What Is an IAM Policy?

An IAM policy is a JSON document that defines:

Who (user, group, role) can perform
What actions on
Which resources

IAM policies give you granular control over access.

The image explains IAM policies, highlighting their role in managing access and permissions in AWS, defining permissions for identities or resources, specifying accessible resources and operations, and providing fine-grained access control.

Policy Types

IAM policies fall into two primary categories:

Policy Type	Attachment Point	Use Case
Identity-based policy	Users, groups, roles	Grant permissions to IAM identities
Resource-based policy	AWS resources (e.g., S3, Lambda)	Attach policies directly to resources themselves

The image categorizes IAM policies into "Identity Policies" and "Resource-Based Policies," with examples like Role, Group, User, S3, and Lambda.

You can attach an identity-based policy to a group of developers or assign a role to an EC2 instance so your applications inherit those permissions.

Identity-based Policy Example

Below is a sample JSON identity policy with two statements:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*"
      ],
      "Resource": [
        "arn:aws:s3:::<bucket-name>"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances"
      ],
      "Resource": [
        "arn:aws:ec2:<region>:<account-id>:instance/<instance-id>"
      ]
    }
  ]
}

The first statement allows all S3 actions on a specific bucket.
The second statement allows starting a particular EC2 instance.

Warning

Use wildcard (*) actions sparingly. Overly broad permissions increase security risks.

Demo: Creating an Identity Policy

Follow these steps in the AWS Management Console to create and attach an identity-based policy to a group:

Sign in to the IAM console.
Navigate to Policies > Create policy.
Use the JSON editor to paste your policy document.
Review and Create policy.
Attach the new policy to your IAM group.

The image is a slide titled "Create Identity Policy" with an illustration of a person pointing to a "Demo" sign. It includes instructions for creating identity-based policies for IAM groups on AWS.

Links and References

Watch Video

Watch video content