Skip to main content
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.
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 TypeAttachment PointUse Case
Identity-based policyUsers, groups, rolesGrant permissions to IAM identities
Resource-based policyAWS 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.
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:
  1. Sign in to the IAM console.
  2. Navigate to Policies > Create policy.
  3. Use the JSON editor to paste your policy document.
  4. Review and Create policy.
  5. 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.

Watch Video