AWS Certified Cloud Practitioner / Identity and Access Management

IAM Introduction: Users, Groups, Policies

🔑 AWS Identity and Access Management (IAM)

IAM (Identity and Access Management) is an AWS global service that controls who can access AWS resources and what actions they can perform.

Being a global service means IAM is not tied to a specific AWS Region. You configure it once, and it applies across all regions worldwide.

🛡 Why IAM Matters

IAM is the security foundation of AWS. It ensures:

  • The right people or systems have access

  • Access is restricted to only what is necessary

  • AWS accounts are protected from misuse

👉 You have already interacted with IAM when creating your AWS root account.

⚠️ Best Practice: Never use the root account for day-to-day operations.

🧩 Core IAM Concepts

IAM is built around four main elements:

  1. Users

  2. Groups

  3. Roles

  4. Policies

👤 IAM Users

IAM users represent real people or applications in your organization.

IAM users can represent either:

  • 👤 A person – e.g., a developer logging into the AWS Console.

  • 🤖 An application – e.g., a Node.js app using AWS SDK with an Access Key and Secret Key to access services like S3.

Example:

Node.js App
     │
IAM User (Access Key + Secret Key)
     │
Amazon S3

Note: While applications can use IAM users, AWS recommends using IAM Roles instead because they provide temporary credentials and are more secure.

🧠 Key Points:

  • Each user has individual login credentials

  • Credentials should never be shared

  • One IAM user = one person or application

👥 IAM Groups

Groups are collections of IAM users with shared permissions.

🧠 Key Rules:

  • Groups can contain only users

  • Groups cannot contain other groups

  • Users do not have to belong to a group

  • Users can belong to multiple groups

❓ Why Groups Matter: Simplifies permission management, makes it scalable and easier to maintain.

👉 Example: IAM Groups in a Company

A company organizes users by role. Each user gets unique login credentials and permissions through their group — pick an action below to see who can actually do it.

🎭 IAM Roles

Roles are temporary identities that users, apps, or AWS services can assume to gain permissions — no long-term credentials involved.

🧠 Key Rules:

  • Roles have no permanent password or access keys

  • Any trusted identity (user, app, or AWS service) can assume a role

  • AWS STS (Security Token Service) issues temporary credentials that expire automatically

  • One role can be assumed by many different identities, one at a time each

📜 IAM Permissions & Policies

IAM permissions are defined using policies.

A policy is a JSON document that defines:

  • Actions – What can be done

  • Resources – What the actions apply to

  • Effect – Allow or Deny

  • Conditions – Optional rules for access

Policies can be attached to: IAM Users, IAM Groups, IAM Roles

👉 Example Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:ListMetrics",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:Describe*"
      ],
      "Resource": "*"
    }
  ]
}

  • Version – Policy language version.

  • Effect: Allow – Grants permission.

  • Action – Allowed operations (EC2 and CloudWatch read-only).

  • Resource: "*" – Applies to all resources.

Give users only the permissions they need—nothing more.

Example: If a user only works with EC2 and S3, grant access only to those services. This improves security and reduces the risk of accidental changes.

✅ Remember

IAM is not just about giving access — it’s about giving the right access, to the right entity, at the right time, and nothing more.

By properly structuring users, groups, roles, and policies, you build a secure, scalable, and professionally managed AWS environment.