DEV Community

Cover image for Identity & Access Management on AWS — A Complete Guided Reference
Md Enayetur Rahman
Md Enayetur Rahman

Posted on

Identity & Access Management on AWS — A Complete Guided Reference

A practical, skimmable guide to workforce/workload access, least privilege, and the exact console flows you’ll use in a fresh AWS environment.

Why Identity & Access Management (IAM) Matters

  • Goal: Ensure only authenticated and authorized entities can touch your cloud resources.
  • Default = Deny: Nothing is allowed unless a policy explicitly permits it.
  • Cost: Most identity and access capabilities in AWS are free, so adopt them from day one.
  • AWS Account ≠ User:
    • Resource container: Owns your resources; every resource is uniquely identified by an ARN that embeds the account ID.
    • Security boundary: Isolates your resources from other accounts unless you explicitly allow cross‑account access.

AuthN vs AuthZ (and for Whom?)

Concept Question Examples Primary AWS Tools
Authentication (AuthN) Who are you? Sign‑in, access keys, MFA IAM Identity Center, federation to roles, IAM roles (workloads)
Authorization (AuthZ) What can you do? Allowed actions on resources IAM policies on users/groups/roles; resource policies; conditions

Services by Use Case

A) Workforce (People) Access

Recommended: IAM Identity Center (formerly AWS SSO)

  • Connect your existing identity source via SCIM or create local identities.
  • Central place to manage access to multiple AWS accounts and applications.
  • Use an Organization instance for production scale; Account instance for POCs.
  • Reduces duplication (“who has access to what?”) as you add accounts and apps.

If Identity Center isn’t possible: You can federate users to assume IAM roles per app/account. Works, but is less scalable—use only when you can’t use Identity Center.

Multi‑Account Strategy: With AWS Organizations, run separate accounts per workload/environment. Manage workforce permissions centrally with Identity Center.

AWS Builder ID: A personal identity for AWS tools/training that complements (doesn’t replace) Identity Center or account credentials.

B) Workloads (Devices, Services, Code) Access

IAM (core):

  • Every API call is evaluated against IAM (allows/denies).
  • Use IAM roles for temporary, scoped permissions (avoid long‑lived keys).
  • IAM Access Analyzer guides least privilege:
    • Generate least‑privilege policies from access activity.
    • Detect public/cross‑account exposure.
    • Validate policies for security & functionality.

IAM Roles Anywhere: Extend temporary IAM credentials to on‑prem, hybrid, multi‑cloud workloads using your PKI—reuse the same roles/policies you use in AWS.

AWS Directory Service (Managed Microsoft AD): Fully managed AD for directory‑aware, on‑prem + AWS resources via a single directory.

C) App‑Facing Auth for Your Users

Amazon Cognito: CIAM for web/mobile; native or third‑party sign‑in; scales to millions; handles auth + user management.

Amazon Verified Permissions: Externalize authorization from your apps; centralize policies using the Cedar language; improves security, auditability, and developer velocity.

IAM Policies — The Permission Engine (JSON)

Anatomy

  • Effect: Allow or Deny
  • Action: One or more API operations (e.g., s3:GetObject)
  • Resource: Specific ARNs the actions apply to
  • Condition (optional): Context rules (IP, VPC endpoint, MFA, time, tags)
  • Sid (optional): Statement identifier

Evaluation Logic

  1. Implicit deny to start.
  2. Explicit allow grants access.
  3. Any explicit deny overrides all allows.

Example — Read‑only S3 (broad)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "S3ReadOnly",
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:ListBucket",
      "s3:GetBucketLocation"
    ],
    "Resource": [
      "arn:aws:s3:::*",
      "arn:aws:s3:::*/*"
    ]
  }]
}
Enter fullscreen mode Exit fullscreen mode

Condition Ideas

  • Lock to a VPC endpoint: 
"Condition": { "StringEquals": { "aws:SourceVpce": "vpce-0123456789abcdef0" } }
Enter fullscreen mode Exit fullscreen mode
  • Require MFA for sensitive console actions: 
"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
Enter fullscreen mode Exit fullscreen mode

Principle of Least Privilege (PoLP) — How to Apply

  1. Grant only the specific permissions needed for each task.
  2. Start with AWS managed policies → evolve to customer managed policies tailored to your use cases.
  3. Remove unused users, roles, and permissions regularly.
  4. Narrow with Conditions (IP, time, MFA, tags, VPC endpoints, region).
  5. Combine grant policies with guardrails (permission boundaries, SCPs in Organizations).
  6. Prefer roles over static keys for EC2/Lambda/ECS/CI/CD.

Hands‑On: Exact Console Flows

1) Configure Administrative Access (New Account)

  1. Sign in as root (only for initial setup).
  2. Enable MFA on root.
  3. Enable IAM Identity Center (prefer “Enable with AWS Organizations”).
  4. Create AdministratorAccess permission set.
  5. Create a user in Identity Center → verify email → set password → enable MFA.
  6. Assign the user to the account with AdministratorAccess permission set.
  7. Enable Root access management (centralized control in Organizations).
  8. After setup, avoid root; use your admin user/role.

2) Permission Sets in Identity Center

  1. Identity Center → Permission sets → Create.
  2. Choose Predefined (e.g., ViewOnlyAccess) or Custom.
  3. Optionally set session duration.
  4. Assign to users/groups for the selected account(s).
  5. Verify via the AWS access portal; console shows the active permission set.

3) Create & Test an IAM Policy (S3 Read‑Only)

  1. IAM → Policies → Create policy → Service: S3.
  2. Actions: expand Read → All read actions.
  3. Resource: any bucket/object (or specific ARNs).
  4. Name & Create → then attach to a Role (IAM → Roles → Create role).
  5. Validate with IAM Policy Simulator (policysim.aws.amazon.com):
    • Pick your role, choose an action like s3:CreateBucket (should be Denied).

Quick Decision Guide

  • People need console/app access across accounts? → IAM Identity Center
  • Code/services need AWS API access? → IAM role with least‑privilege policy
  • External workloads (on‑prem/multi‑cloud)? → IAM Roles Anywhere
  • Your product’s end‑users (customers)? → Amazon Cognito
  • Centralized, app‑level authorization? → Amazon Verified Permissions (Cedar)
  • AD‑integrated workloads? → AWS Directory Service (Managed Microsoft AD)

Security Checklist (Copy/Paste)

  • [ ] Root MFA enabled; root not used for daily work
  • [ ] Identity Center enabled (Organization instance)
  • [ ] Admin permission set created & assigned; access portal verified
  • [ ] No long‑lived keys on compute; use roles/instance profiles
  • [ ] Access Analyzer enabled; review public/cross‑account findings
  • [ ] Policies follow least privilege; use conditions where possible
  • [ ] Routine access reviews; remove stale identities/policies
  • [ ] SCPs/permission boundaries as guardrails (Organizations)
  • [ ] Centralized logging/monitoring for root & privileged actions
  • [ ] Policy Simulator used to validate critical operations

Troubleshooting Access Denies — Checklist

  1. Identity: user vs assumed role? credentials current?
  2. Policies in play: identity, resource, session policies, boundaries, SCPs.
  3. Any explicit Deny? (wins over all Allows)
  4. Conditions failing? (IP, MFA, time, tags, VPC)
  5. Cross‑account trust correct? (trust policy principal/ARNs exact)
  6. Reproduce in Policy Simulator to isolate the statement.

Top comments (0)