Identity and Access Management

Identity and Access Management

AWS Identity and Access Management evaluates signed requests against identity policies, resource policies, session policies, permission boundaries, and organizational controls. A default deny applies; an applicable explicit deny overrides allows.

Core ideas

• Human users should normally federate from an identity provider and assume roles.
• Workloads use roles through services such as EC2 instance profiles, ECS task roles, and Lambda execution roles.
• Policies contain statements with effect, action, resource, and optional conditions.
• AWS STS issues temporary credentials whose session duration and permissions can be constrained.

Design and operating model

Define job functions, create narrow roles, scope actions and resources, then add conditions such as organization, network, tag, or requested Region where appropriate. Use IAM Access Analyzer and activity data to refine policies. Apply service control policies as account-level guardrails, not as grants.

Example

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::training-materials/public/*",
    "Condition": {
      "StringEquals": { "aws:PrincipalOrgID": "o-example" }
    }
  }]
}

Run examples in a disposable training account and replace Regions, identifiers, policies, resource sizes, and names with reviewed values. Verify commands with the current AWS CLI and service documentation before production use.

Production guidance

• Require MFA for privileged human access and eliminate unnecessary long-lived keys.
• Separate deployment roles from runtime roles and production from non-production accounts.
• Review unused permissions, cross-account trusts, resource policies, and privilege-escalation paths.

The chapter quiz follows the lesson and checks both service vocabulary and architecture decisions.