Skip to main content

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.

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.

Prerequisites for Both​

For any resource encrypted with a customer-managed KMS key (not an AWS managed key), that key's resource policy must allow the local backup operator role (default ntc-local-backup-operator-role) to use it:

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

Fully Managed​

AWS Backup re-encrypts the recovery point using the backup vault's own KMS key. No additional cross-account KMS access is required beyond the statement above.

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, not just the local backup operator role.

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

{
  "Sid": "AllowCentralBackupAccountToUseKey",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::<central-backup-account-id>:root" },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey",
    "kms:GenerateDataKey",
    "kms:ListKeys",
    "kms:ListAliases",
    "kms:CreateGrant",
    "kms:ListGrants",
    "kms:RevokeGrant"
  ],
  "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.