AWS IAM EXPLAINED: IDENTITY & ACCESS MANAGEMENT BEST PRACTICES FOR CLOUD SECURITY

AWS IAM Explained: Identity & Access Management Best Practices for Cloud Security

IAM Policies

Policy- JSON documents that define permissions Attached to: Users, groups, or roles Types: - AWS managed policies - Customer managed policies - Inline policies

AWS evaluates permissions by combining all policies:

  1. Default = Deny (if no policy → no access).

  2. Explicit Deny > Allow (deny always wins).

  3. Explicit Allow → access is granted unless denied elsewhere.

  4. Permissions are cumulative (group + user + role).

IAM Policy Structure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetObject"],
      "Resource": [
        "arn:aws:s3:::mybucket",
        "arn:aws:s3:::mybucket/*"
      ]
    }
  ]
}
  • Version → always "2012-10-17".
  • Statement → list of rules.
  • Effect → Allow or Deny.
  • Action → API calls (e.g., ec2:StartInstances).
  • Resource → ARN of resource (e.g., arn:aws:s3:::bucket/*).
  • Condition → optional constraints (IP, MFA, time, tags).

IAM Password Policy

You can enforce rules for IAM user passwords.

Examples:

Minimum length

Require numbers, uppercase, lowercase, special chars

Password expiration

Prevent password reuse

👉 Managed at the account level (not per user).

Multi-Factor Authentication (MFA)

Adds a second layer of security. Even if password/keys are stolen → can’t login.

Options:

Virtual MFA App (Google Authenticator, Authy, AWS MFA app).

U2F Security Key (YubiKey, FIDO2 keys).

Hardware MFA Device (Gemalto tokens).

SMS MFA (for AWS GovCloud only, mostly deprecated).

👉 Exam tip: Virtual MFA is the most common.

IAM Roles for AWS Services

Roles are used when AWS services need permissions:

  • EC2 Role → instance profile, lets EC2 access S3/DynamoDB.

  • Lambda Execution Role → allows Lambda to access DynamoDB/SQS.

  • ECS Task Role → gives container-specific permissions.

  • CloudFormation Service Role → allows CFN to create/manage resources.

👉 No long-term credentials, only temporary STS tokens delivered by AWS.

IAM Security Tools

AWS provides built-in tools:

  • IAM Credentials Report → lists all users, keys, MFA, last usage.

  • IAM Access Advisor → shows last-used services for a user/role.

  • Access Analyzer → detects resources (S3, KMS, IAM) shared with external accounts.

  • Policy Simulator → test what a policy actually allows/denies.

IAM Best Practices

  • Don’t use root account (enable MFA, lock it away).
  • Use IAM roles instead of embedding keys in apps.
  • Grant least privilege (start restrictive → open up if needed).
  • Rotate credentials regularly.
  • Enable MFA for all IAM users.
  • Use groups for permissions, not direct user policies.
  • Audit IAM using Credentials Report & CloudTrail.
  • Use IAM Access Analyzer to spot overly permissive access.

IAM Integration Scenarios

## IAM + S3 (Accessing Buckets)

Real-life example

  • You have an EC2 app that needs to read/write S3 objects.

  • Instead of embedding keys → use an IAM Role attached to the EC2 instance.

Policy Example

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::mybucket/*"
  }]
}

Attach this to the EC2 Role. Now EC2 can fetch S3 creds from Instance Metadata Service (IMDS) automatically.

Exam Tip: If app can’t access S3 → check:

  • Role attached?

  • Policy correct resource ARN (bucket vs bucket/*)?

IAM + CloudWatch (Logs/Monitoring)

Real-life example

  • Lambda → needs permission to write logs to CloudWatch.

Policy:

{
  "Effect": "Allow",
  "Action": [
    "logs:CreateLogGroup",
    "logs:CreateLogStream",
    "logs:PutLogEvents"
  ],
  "Resource": "*"
}

What’s usually extra on the exam (don’t skip):

  • Temporary credentials (STS)AssumeRole, session duration, intersection of session policy & role policy.

  • Cross-account roles → trust policy + permission policy needed (they love this scenario).

  • SigV4 signing → for API Gateway & S3 presigned URLs (highly testable).

  • Resource vs identity policies → e.g., S3 bucket policy vs IAM user policy.

  • Condition keys → especially MFA (aws:MultiFactorAuthPresent), source IP (aws:SourceIp), request tags.

  • Permissions boundaries vs SCPs (know the difference conceptually).

×