Skip to main content

Backup Policies

This page covers the three mechanics behind every backup_definitions entry: how its policy gets attached to accounts, how it decides which resources are backed up, and where the resulting recovery points end up.

What Are Backup Policies?​

Backup policies are an AWS Organizations policy type (BACKUP_POLICY), the same mechanism behind Service Control Policies and Tag Policies. A backup policy is a JSON document that centrally defines one or more AWS Backup plans, schedule, lifecycle/retention rules, and resource-selection criteria, and attaches them to an OU or account. Once attached, AWS Backup in every affected account creates and runs the plan(s) the policy defines automatically. No one has to touch that account's own AWS Backup configuration.

Backup policies solve the same governance problem for backups that SCPs solve for permissions and tag policies solve for tagging: enforce a baseline centrally so it can't be skipped or forgotten at the account level. Typical use cases:

  • Guaranteeing every account in an OU like /root/workloads runs a minimum backup plan, whether or not the account owner ever configures AWS Backup themselves
  • Applying different retention and resource-selection rules per environment, for example a stricter plan for production than for sandbox, by attaching different policies to different OUs
  • Extending backup coverage to new accounts automatically the moment they land in a governed OU, since the policy is inherited rather than something each account opts into

How backup_definitions Relates to Backup Policies​

Each backup_definitions[] entry is NTC Backup's Terraform-native abstraction over exactly one backup policy. The module compiles an entry's resource types, cron schedule, retention settings, and tag-based selection rules into the underlying BACKUP_POLICY JSON, creates it as an aws_organizations_policy, and attaches it to that entry's own backup_target_ou_path_ids / backup_target_account_ids.

In other words: backup_definitions is the input you write, one list entry per central vault; the backup policy is the AWS Organizations artifact NTC Backup generates and manages for you as a result. You never author the BACKUP_POLICY JSON by hand, everything you set on an entry (resource types, schedule, retention, selection tags) is exactly what ends up in that entry's generated policy. This one-to-one mapping is also why entries stay isolated from each other: because each is its own policy document, one entry's configuration can never leak into another entry's accounts, even when their targets overlap, as covered next.

Backup Policy Attachment​

Each backup_definitions[] entry gets its own AWS Organizations BACKUP_POLICY document, containing only that entry's own plan(s) - it's attached only to that entry's own backup_target_ou_path_ids / backup_target_account_ids, never to any other entry's targets. AWS Organizations backup policies are inherited: attaching to an OU applies to every account nested anywhere beneath it (child OUs included), not just accounts directly in that OU.

If more than one entry's plan(s) end up applying to the same account (their targets overlap), AWS merges all of them into that account's one effective policy - every applicable entry's plan(s) get evaluated there. The Resource Selection Logic below then decides, per resource, which one (if any) actually captures it - which is exactly why entries with overlapping targets need distinct tag_key_to_enable_backup values, per the backup_definitions description.

Resource Selection Logic​

How each backup_definitions[] entry decides whether a resource is backed up at all, and whether it's also copied to the central vault - once its plan(s) already apply to the resource's account, per the attachment logic above. Only applies while tag_based_selection_enabled = true - when it's false, every resource matching resource_types goes unconditionally to whichever plan default_backup_scope picks, and the tags below are ignored entirely.

Defaults: tag_key_to_enable_backup = "ntc:backup", tag_key_to_define_backup_scope = "ntc:backup-scope", default_backup_scope = "local-and-central".

Copy Flow​

Once a resource lands in the local-and-central plan (per the Resource Selection Logic above), where does the actual data go. One backup job in the member account creates a single local recovery point, then copies that same recovery point directly to every target vault in one step - not a relay through one central vault to another.

The copy is authorized by the member account's own member_account_backup_role_name role. Each vault's access policy and KMS key trust that entry's own backup_target_ou_path_ids / backup_target_account_ids / member_account_backup_role_name, plus the same from every other entry that names it in copy_to_backup_definition_by_name - naming a fan-out target automatically extends that target's trust to cover the source entry's accounts too, so no manual duplication is needed on the destination side.