AWS Tag Policies and Backup Policies Explained: Governing Resources Across Your Organization

Key Takeaways

• Tag policies and backup policies are both management policies in AWS Organizations, but they govern different things: tag policies define how resources should be tagged across your organization, while backup policies define how they should be protected.
• Tag policies are primarily an observability and consistency tool. They'll flag noncompliant resources and can optionally block noncompliant tag changes, but they can't prevent untagged resources from being created through the API or console, regardless of enforcement mode. That requires an SCP, or, for infrastructure as code, the required tag keys validation AWS added in November 2025.
• Backup policies are more active by design. When a backup policy is attached to an OU or account, AWS Backup automatically creates and applies backup plans in every account under it, regardless of whether individual teams have configured anything locally.
• The two policies are most useful when designed together. A backup policy that targets resources by tag only works reliably if a tag policy is ensuring those tags are applied consistently. Each construct reinforces the other.

The failure mode is consistent across organizations that have grown past a handful of AWS accounts: cost reports that can't be attributed accurately, backup gaps discovered during an incident rather than before one, and attribute-based access control policies that quietly stop working because someone tagged a resource environment: Production where the policy expected Environment: prod. These failures have different surfaces, but they share a root cause. There was never a centralized standard.

AWS Organizations provides two policy types that address this directly: tag policies, which define how resources across the organization should be tagged, and backup policies, which define how they should be protected. They belong on this page together because they're most useful when they're designed together. A backup policy that selects resources by tag only works if those tags are consistently applied. A tag policy that standardizes a backup-policy key creates the foundation that makes backup policy resource selection reliable. The two constructs are operationally complementary, and understanding both at once makes each one easier to reason about.

Where Tag Policies and Backup Policies Fit in AWS Organizations

AWS Organizations organizes its policy types into two categories. Authorization policies, including Service Control Policies (SCPs) and Resource Control Policies (RCPs), control what API actions can be performed inside your accounts. Management policies configure how specific AWS services behave. Tag policies and backup policies are both management policies.

The distinction that matters most in practice is the one between tag policies and SCPs, because practitioners regularly expect one to do the job of the other. An SCP can require that tags exist by adding a condition to a Deny statement that blocks resource creation when a specific tag key is absent. A tag policy defines what compliant tag values look like for keys that are already present, and can optionally block noncompliant tag updates. The two tools govern different things: SCPs are the right mechanism for making tags required; tag policies are the right mechanism for ensuring tags that exist are correctly formatted. When tagging governance breaks down, it's usually because one was expected to do the work of the other.

Both policy types require AWS Organizations to be running in all features mode. They can be attached to the organization root, to any OU, or to individual accounts, and they inherit and merge downward through the hierarchy. The diagram below shows how this works in practice.

Organization Root
├── Root Tag Policy (defines CostCenter allowed values)
├── Root Backup Policy (defines weekly backup baseline)
│
├── Production OU
│   ├── OU Tag Policy (appends additional Environment values)
│   ├── OU Backup Policy (adds daily backup rule)
│   │
│   └── Account A
│       └── Effective policy = Root + OU merged
│
└── Development OU
    └── Account B
        └── Effective policy = Root only

Enabling a policy type in Organizations doesn't enforce anything on its own. You still need to create and attach policies for them to have any effect.

What Is an AWS Tag Policy?

A tag policy is an AWS Organizations management policy that defines tagging standards for resources across your organization's accounts. It specifies how tag keys should be capitalized, which values are allowed for a given key, and which resource types those rules apply to. A tag policy doesn't restrict what actions can be performed on resources; it defines what compliant tagging looks like and surfaces where actual tags deviate from that definition.

How Tag Policy Enforcement Works

Tag policies operate in two modes. In reporting mode, which is the default, a policy flags noncompliant tags and makes that compliance data available through the tag compliance report in the AWS Resource Groups and Tag Editor console, under Tag policies. An EC2 instance tagged environment: Production where the policy requires Environment: prod would show up as noncompliant, but the instance would still exist and the tag would still persist.

In enforcement mode, you add the enforced_for element to the policy for specific resource types. When enforcement is active, AWS blocks any tag operation that would leave the resource in a noncompliant state. Trying to apply environment: Production to an EC2 instance where the policy requires Environment: prod would be rejected at the API level.

