IAM: Identity & Access Management

Everything is an API call

When you click "Create bucket" in the console, the browser sends s3:CreateBucket to the S3 control plane. When your Spring Boot app on ECS reads a secret, the task role credentials sign secretsmanager:GetSecretValue. When Terraform runs aws ec2 describe-instances, the IAM user or role behind the provider must have ec2:DescribeInstances. Same engine, same evaluation order, every time.

IAM is global

IAM users, groups, roles, and policies exist once per account, not per region. You create a role in IAM once and attach it to EC2 instances in any region. The exception: some actions are region-scoped in policies via condition keys like aws:RequestedRegion, but the IAM entities themselves are global. Route53 and CloudFront are also global services; most others are regional.

Core components

flowchart TD
  START["Incoming API request\n(principal + action + resource)"]
  START --> EXPLICIT{"Explicit Deny\nin any policy?"}
  EXPLICIT -->|Yes| DENY["❌ DENY"]
  EXPLICIT -->|No| SCP{"SCP allows?\n(org guardrail)"}
  SCP -->|No| DENY
  SCP -->|Yes| RP{"Resource-based policy\nallows?"}
  RP -->|Explicit Deny| DENY
  RP -->|Allow| ALLOW["✅ ALLOW"]
  RP -->|No match| ID{"Identity-based policies\n(user/role/group) allow?"}
  ID -->|Explicit Deny| DENY
  ID -->|Allow| PB{"Permission boundary\nallows?"}
  ID -->|No Allow| IMPLICIT["❌ Implicit DENY"]
  PB -->|No| DENY
  PB -->|Yes| SP{"Session policy\n(AssumeRole) allows?"}
  SP -->|No| DENY
  SP -->|Yes| ALLOW

Evaluation order (simplified — exam-critical):

1. Explicit Deny — any policy, any type → immediate deny
2. SCPs — organization guardrails; cannot grant permissions, only deny or pass-through
3. Resource-based policies — S3 bucket policy, KMS key policy, SQS queue policy, Lambda resource policy
4. Identity-based policies — attached to user, group, or role
5. Permission boundaries — cap maximum permissions even if identity policies allow more
6. Session policies — passed during AssumeRole to further restrict the session
7. Implicit deny — default if no Allow matched

Policy structure

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowReadOwnBucketPrefix",
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::my-app-artifacts",
      "arn:aws:s3:::my-app-artifacts/${aws:username}/*"
    ],
    "Condition": {
      "Bool": { "aws:SecureTransport": "true" },
      "StringEquals": { "aws:RequestedRegion": "eu-west-1" }
    }
  }]
}

Wildcards — when to use and when to avoid

• s3:Get* — acceptable during prototyping; replace with explicit actions in production
• s3:* on arn:aws:s3:::* — almost never acceptable for application roles
• ec2:Describe* — common for read-only ops roles; low risk (no mutations)
• ? — single-character wildcard in some resource patterns; rarely needed

Condition operators and keys

High-value condition keys for backend engineers:

• aws:MultiFactorAuthPresent — require MFA for sensitive operations
• aws:CalledVia — restrict which service may call on your behalf (confused deputy prevention)
• aws:SourceVpc / aws:SourceVpce — only from your VPC or endpoint
• ec2:Region — legacy; prefer aws:RequestedRegion

Policy variables

Dynamic policies use ${aws:username}, ${aws:userid}, ${aws:PrincipalTag/key} in Resource or Condition values — one policy template for all developers instead of one policy per person.

NotAction and NotResource

NotAction means "everything except these actions" — e.g. deny all except s3:GetObject. Powerful and dangerous: easy to accidentally allow more than intended. Use explicit Allow lists instead when possible.

Inline vs managed policies

Example: least-privilege S3 read for a Spring service role

