Tag Policies in AWS Organizations

A tag policy is a rule-based policy in AWS Organizations that specifies the rules for tagging resources across accounts in your organization. Tag policies help you standardize tags, enforce tag compliance, and automate tag management. They are written in JSON format and can include rules such as:

Tag policies are attached to organizational units (OUs) or directly to accounts. They apply to all IAM users and roles in the target accounts, as well as to AWS services that create resources on your behalf. Tag policies do not directly prevent tag operations; instead, they mark resources as noncompliant if tags violate the policy. However, you can use AWS Config rules to enforce compliance by triggering remediation actions.

When you create or update a tag policy, AWS Organizations replicates the policy to all affected accounts. The policy is stored as a JSON document. When a resource creation or tagging operation occurs, the AWS service checks the tag policy for that account. If the operation violates the policy, the resource is still created or tagged, but it is flagged as noncompliant. The compliance status can be viewed in the Tag Policy console or via the AWS Organizations API.

Tag policies are evaluated based on the resource's AWS account and the region. Each account can have multiple tag policies applied from different OUs, and the policies are merged using a union logic: the most restrictive rule for each tag key is applied. For example, if one policy allows 'Environment' with values 'Prod' and 'Dev', and another allows 'Environment' with values 'Prod' and 'Test', the effective allowed values are 'Prod' only (intersection of allowed values? Actually, it's union of allowed values? Let's clarify: Tag policies use a 'deny' override model. If any policy denies a tag value, it is denied. For allowed values, the effective set is the intersection? No, the documentation states that when multiple policies are applied, the most restrictive combination is used. For allowed values, the intersection is used. For example, if Policy A allows values ['Prod', 'Dev'] and Policy B allows values ['Prod', 'Test'], the effective allowed values are ['Prod'] only. This is a common exam trap.)

- Tag policy JSON structure: Contains a tags object with tag keys as properties. Each tag key can have: - tag_key: The tag key name (supports case sensitivity settings). - tag_value: An array of allowed values, or a wildcard ["*"] to allow any value. - enforced_for: A list of resource types that the rule applies to. If omitted, it applies to all resource types. - case_sensitive: Boolean (default true). If false, the tag key and values are case-insensitive.

To create a tag policy: 1. Sign in to the AWS Organizations console as a management account user. 2. Navigate to Policies > Tag policies. 3. Click Create policy. 4. Provide a name and optional description. 5. Define the policy JSON. Example:

{
  "tags": {
    "CostCenter": {
      "tag_value": [
        "CC-100",
        "CC-200"
      ],
      "enforced_for": [
        "ec2:instance",
        "s3:bucket"
      ]
    },
    "Environment": {
      "tag_value": [
        "Prod",
        "Dev"
      ],
      "case_sensitive": false
    }
  }
}

To verify compliance:

aws organizations list-policies-for-target --target-id ou-xxxx --filter TAG_POLICY
aws organizations list-targets-for-policy --policy-id p-xxxx
aws organizations describe-policy --policy-id p-xxxx

aws organizations list-roots
aws organizations list-children --parent-id r-xxxx --child-type ACCOUNT

Tag policies use a 'deny list' approach for tag keys: if a tag key is not defined in the policy, it is allowed by default? Actually, the default behavior is that any tag key not specified in the policy is allowed. To restrict tags, you must explicitly list the allowed tag keys. For tag values, if you specify allowed values, only those values are permitted; otherwise, any value is allowed. The enforced_for field limits the rule to specific resource types; if a resource type is not listed, the rule does not apply.

Tag policies are evaluated in near real-time. However, compliance status may take a few minutes to update. There is no specific timer; it is event-driven. The maximum size of a tag policy document is 10,000 characters. There is no limit on the number of tag policies per organization, but there is a limit on the number of policies attached to a target (OU or account): up to 10 tag policies per target.

When multiple tag policies apply to a resource, the effective policy is the union of all tag keys (with restrictions). For each tag key, the effective allowed values are the intersection of allowed values across all policies. If a policy does not specify a tag key, that key is considered unrestricted (any value allowed). However, if any policy denies a tag key (by not listing it? Actually, tag policies do not have a deny mechanism; they only specify allowed keys/values. If a key is not listed, it is allowed. So to restrict a key, you must list it with allowed values. If multiple policies list the same key, the intersection of allowed values is used. If one policy lists the key and another does not, the key is still subject to the restrictions of the policy that lists it. The policy that does not list it does not add any restrictions. Therefore, to fully restrict a tag, you must ensure all policies that apply to the account either list the allowed values or do not mention the key (which means no restriction from that policy). The most restrictive policy for a given key is the one that lists the narrowest allowed values.

Example: Policy A (attached to root) allows Environment: ["Prod", "Dev"]. Policy B (attached to OU) allows Environment: ["Prod", "Test"]. The effective allowed values for accounts in that OU are ["Prod"]. If Policy B did not mention Environment, then the effective allowed values would be ["Prod", "Dev"] from Policy A.

In a large enterprise with hundreds of AWS accounts, tag policies are essential for cost allocation and security compliance. For example, a financial services company must tag all resources with CostCenter, Environment, and DataClassification. The cloud governance team creates a tag policy attached to the root OU that requires these three tags on all EC2 instances, S3 buckets, and RDS databases. The policy allows specific values: CostCenter must be one of the predefined cost center codes, Environment must be Prod, Dev, or Test, and DataClassification must be Public, Internal, or Confidential. The policy sets case_sensitive: false to avoid user errors. When developers in a member account launch an EC2 instance without the required tags, the instance is created but appears as noncompliant in the Tag Policy console. The governance team receives a daily compliance report and uses AWS Config rules to automatically stop instances that remain noncompliant for more than 24 hours. This ensures that all resources are properly tagged for cost tracking and security audits.

Another scenario: A healthcare company uses tag policies to enforce tagging standards for HIPAA compliance. They require that any resource containing protected health information (PHI) must have a tag PHI: true. The tag policy defines that the PHI tag key is allowed only with values true or false, and it applies to all resource types. Additionally, they use enforced_for to apply the rule only to services that can store PHI, like S3, DynamoDB, and RDS. This prevents unnecessary compliance flags on resources like Lambda functions. The policy also includes a rule that the Environment tag must be Prod for production resources. When a developer accidentally tags a production S3 bucket with Environment: prod (lowercase), it becomes noncompliant because the policy expects exact case match (since case_sensitive defaults to true). The compliance report flags it, and the developer corrects the tag.

A common misconfiguration is forgetting to attach the tag policy to the correct OU. For instance, if the policy is attached only to the root, but a new OU is created under the root, the policy automatically applies to the new OU via inheritance. However, if the policy is attached to a specific OU and not the root, accounts outside that OU are not affected. This leads to gaps in compliance. Another issue is exceeding the 10-policy attachment limit per target. If you try to attach an 11th policy, the operation fails. Also, if multiple policies have conflicting allowed values, the intersection might result in an empty set, making it impossible to tag any resource with that key. For example, if Policy A allows Environment: ["Prod"] and Policy B allows Environment: ["Dev"], the effective allowed values are empty, so any attempt to tag with Environment will be noncompliant. This can cause widespread noncompliance if not carefully designed.