Two things are worth being precise about. First, enforcement applies to tag changes, not to resource creation. A developer who creates an EC2 instance without any Environment tag at all won't be blocked, regardless of whether enforcement mode is on. Tag policies have no mechanism for requiring that a tag key be present at creation time. For that, you need an SCP with a Deny condition that checks for the tag's absence. Second, compliance reports have setup requirements. Organization-wide compliance reports can only be requested from us-east-1 and require credentials from the management account. Per-account reports can be run from the account itself.

Tag Policy Example

The following policy enforces CostCenter and Environment tags with allowed values and applies enforcement to specific resource types. A child OU could inherit this policy and add additional allowed values using the @@append operator without overwriting the parent's list, since @@append adds to the inherited values while @@assign replaces them entirely.

{
  "tags": {
    "CostCenter": {
      "tag_key": {
        "@@assign": "CostCenter"
      },
      "tag_value": {
        "@@assign": [
          "Engineering",
          "Security",
          "Finance",
          "Operations"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "rds:db",
          "s3:bucket"
        ]
      }
    },
    "Environment": {
      "tag_key": {
        "@@assign": "Environment"
      },
      "tag_value": {
        "@@assign": [
          "prod",
          "staging",
          "dev"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "rds:db",
          "lambda:function"
        ]
      }
    }
  }
}

As of July 2025, tag policies support the ALL_SUPPORTED wildcard in the enforced_for element (and in report_required_tag_for), which lets you cover every supported resource type for one service in a single line rather than listing each type. It has to be service-prefixed, as in ec2:ALL_SUPPORTED. There is no bare ALL_SUPPORTED that spans services.

What Is an AWS Backup Policy?

A backup policy is an AWS Organizations management policy that defines AWS Backup plans and automatically applies them to member accounts. When a backup policy is attached to an OU, AWS Backup creates the specified backup plan in every account under that OU and runs it according to the defined schedule. Teams in those accounts don't have to configure anything locally: the plan appears and runs automatically.

How Backup Policy Enforcement Works

Backup policies use a merge model when multiple policies apply to the same account. A policy at the root might define a weekly backup baseline. A policy at the production OU might add a daily backup rule. The account-level effective policy merges both, and the account ends up running a weekly and a daily backup plan. Three inheritance operators control how merging works: @@assign replaces the parent's value for a given element, @@append adds to the parent's list, and @@remove strips specific values from the inherited list. When no operator is specified, @@assign is the default. Understanding which operator applies to which element is important when layering policies, because @@assign at a child level silently replaces everything the parent set for that element.

One important constraint: backup policies target resources by resource type or by tag, not by individual resource ARN. If you want to back up only resources tagged backup-policy: required, you'd use tag-based selections, which is where the connection to tag policies becomes concrete. Targeting individual resources by ARN requires a local backup plan in the account.

Backup Policy Example

The following policy defines a daily backup plan that targets resources tagged backup-policy: required across two regions. The $account variable is substituted with the actual account ID at runtime, and $region does the same for the Region the plan is running in. Together they are what make a single policy portable across all member accounts.

{
  "plans": {
    "OrgDailyBackupPlan": {
      "regions": {
        "@@assign": [
          "us-east-1",
          "us-west-2"
        ]
      },
      "rules": {
        "DailyRule": {
          "schedule_expression": {
            "@@assign": "cron(0 5 ? * * *)"
          },
          "start_backup_window_minutes": {
            "@@assign": "60"
          },
          "complete_backup_window_minutes": {
            "@@assign": "240"
          },
          "lifecycle": {
            "delete_after_days": {
              "@@assign": "35"
            }
          },
          "target_backup_vault_name": {
            "@@assign": "OrgDefaultVault"
          }
        }
      },
      "selections": {
        "tags": {
          "OrgBackupSelection": {
            "iam_role_arn": {
              "@@assign": "arn:aws:iam::$account:role/OrgBackupRole"
            },
            "tag_key": {
              "@@assign": "backup-policy"
            },
            "tag_value": {
              "@@assign": [
                "required"
              ]
            }
          }
        }
      }
    }
  }
}

Tag Policies vs. Backup Policies: What Each Governs

Limits and Quotas