cat > /tmp/order-service-s3-policy.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-app-artifacts/orders/*",
    "Condition": { "Bool": { "aws:SecureTransport": "true" } }
  }]
}
EOF

aws iam create-policy --policy-name OrderServiceS3Access \
  --policy-document file:///tmp/order-service-s3-policy.json

aws iam attach-role-policy --role-name order-service-ecs-task \
  --policy-arn arn:aws:iam::123456789012:policy/OrderServiceS3Access

resource "aws_iam_policy" "order_service_s3" {
  name = "OrderServiceS3Access"
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = ["s3:GetObject", "s3:PutObject"]
      Resource = "${aws_s3_bucket.artifacts.arn}/orders/*"
      Condition = {
        Bool = { "aws:SecureTransport" = "true" }
      }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "order_service" {
  role       = aws_iam_role.ecs_task.name
  policy_arn = aws_iam_policy.order_service_s3.arn
}

import * as iam from 'aws-cdk-lib/aws-iam';
import * as s3 from 'aws-cdk-lib/aws-s3';

const bucket = s3.Bucket.fromBucketName(this, 'Artifacts', 'my-app-artifacts');

taskRole.addToPolicy(new iam.PolicyStatement({
  effect: iam.Effect.ALLOW,
  actions: ['s3:GetObject', 's3:PutObject'],
  resources: [`${bucket.bucketArn}/orders/*`],
  conditions: { Bool: { 'aws:SecureTransport': 'true' } },
}));

Trust policy vs permissions policy

Every role has two documents: a trust policy (who can assume the role) and one or more permissions policies (what the role can do once assumed). Confusing them is the #1 IAM mistake — granting s3:* in the trust policy does nothing; putting ec2.amazonaws.com in a permissions policy does nothing.

ECS task role vs EC2 instance role

On ECS with EC2 launch type, the container instance has an instance profile (pull images from ECR, send logs). Each task gets its own task role injected as environment credentials — your Spring service gets only the S3/DynamoDB permissions it needs, not the host's ECR pull permissions. On Fargate, there is no instance profile — only the task role matters.

Cross-account access

Account A assumes a role in Account B: B's role trust policy allows A's principal; B's permissions policy grants the actions; A's identity may also need sts:AssumeRole on the role ARN. Use External ID when a third party assumes into your account — prevents confused deputy attacks where another customer tricks the third party into assuming your role.

Role chaining

Assume role A, then from A assume role B — maximum session duration 1 hour for chained roles. Useful for hub-and-spoke access patterns; adds latency (two STS calls). Prefer direct trust where possible.

Create an ECS task role (production pattern)

aws iam create-role --role-name order-service-task \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": { "Service": "ecs-tasks.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }]
  }'

# Reference in task definition:
# "taskRoleArn": "arn:aws:iam::123456789012:role/order-service-task"

resource "aws_iam_role" "ecs_task" {
  name = "order-service-task"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Action    = "sts:AssumeRole"
      Principal = { Service = "ecs-tasks.amazonaws.com" }
    }]
  })
}

resource "aws_ecs_task_definition" "app" {
  family                   = "order-service"
  task_role_arn            = aws_iam_role.ecs_task.arn
  execution_role_arn       = aws_iam_role.ecs_execution.arn
  # ...
}

import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as iam from 'aws-cdk-lib/aws-iam';

const taskRole = new iam.Role(this, 'OrderServiceTaskRole', {
  assumedBy: new iam.ServicePrincipal('ecs-tasks.amazonaws.com'),
  description: 'Runtime permissions for order-service containers',
});

new ecs.FargateTaskDefinition(this, 'TaskDef', {
  taskRole,
  // executionRole for ECR pull + logs — separate, tighter role
});

The narrowing workflow

1. Start with AWS managed policy closest to need (e.g. AmazonDynamoDBFullAccess in dev only)
2. Enable CloudTrail in all regions; log to a security account
3. Run IAM Access Advisor — see last-accessed services per user/role; remove unused actions
4. Use IAM Access Analyzer — detect resources shared externally; validate policies before deploy
5. Generate policies from CloudTrail with Access Analyzer policy generator (last 90 days of actual API calls)
6. Replace with customer-managed policy; attach permission boundary for delegated admin teams

Permission boundaries

A permission boundary caps what a role/user can do even if attached policies allow more. Use case: let a product team create their own roles in CI, but cap them with a boundary that denies iam:*, organizations:*, and s3:DeleteBucket. The effective permission is the intersection of boundary and identity policies.

CloudTrail → Athena: find what a role actually used

-- Run against CloudTrail logs table in Athena
SELECT eventSource, eventName, count(*) AS calls
FROM cloudtrail_logs
WHERE userIdentity.arn LIKE '%order-service-task%'
  AND eventTime > date_add('day', -90, current_timestamp)
GROUP BY eventSource, eventName
ORDER BY calls DESC
LIMIT 50;

$ # Simulate: can this role publish to our queue?
$ aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/order-service-task \
  --action-names sqs:SendMessage \
  --resource-arns arn:aws:sqs:eu-west-1:123456789012:orders.fifo
→ EvalDecision: allowed | denied | explicitDeny
$ aws iam generate-service-last-accessed-details \
  --arn arn:aws:iam::123456789012:role/order-service-task
$ aws accessanalyzer validate-policy --policy-type IDENTITY_POLICY \
  --policy-document file://policy.json

GitHub Actions → AWS (OIDC) — the modern CI pattern

# 1. Create OIDC provider (once per account)
aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1

# 2. Role trust policy — only repo main branch can assume
# "Condition": {
#   "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" },
#   "StringLike": { "token.actions.githubusercontent.com:sub": "repo:myorg/my-app:ref:refs/heads/main" }
# }

resource "aws_iam_openid_connect_provider" "github" {
  url             = "https://token.actions.githubusercontent.com"
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = ["6938fd4d98bab03faadb97b34396831e3780aea1"]
}

resource "aws_iam_role" "github_deploy" {
  name = "github-actions-deploy"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Action = "sts:AssumeRoleWithWebIdentity"
      Principal = {
        Federated = aws_iam_openid_connect_provider.github.arn
      }
      Condition = {
        StringEquals = {
          "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
        }
        StringLike = {
          "token.actions.githubusercontent.com:sub" = "repo:myorg/my-app:ref:refs/heads/main"
        }
      }
    }]
  })
}

import * as iam from 'aws-cdk-lib/aws-iam';

const provider = new iam.OpenIdConnectProvider(this, 'GitHubOidc', {
  url: 'https://token.actions.githubusercontent.com',
  clientIds: ['sts.amazonaws.com'],
});

new iam.Role(this, 'GitHubDeployRole', {
  assumedBy: new iam.WebIdentityPrincipal(provider.openIdConnectProviderArn, {
    StringEquals: {
      'token.actions.githubusercontent.com:aud': 'sts.amazonaws.com',
    },
    StringLike: {
      'token.actions.githubusercontent.com:sub': 'repo:myorg/my-app:ref:refs/heads/main',
    },
  }),
  managedPolicies: [iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonEC2ContainerRegistryPowerUser')],
});

IAM Identity Center (AWS SSO)

For human access across multiple accounts: connect Okta/Azure AD once, define permission sets (templates of IAM policies), assign to groups per account. Engineers get 1–12 hour sessions via the SSO portal — no IAM users, no access keys. This is the AWS-recommended enterprise pattern and appears frequently on the SA Pro exam.

• 🔐

  Root account

  MFA enabled (hardware key). Access keys deleted. Never used for daily work. Email goes to a group alias, not one person.

• 🚨

  Break-glass

  Separate procedure for emergency root use — documented, audited, requires two people. Credentials in physical safe.

• 🏢

  SCPs everywhere

  Deny leaving org, deny disabling CloudTrail, deny unapproved regions, deny root API calls except from break-glass IP.

• 📜

  CloudTrail all regions

  Multi-region trail, log file validation, deliver to security account S3 with MFA delete. Alert on StopLogging.

• 👁

  GuardDuty on

  Detects credential exfiltration, unusual API geography, crypto mining, Tor activity. Enable org-wide from admin account.

• 🎭

  Roles not keys

  EC2/ECS/Lambda use roles. CI uses OIDC. Never hardcode keys in application.properties or GitHub secrets long-term.

Credential hygiene

• Rotate IAM access keys < 90 days if they must exist; prefer elimination over rotation
• Alert on access keys unused > 45 days (Config rule or Access Analyzer)
• Deny iam:CreateAccessKey for human users via SCP
• Use aws:MultiFactorAuthPresent for sensitive console/API operations

Example SCP: deny risky actions org-wide

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrg",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "DenyDisableAudit",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyUnapprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*", "organizations:*", "route53:*", "support:*",
        "budgets:*", "ce:*", "cloudfront:*", "globalaccelerator:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["eu-west-1", "us-east-1"]
        }
      }
    }
  ]
}