IAM Policies & Roles
IAM controls who can do what to which AWS resources. Policies are JSON documents with Effect (Allow/Deny), Action, Resource, and optional Condition. Roles are identities assumed by AWS services, applications, or federated users.
IAM is a courthouse: the judge (AWS) checks your ID (identity-based policy), the court rules (SCPs), and the deed to the property (resource-based policy) before granting access. All documents must agree.
Policy types: Identity-based (attached to users/groups/roles), Resource-based (attached to S3 buckets, SQS queues — allows cross-account access), Permissions boundaries (cap maximum permissions a role can have), SCPs (Service Control Policies in Organizations — guardrails across accounts), Session policies (temporary restriction when assuming a role). Policy evaluation: explicit Deny always wins. Otherwise, allow only if explicitly permitted. Least privilege: grant only what's needed. Use roles over long-term credentials.
Policy evaluation order: explicit Deny → Organizations SCP → Resource-based policy → Permissions boundary → Identity-based policy. All must allow; any deny blocks. IAM Access Analyzer identifies resources shared with external principals and generates least-privilege policies from CloudTrail activity. IAM Conditions: aws:SourceIp, aws:MultiFactorAuthPresent, aws:RequestedRegion, s3:prefix. Attribute-based access control (ABAC) uses tags as conditions: allow actions only when the resource tag matches the principal tag — scales better than role proliferation. IAM roles for EC2 use instance profiles; roles for Lambda use the execution role. Never embed access keys in code or AMIs.
IAM is the foundation of AWS security. I always use roles over long-term access keys, apply least privilege by generating policies from CloudTrail activity via Access Analyzer, and use SCPs in Organizations to set account-level guardrails. For cross-account access, I use resource-based policies or role assumption via STS. I use conditions (aws:MultiFactorAuthPresent, aws:SourceIp) to add context-aware restrictions.
Thinking that an identity-based Allow policy is sufficient for cross-account S3 access. Both the identity-based policy AND the S3 bucket policy must allow the cross-account principal. One allow alone is insufficient for cross-account resource-based policies.