These quotas apply at the AWS Organizations level. Hitting them is rare for most organizations but worth knowing before you design a deeply layered policy architecture.

Policy documents are measured without whitespace when saved through the console. When saved via CLI or SDK, whitespace counts toward the limit. For complex organizations, it's worth splitting policies by function across multiple attached documents rather than consolidating everything into one.

Best Practices

The most useful starting point is treating tag policies as a prerequisite to any tag-dependent control. Attribute-based access control, cost allocation, and backup targeting all depend on tags being applied consistently. Standardizing capitalization and allowed values before building controls that consume those tags prevents significant remediation work later.

From that baseline, enable enforcement mode selectively rather than all at once. Start in reporting mode, run the compliance report, and understand the gap before enabling enforcement on specific resource types. Organizations that move to enforcement without a baseline view often block legitimate operations and create friction that drives teams toward policy exceptions, which is the opposite of the governance outcome you're after.

Once you have tag standards in place, using tag policies and backup policies together is where the compounding value shows up. A backup policy that targets resources by tag only works reliably if those tags are correctly formatted. Standardizing the specific keys your backup policy relies on, such as backup-policy or data-tier, through a tag policy is what makes tag-based resource selection consistent at scale.

At that point, layering backup policies at multiple OU levels rather than trying to express everything in a single root policy gives you both flexibility and legibility. A root policy can define a weekly baseline. Production OUs can add daily schedules. Database OUs can set longer retention windows. The merge model is designed for this approach, and it keeps each individual policy document well within the character limit.

Finally, use the $account and $region variables in backup policies wherever you reference account-specific or Region-specific resources like IAM roles or vault ARNs. Hardcoding account IDs into a policy that applies across hundreds of accounts is a consistent source of failed backup jobs.

Common Mistakes

Most of these appear when organizations adopt one policy type without fully understanding the other, or when the design assumptions behind a policy type don't match what practitioners expect them to do.

Assuming tag policies prevent untagged resource creation. They don't, and enforcement mode doesn't change this. Tag policies evaluate tag operations: attempts to apply a tag value that isn't in the allowed list. A resource created with no Environment tag at all passes through without being blocked. If preventing untagged resource creation is the goal, the right tool is an SCP with a Deny condition that checks for the tag's absence, not a tag policy with enforcement enabled. AWS did add a required tag keys capability in November 2025 that fails deployments missing required keys through a CloudFormation hook, the Terraform AWS provider, or a Pulumi policy pack, but it only covers infrastructure as code, not direct API or console creation.

Forgetting to pre-create backup vaults and IAM roles in member accounts. Backup policies define plans, but the vaults they write to and the IAM roles they assume have to exist in each member account before the plan runs. If the referenced vault or role doesn't exist at job execution time, the backup job fails without obvious visibility. Using CloudFormation StackSets to pre-provision OrgDefaultVault and OrgBackupRole in every account before attaching backup policies is the standard approach.

Building backup policies that accidentally target the same resources twice. If a parent OU policy and a child account policy both select the same EC2 volumes with no override operators, those volumes get backed up by both plans. The merge model doesn't deduplicate. Using @@assign at a child level explicitly replaces the parent selection for that element and prevents accidental duplication.

Running organization-wide tag compliance reports from the wrong account or region. Organization-wide compliance reports require management account credentials and must be requested from us-east-1. Teams who try to pull these reports from a member account or another region get incomplete results and sometimes interpret partial data as full compliance.

Leaving tag policies in reporting mode indefinitely. Reporting without enforcement gives visibility but doesn't change behavior. Teams see the compliance report, note the problems, and have no incentive to fix tags that aren't blocking anything. The compliance report is the right place to start, but it's only useful if it's followed by a plan to enable enforcement on the resource types where consistent tagging matters most.

Native connects the governance intent behind policies like these to the broader architectural intent of your organization. If you're working through how tag policies, backup policies, SCPs, and RCPs fit together into a coherent cloud security control model, see how Native approaches that layer.

FAQ

Q: What's the difference between an AWS tag policy and an SCP that restricts tagging?

They control different things. A tag policy defines standards for what tag keys and values should look like, and can optionally block noncompliant tag changes for specific resource types. An SCP can restrict tagging actions by limiting which IAM principals can call tagging APIs, but its more common use in tagging governance is requiring that specific tags exist before a resource can be created. The two can work together: an SCP handles whether required tags are present; a tag policy handles whether the values applied to those tags are correct.

