Member Account Requirements

This page covers what individual member accounts need to adjust for their resources so backup actually succeeds, on top of the account-level setup. The prerequisite for everything below is the Guide to Configure NTC Backup.

For each resource that should be backed up, a member account has to:

1. Make sure the resource is opted in: its resource type is covered centrally, and its tags select it (see Resource Opt-In).
2. Grant access to its KMS key if the resource is encrypted with a customer-managed key (see CMK Access).

Resource Opt-In

A resource is only backed up when both of the following are true:

• Its resource type is listed in resource_types of a backup_definitions entry that applies to the account.
• Its tags select it for backup, unless tag-based selection is disabled for that entry.

Resource types and selection defaults are configured centrally in the backup account. A member account can't change them, it only controls the tags on its own resources. See Backup Policies for the full selection logic.

Resource Type

Check with your platform team which resource types the backup_definitions entry for your account covers. The reference configuration in the Guide to Configure NTC Backup uses:

resource_types = ["EC2", "EBS", "RDS", "Aurora", "Neptune", "DocumentDB", "DynamoDB", "EFS", "S3"]

If a resource type is missing from that list, tagging the resource has no effect. The type has to be added to resource_types in the backup account first.

Tags

With the default tag keys, a member account controls backup per resource through two tags:

Tag key	Values	Effect
ntc:backup	true / false	Whether the resource is backed up at all
ntc:backup-scope	local-only / local-and-central	Whether the recovery point stays in the local vault only, or is also copied to the central vault in the backup account

Use the values exactly as shown, in lowercase.

What happens to a resource without these tags depends on the central configuration of the entry:

• backup_enabled_if_untagged = false (default-deny, used in the reference configuration): the resource must be tagged ntc:backup = true, otherwise it isn't backed up.
• backup_enabled_if_untagged = true (default-allow): every resource of a listed type is backed up, unless it's tagged ntc:backup = false.
• Without an ntc:backup-scope tag, a backed-up resource follows default_backup_scope (local-and-central in the reference configuration).
• With tag_based_selection_enabled = false, all tags are ignored and every resource of a listed type is backed up with default_backup_scope.

The backup account can rename the tag keys per entry (tag_key_to_enable_backup, tag_key_to_define_backup_scope), for example when entries target overlapping accounts. Confirm the tag keys in use with your platform team.

Example of opting in an RDS instance with Terraform:

resource "aws_db_instance" "example" {
  # ...

  tags = {
    "ntc:backup"       = "true"
    "ntc:backup-scope" = "local-and-central"
  }
}

A newly tagged resource is picked up by the next scheduled backup run (cron_schedule of the entry), no further action is required in the member account.

CMK Access

AWS Backup treats resource types differently depending on whether they're fully managed or not fully managed, and that determines how a resource's recovery point ends up encrypted.

• Fully managed resource types: AWS Backup already re-encrypts the recovery point in the local backup vault with the local vault's own KMS key.
• Not fully managed resource types: the recovery point keeps the resource's original encryption. For cross-account copies, the entire central backup account needs access to that original CMK, because the native AWS service (running in the central backup account for the copy) performs the re-encryption itself, not AWS Backup.

The statements below only apply to resources encrypted with a customer-managed KMS key. AWS managed keys need no changes.

Fully Managed

AWS Backup re-encrypts the recovery point using the backup vault's own KMS key. The resource's CMK only has to allow the local backup operator role (default ntc-local-backup-operator-role) to read the data. No cross-account KMS access is required.

Add the following statement to the CMK in the member account:

{
  "Sid": "AllowLocalBackupOperatorRoleToUseKey",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::<current-account-id>:role/ntc-local-backup-operator-role"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

Resource types: EFS, S3, Timestream, VMware VMs, DynamoDB (AWS Backup advanced features must be enabled).

Not Fully Managed

The local backup vault keeps the resource's own encryption on the recovery point rather than re-encrypting it. Because the copy into the central vault is performed by AWS Backup's own service-linked role acting through the native service, the central backup account needs access to the CMK that encrypted the resource, in addition to the local backup operator role.

Add the following statements to the CMK in the member account:

[
  {
    "Sid": "AllowLocalBackupOperatorRoleToUseKey",
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::<current-account-id>:role/ntc-local-backup-operator-role"
    },
    "Action": [
      "kms:Decrypt",
      "kms:DescribeKey",
      "kms:GenerateDataKey*",
      "kms:CreateGrant"
    ],
    "Resource": "*"
  },
  {
    "Sid": "AllowCentralBackupAccountToUseKey",
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::<central-backup-account-id>:root" },
    "Action": [
      "kms:Decrypt",
      "kms:DescribeKey",
      "kms:GenerateDataKey",
      "kms:CreateGrant",
      "kms:ListGrants"
    ],
    "Resource": "*"
  }
]

The recovery point is only re-encrypted with the backup vault's own CMK at cross-account and cross-region copy time, not before.

Resource types: EC2/EBS, RDS, Aurora, FSx, DocumentDB, Neptune.

Only the resource types listed above (Fully Managed and Not Fully Managed combined) have been tested with NTC Backup. Other AWS Backup resource types, such as CloudFormation, Redshift, Redshift Serverless, Storage Gateway, SAP HANA on Amazon EC2, or EKS, haven't been validated yet, they may work, but the behavior isn't confirmed.

See Restore for how to bring a recovery point back, including the per-service restore behavior these encryption differences lead to.