AWS ABAC: Attribute-Based Access Control with IAM Tags

Attribute-Based Access Control (ABAC) is an IAM authorization strategy that makes access decisions from attributes, which AWS commonly represents with tags. Instead of writing a separate policy for every person, team, or resource, you write a reusable policy that allows access when the relevant principal and resource attributes match.

This is Part 48 of the AWS Cloud Practitioner Study Notes. The one-line summary is:

Tag the principal
        +
Tag the resource
        +
Write a policy that compares the tags
        ↓
Access is allowed only when the required attributes match

Tags alone do nothing. The IAM policy condition is what turns labels into authorization logic.

ABAC’s three building blocks

Building block	Purpose	IAM mechanism
Principal attribute	Describes who is making the request	aws:PrincipalTag/key
Resource attribute	Describes the target resource	Service-specific service:ResourceTag/key or aws:ResourceTag/key where supported
IAM policy	Compares attributes and allows or denies the request	Condition block

The exact resource condition key depends on the AWS service and action. For example, EC2 commonly uses ec2:ResourceTag/CostCenter, while some services support the global aws:ResourceTag/CostCenter key. Always check the service’s Actions, Resources, and Condition Keys documentation.

Worked example: matching EC2 tags

Suppose a company has employees assigned to committees. An employee should be able to start or stop only the EC2 instances belonging to the same committee.

1. Tag the principal

Attach a tag to the IAM user or role, or pass the attribute as a session tag through federation:

CostCenter = Fundraising

2. Tag the resource

Tag the EC2 instance:

CostCenter = Fundraising

3. Attach one reusable policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}"
        }
      }
    }
  ]
}

The result is:

Fundraising principal → Fundraising EC2 instance → Allowed
Fundraising principal → Finance EC2 instance      → Not allowed by this statement

When a new employee joins, tag the principal. When a resource moves to another committee, update its tag. The policy does not need to be rewritten for each new person or instance.

How IAM evaluates the match

When the principal makes a request, IAM builds a request context containing the relevant principal tag and resource tag. The policy compares them:

aws:PrincipalTag/CostCenter = Fundraising
ec2:ResourceTag/CostCenter  = Fundraising
        ↓
StringEquals returns true
        ↓
This policy statement can allow the action

If the values differ, the condition is false. If the principal or resource tag is missing, the condition normally does not match and the statement does not grant access. Other applicable IAM policies, permissions boundaries, SCPs, resource policies, and explicit denies still participate in the final authorization decision.

ABAC does not override an explicit Deny. It is one part of the IAM policy evaluation process.

Principal tags and session tags

The principal tag can come from:

• A tag attached to an IAM user
• A tag attached to an IAM role
• A session tag passed when a role is assumed
• Access-control attributes passed through IAM Identity Center federation

Session tags are useful when the identity provider owns the user’s department, team, project, or cost-center attributes. The user can federate into AWS, receive a session with attributes, and use the same reusable policy.

Identity provider
        ↓
Session tag: CostCenter=Fundraising
        ↓
AWS role session
        ↓
aws:PrincipalTag/CostCenter

The trust policy and role-assumption permissions must be designed so that users cannot arbitrarily choose privileged session-tag values. Otherwise, a user might set their own tag to match a sensitive resource. Protect the ability to pass or change session tags.

Resource tags are service-specific

ABAC is not a promise that every AWS action supports every tag condition key. Check the service documentation for:

• Whether the resource can be tagged
• Whether the action supports resource-tag conditions
• Whether the action supports request-tag conditions when creating a resource
• Which condition-key namespace to use
• Whether the resource tag is evaluated by the control plane or data plane

For example, EC2 uses keys such as ec2:ResourceTag/CostCenter for many resource actions. Other services use their own service prefix or the global aws:ResourceTag key.

Important S3 caveat

S3 has more than one tagging context:

• S3 general-purpose bucket tags can support ABAC when bucket ABAC is enabled and the relevant conditions are supported.
• S3 object tags use s3:ExistingObjectTag/tag-key, not aws:ResourceTag/tag-key.

