3.4.1.6. Implementing Role-Based & Attribute-Based Access Control Patterns

3.4.1.6. Implementing Role-Based & Attribute-Based Access Control Patterns

RBAC and ABAC are complementary approaches to permissions at scale.

RBAC: Permissions based on role. Simple but requires policy updates for new resources.

{"Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::dev-*/*"}

ABAC: Permissions based on tags. Scales dynamically — new resources get access automatically.

{
  "Effect": "Allow",
  "Action": ["ec2:StartInstances", "ec2:StopInstances"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
    }
  }
}

This single policy lets any user manage EC2 instances tagged with their project. New projects just need proper tags — no policy changes.

When to use each:

• RBAC: Small orgs, compliance frameworks requiring named roles, simple environments
• ABAC: Large orgs, dynamic resource creation, multi-team, microservices

Exam Trap: ABAC requires consistent tagging. If a resource isn't tagged or tagged incorrectly, access silently fails. The exam may present "some developers can access resources but others can't" — the answer is usually inconsistent tagging on resources or principals.