Q: Do tag policies prevent resources from being created without required tags?

No. Tag policies evaluate tag operations, not resource creation events. They can block you from applying a value that's not in the allowed list, but they have no mechanism for requiring that a tag key be present at creation time. To prevent untagged resource creation, you'd use an SCP with a Deny condition that checks for the absence of a required tag, or a preventive guardrail embedded at the architecture layer. AWS also shipped a required tag keys validation in November 2025 that fails CloudFormation, Terraform, and Pulumi deployments missing required keys, though it doesn't cover direct API or console creation.

Q: What's the difference between an AWS Organizations backup policy and a local backup plan?

A backup policy is defined in the management account (or a delegated administrator account) and gets applied automatically to all member accounts it's attached to. A local backup plan is created directly inside a member account and only affects resources in that account. The two can coexist: organization backup policies handle the baseline, and account-level plans handle anything that needs to be targeted by specific resource ARN, which backup policies can't do.

Q: Can an account opt out of an organization backup policy?

No. Once a backup policy is attached to an OU or account, it runs. There's no mechanism for a member account to opt out of an organization-level backup policy. The management account or delegated administrator can modify or detach the policy, but individual member accounts can't override it.

Q: How do multiple backup policies merge at the account level?

When more than one backup policy applies to an account, AWS merges them using the inheritance operators in each policy document. @@assign replaces the parent's value for that element. @@append adds to the parent's list. @@remove strips specific values from the inherited list. If no operator is specified, @@assign is the default. The merged result is the effective backup policy for that account, and that's what runs.

Q: What happens if the IAM role referenced in a backup policy doesn't exist in a member account?

The backup job will fail at execution time. The backup policy itself will appear as attached and active, but the failure won't surface prominently unless you have AWS Backup compliance monitoring configured. The recommended approach is to use CloudFormation StackSets to pre-create the required IAM role and backup vault in member accounts before attaching backup policies to their OUs.

Q: Where do I see which resources are noncompliant with my tag policies?

Tag compliance data is available in the AWS Resource Groups and Tag Editor console under Tag policies, and organization-wide reports are generated through the Resource Groups Tagging API. Organization-wide compliance reports can only be generated from the us-east-1 region using management account credentials. Per-account reports can be pulled from the account itself. The report surfaces which resources have tags that don't match the effective tag policy for that account.

Q: Can backup policies back up resources in all regions?

A backup policy specifies which regions it applies to in the regions element. Resources outside the listed regions won't be covered by that policy. If you want organization-wide backup coverage, you'll need to include all active regions explicitly in the policy or manage regional coverage across layered policies at different OU levels.

Q: Are tag policies and backup policies free to use?

Enabling and attaching tag policies has no additional cost. Backup policies are also free to configure, but the backups themselves are billed through AWS Backup at standard rates for storage and data transfer.

Q: Can I use tag policies to govern which tags are applied to backup policies themselves?

No. Tag policies govern tags on AWS resources like EC2 instances, RDS databases, S3 buckets, and Lambda functions. Organizations policy objects like SCPs, tag policies, and backup policies aren't taggable resources in that sense. Metadata about your policy objects is managed through naming conventions and descriptions, not through tag policies.

Related Concepts

AWS IAM Permission Boundaries Explained. Permission boundaries are an IAM-level construct that cap the maximum permissions a role or user can have. Where SCPs operate at the account level, permission boundaries operate at the principal level within an account.

Permission Boundary vs. IAM Policy. Understanding when to use a permission boundary versus an inline or managed policy is a common decision point in IAM architecture. See Permission Boundary vs IAM Policy for the decision framework.

Service Control Policies (SCPs). SCPs are the authorization counterpart to the management policies covered here. They define the maximum permissions available to accounts in your organization and are the right tool for making required tags enforceable at resource creation time.

Cloud Security Controls. Tag and backup policies are two components of a broader cloud security control architecture. This article covers how the full set of control types maps to major compliance frameworks.

Cloud Security Guardrails. Guardrails are the architectural controls that make unsafe configurations structurally impossible. Tag policies and backup policies contribute to a guardrail model when combined with SCPs and network-level controls.