Therefore, a generic policy using aws:ResourceTag/Department on an s3:GetObject object ARN should not be assumed to work. For object-tag authorization, use the S3-specific condition key and verify the action’s support. This service-specific detail is why an EC2 example is clearer for learning the core principal-versus-resource matching pattern.

ABAC versus RBAC

Role-Based Access Control (RBAC) assigns permissions through roles or groups. ABAC assigns or evaluates permissions through attributes.

Situation	ABAC	RBAC
Many users and resources with the same pattern	Strong fit	Can create many groups and policies
Frequent team or project changes	Update tags or session attributes	Move users and rewrite assignments
Small, stable team	May be unnecessary complexity	Simple and easy to audit
Dynamic multi-project access	Flexible	More static
Very sensitive, small resource set	Requires careful tag governance	Explicit permissions may be clearer
Main operational risk	Incorrect or changed attributes	Policy and group sprawl

ABAC scales well when the organisation and resources change frequently. RBAC can be easier to understand when the user population and resource set are small and stable.

ABAC for resource creation

ABAC must also control how resources are tagged. If a user can create a resource without the required tag, the resource may become inaccessible to the intended team—or a user may add a misleading tag.

A complete ABAC design commonly uses:

Allow creation only when required request tags are present
        ↓
Allow access only when principal and resource tags match
        ↓
Prevent unauthorised users from changing access-control tags

For creation and tagging operations, policies can use condition keys such as:

• aws:RequestTag/key
• aws:TagKeys
• Service-specific request-tag keys

For example, an organisation might require CostCenter and Environment on new resources and restrict the allowed values. It should also control who may remove or change those tags because changing an access-control tag can change who is authorised.

Tags must be governed

ABAC makes tags part of the security boundary. Treat them as security-sensitive metadata:

• Standardise tag keys and allowed values.
• Prevent users from modifying tags that control access unless authorised.
• Protect session-tag creation and role assumption.
• Ensure resources cannot be created without required tags.
• Monitor tag changes with CloudTrail and governance controls.
• Test missing-tag behavior and mismatched-tag behavior.
• Keep explicit denies for high-risk actions where appropriate.
• Check every AWS service’s supported condition keys.

Bad ABAC design
→ Users can freely edit Department tags
→ Users can choose their own privileged session tags
→ Access boundary becomes unreliable

ABAC is only as trustworthy as the process that controls its attributes.

Common exam questions

What does ABAC use to make authorization decisions in AWS?

Attributes, commonly tags on principals and resources.

Which key reads a tag on the requesting IAM principal?

aws:PrincipalTag/key.

Which key reads a tag on a resource?

The appropriate resource-tag condition key, such as ec2:ResourceTag/key or aws:ResourceTag/key where supported.

Do tags grant permissions by themselves?

No. An IAM policy condition must use the tags.

What is the advantage of ABAC over separate static policies?

A reusable policy can apply to new users and resources when their attributes match.

What happens when a principal’s tag does not match the resource tag?

The condition fails, so that policy statement does not allow the action.

Can ABAC override an explicit IAM deny or SCP deny?

No. An explicit deny still overrides an allow.

Does every AWS service support ABAC identically?

No. Support is service- and action-specific; verify the condition keys and resource types.

Final memory map

Principal tag
→ aws:PrincipalTag/Department

Resource tag
→ service:ResourceTag/Department

Policy condition
→ StringEquals principal tag and resource tag

Match
→ Statement may allow

No match or missing tag
→ Statement does not allow

The one-line takeaway is: ABAC tags people and resources, then uses one policy to require a matching attribute. It is powerful for growing organisations, but it requires strict tag and session governance.

Sources

• Define permissions based on attributes with ABAC
• AWS global condition key: aws:PrincipalTag
• EC2 policy example using matching principal and resource tags
• IAM ABAC tutorial
• S3 ABAC and object-tag condition keys