Guidance on Managing Policy Limits with Tag-Based Access (20 policies per role limit)

Question

Hi AWS Support,

I am currently facing the 20 policies per role limit in AWS IAM and am exploring ways to consolidate permissions using a single customer-managed policy that applies to all roles and enforces access based on resource tags.

Here is the scenario:

Each resource (e.g., RDS, DynamoDB, ElastiCache and more) has a tag called permitted_departments, e.g.,

4521e1d2-a662-447c-baf2-912b405981bb:806c3f0f-0190-48d0-be42-ab8cd8e22eb2

Roles have a tag called department, e.g.,

806c3f0f-0190-48d0-be42-ab8cd8e22eb2

My intention is to have one policy attached to all roles, with actions restricted via a condition like:

"Condition": {
    "StringLike": {
        "aws:ResourceTag/permitted_departments": "*${aws:PrincipalTag/department}*"
    }
}

Example of policy statements I planned:

{
    "Sid": "RDSModifyParameterGroupsTagged",
    "Effect": "Allow",
    "Action": [
        "rds:ModifyDBClusterParameterGroup",
        "rds:ModifyDBParameterGroup"
    ],
    "Resource": "*",
    "Condition": {
        "StringLike": {
            "aws:ResourceTag/permitted_departments": "*${aws:PrincipalTag/department}*"
        }
    }
},
{
    "Sid": "RDSDescribeReadOnly",
    "Effect": "Allow",
    "Action": [
        "rds:DescribeDBClusters",
        "rds:DescribeDBInstances",
        "rds:DescribeGlobalClusters",
        "elasticache:DescribeCacheClusters",
        "dynamodb:ListTables",
        "dynamodb:DescribeTable"
    ],
    "Resource": "*"
}

The problem:

AWS IAM does not support tag-based conditions for many Describe* or List* actions.

Currently, I create a separate policy per resource and attach it only to the permitted department, which works, but this approach is limited and does not scale.

I want to consolidate to a single policy but cannot restrict read-only actions (Describe/List) by tags.

Questions:

Is there a recommended approach to consolidate policies for multiple resources and roles while enforcing access based on tags, given that Describe* and List* actions do not support tag-based conditions?

Are there best practices for handling tag-based access control for read-only actions in AWS?

Could you suggest alternative strategies to avoid hitting the 20 policies per role limit without losing the ability to restrict access by department or tag?

Thank you for your guidance.

re:Post Agent · Answer

# Managing IAM Policy Limits with Tag-Based Access Control

You're facing a common challenge with IAM policy management when scaling across multiple departments and resources. Let me address your questions about tag-based access control and policy consolidation.

## Tag-Based Access Control Limitations

You've correctly identified a key limitation: many Describe* and List* actions in AWS services don't support tag-based conditions. This is by design, as these operations are typically needed to discover resources before performing actions on them.

## Recommended Approaches

1. **Separate Read vs. Write Policies**: Continue using a tag-based approach for write/modify operations while having broader read-only permissions. This aligns with your current policy structure where you're using tag conditions for ModifyDBParameterGroup but not for Describe* actions.

2. **Attribute-Based Access Control (ABAC)**: Expand your tag strategy to implement a full ABAC model. This allows you to grant permissions in bulk to resources with certain tags rather than creating separate policies for each resource type.

3. **Resource-Specific Policies with Higher Granularity**: Instead of having many small policies, create fewer, more comprehensive policies organized by function rather than by department.

## Best Practices for Tag-Based Access Control

- Use the appropriate condition keys:
- `aws:PrincipalTag` to compare tags attached to the calling principal
- `aws:RequestTag` to compare tags passed in the request
- `aws:ResourceTag` to compare tags attached to the accessed resource
- `aws:TagKeys` to control which tag keys can be used

- Avoid using `ResourceTag` condition keys with the `iam:PassRole` action as this approach doesn't provide reliable results.

- For Global Accelerator and similar services where tagging is limited to specific resources, understand which resources can be tagged before implementing tag-based policies.

## Alternative Strategies to Avoid the 20-Policy Limit

1. **Consolidate by Function**: Group permissions by functional area rather than department (e.g., "DatabaseManagement", "CacheManagement").

2. **Use Permission Boundaries**: Set permission boundaries on roles to limit maximum permissions while using fewer attached policies.

3. **Inline Policies for Role-Specific Permissions**: Use inline policies for unique permissions and managed policies for common permissions.

4. **Review and Refactor Existing Policies**: Analyze your current policies to identify redundancies and consolidate overlapping permissions.

By implementing these strategies, you can maintain proper access control while working within the IAM policy limits. The tag-based approach you're developing can work well for write operations, while accepting that read operations may need broader permissions.  
**Sources**  
[Controlling access to and for IAM users and roles using tags - AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_iam-tags.html)  
[Controlling access to AWS resources using tags - AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)  
[Using tags in IAM permission policies - Tagging AWS Resources and Tag Editor](https://docs.aws.amazon.com/tag-editor/latest/userguide/tags-in-iam-policies.html)  
[Using tag-based policies with AWS Global Accelerator - AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/security_iam-tag-policies.html)

Guidance on Managing Policy Limits with Tag-Based Access (20 policies per role limit)

Managing IAM Policy Limits with Tag-Based Access Control

Tag-Based Access Control Limitations

Recommended Approaches

Best Practices for Tag-Based Access Control

Alternative Strategies to Avoid the 20-Policy Limit

Add your answer

Relevant content