Centralizing Backups in AWS Control Tower: A Practical Guide for Engineers

If you’ve ever tried to manage backups across multiple AWS accounts, you’ll probably know how quickly it can turn into a mess of IAM roles, custom scripts, and the classic “wait, which account has the latest copy?” questions.

That’s where AWS Backup comes into play, helping you to centralize your backups in your AWS accounts. But AWS Backup shines especially when combining it with AWS Organizations, and even more when enrolled through its AWS Control Tower integration. This takes away a lot of the operational overhead by giving you a governed, organization-wide backup setup out of the box. In this post, we’ll look at how to enable it, what to watch out for, and what the trade-offs are.

How AWS Backup Works with Control Tower

With AWS Control Tower you can enable AWS Backup as a managed service across your entire AWS Organization through your Landing Zone configuration. This setup provides a centralized way to manage backups, ensuring that all accounts within your organization adhere to consistent backup policies and practices, reducing the chances of misconfiguration.

Basic Architecture

A Diagram showing the basic AWS Backup architecture enrolled with Control Tower

When you enable AWS Backup through Control Tower, it provisions a standardized backup architecture across your organization. This setup includes:

• A central backup storage account, which hosts the vaults where recovery points are stored.
• A central backup admin account, which is used for reporting and acts as the delegated administrator for AWS Backup in your Organization.
• Local backup vaults in each governed Region, along with a central backup vault for safekeeping and long-time storage.
• Predefined backup plans that use resource tags to trigger backups automatically.
• From that point on, instead of managing backup jobs per account, you get central control and consistent governance across your Organization.

The predefined backup plans cover common use cases, but you can also create custom plans if needed, i.e. by using an Organization Backup Policy.

How Backing Up Works

1. Depending on the deployed backup plans (predefined or custom), AWS recognizes selected resources in your member accounts based on their tags or a specific resource selection. AWS Backup automatically creates recovery points and stores them in the local vaults. The recovery points are encrypted using a customer managed central KMS key, which you define when enabling the backup feature in Control Tower. AWS Backup uses a predefined IAM role in each member account to access the resources and create backups, as well as to copy them to the central vault.

2. If a copy action is defined in a backup plan, AWS Backup copies the recovery points from the local vaults to, i.e. the central vault in the backup storage account. This provides an additional layer of protection and helps meet compliance requirements. The copied recovery points are encrypted using a customer managed central KMS key, as well.

3. Depending on your backup plan, retention periods are applied to both local and central vaults. After the retention period expires, recovery points are automatically deleted.

How Restoring Works

Restoring resources is done through the AWS Backup console. You can choose to restore from either the local vault or the central vault, depending on your needs and the availability of your recovery points due to the defined retention period.

• If restoring from a local vault: You can select the desired recovery point and initiate the restore process to this account by clicking on Restore. AWS Backup uses the predefined IAM role in the member account to access the resources and perform the restore, or you can choose a custom role.
• If restoring from a central vault: You first need to copy the recovery point back to the original account. This is done through the AWS Backup console by selecting the recovery point in the central vault and choosing the option Copy. It starts an on-demand copy job to a local vault of a member account. Be aware that the copy action may not offer cross-account and cross-region copy at the same time.

In case of a copy job fail, be sure to check the vault policy of your local backup vault. It needs to allow the backup storage account to write recovery points to it. You can find more information on vault policies in the AWS Backup documentation. Usually, Control Tower sets this up for you, but if you have modified the vault policy, it might cause issues.

Setting It Up

Prerequisites

Before you can enable AWS Backup, you’ll need AWS Control Tower and its Landing Zone in place. In addition, you’ll need two AWS accounts in your Organization that are not yet enrolled in Control Tower: one to later act as the backup admin account, and another as the backup storage account.

Preparing Encryption Keys

Encryption is another important piece of the puzzle. AWS Backup in Control Tower expects a multi-Region customer managed KMS key for the central vaults. This key (and its replicas) needs to be deployed before you switch on the backup feature.
You need to deploy the key in the Management Account and replicate it to each governed region for which AWS Control Tower is enrolled.

To create the multi-region key with CDK, you can use the following code snippet in your Infrastructure as Code setup. This snippet utilizes a custom resource to read the SSM parameter from another region, as CDK does not support cross-region stack references.

KMS Key and Key Policy Creation with CDK

💡 Be aware to use the key policy as suggested in the AWS Backup for Control Tower documentation to prevent permission issues.

// SSM parameter name for the primary encryption key ARN
const primaryKeyArnSSMParameterName =
  '/central-backup/encryption-key-arn-for-replication';

const createPolicy = (stack: cdk.Stack, orgId: string): iam.PolicyDocument => {
  return new iam.PolicyDocument({
    statements: [
      new iam.PolicyStatement({
        sid: 'EnableIAMUserPermissions',
        effect: iam.Effect.ALLOW,
        principals: [new iam.AccountRootPrincipal()],
        actions: ['kms:*'],
        resources: ['*'],
      }),
      new iam.PolicyStatement({
        sid: 'AllowOrgAccountsToUseKey',
        effect: iam.Effect.ALLOW,
        principals: [new iam.AnyPrincipal()],
        actions: [
          'kms:Decrypt',
          'kms:DescribeKey',
          'kms:GenerateDataKey*',
          'kms:Encrypt',
          'kms:ReEncrypt*',
          'kms:GetKeyPolicy',
          'kms:CreateGrant',
          'kms:ListGrants',
          'kms:RevokeGrant',
        ],
        resources: ['*'],
        conditions: {
          StringEquals: {
            'aws:PrincipalOrgID': orgId,
          },
        },
      }),
    ],
  });
};

export class CentralBackupEncryptionKeyStack extends cdk.Stack {
  public readonly primaryKeyArn: string;

  constructor(
    scope: Construct,
    id: string,
    props: CentralBackupEncryptionKeyStackProps,
  ) {
    super(scope, id, props);

    const primaryKey = new kms.Key(this, 'KmsPrimaryKeyArn', {
      policy: createPolicy(this, props.orgId),
      description: 'Encryption Key for central backup vault',
      enableKeyRotation: true,
      multiRegion: true,
      removalPolicy: cdk.RemovalPolicy.RETAIN,
    });
    primaryKey.addAlias(props.kmsKeyAliasName);

    this.primaryKeyArn = primaryKey.keyArn;

    // CDK aren't allowing to pass Stack Outputs (here: kms key arn) across regions, so we use SSM Parameter Store to share the primary key ARN.
    // The primary key ARN will be retrieved in the replica stacks.
    new ssm.StringParameter(this, 'SsmPrimaryKeyArn', {
      parameterName: primaryKeyArnSSMParameterName,
      description: 'The primary key ARN to be replicated',
      stringValue: primaryKey.keyArn,
    });

    new CfnOutput(this, 'PrimaryKeyArnOutput', {
      value: primaryKey.keyArn,
      description:
        'The ARN of the primary KMS key for the central backup vault',
      exportName: 'PrimaryKeyArn',
    });
  }
}

interface CentralBackupReplicaKeyStackProps extends cdk.StackProps {
  kmsKeyAliasName: string;
  primaryKeyRegion: string;
  orgId: string;
}

export class CentralBackupReplicaKeyStack extends cdk.Stack {
  constructor(
    scope: Construct,
    id: string,
    props: CentralBackupReplicaKeyStackProps,
  ) {
    super(scope, id, props);

    const primaryKeyArnSSMReader = new SSMParameterReader(
      this,
      'PrimaryKeyArnSSMReader',
      {
        parameterName: primaryKeyArnSSMParameterName,
        region: props.primaryKeyRegion,
      },
    );

    const primaryKeyArn = primaryKeyArnSSMReader.getParameterValue();

    const replicaKey = new kms.CfnReplicaKey(this, 'KmsReplicaKey', {
      primaryKeyArn,
      keyPolicy: createPolicy(this, props.orgId),
    });

    new kms.CfnAlias(this, 'CentralBackupVaultKeyAlias', {
      aliasName: props.kmsKeyAliasName,
      targetKeyId: replicaKey.attrKeyId,
    });
  }
}

In order to provide a multi-region retrieval of the primary key ARN, we use a custom resource to read the SSM parameter from another region. Here’s the code for the SSMParameterReader class:

interface SSMParameterReaderProps {
  parameterName: string;
  region: string;
}

// Custom resource to read SSM Parameter Store values across regions
export class SSMParameterReader extends cr.AwsCustomResource {
  constructor(scope: Construct, name: string, props: SSMParameterReaderProps) {
    const { parameterName, region } = props;

    const ssmAwsSdkCall: cr.AwsSdkCall = {
      service: 'SSM',
      action: 'getParameter',
      parameters: {
        Name: parameterName,
      },
      region,
      physicalResourceId: { id: Date.now().toString() }, // Update physical id to always fetch the latest version
    };

    super(scope, name, {
      onUpdate: ssmAwsSdkCall,
      policy: {
        statements: [
          new iam.PolicyStatement({
            resources: ['*'],
            actions: ['ssm:GetParameter'],
            effect: iam.Effect.ALLOW,
          }),
        ],
      },
    });
  }

  public getParameterValue(): string {
    return this.getResponseField('Parameter.Value').toString();
  }
}

The code snippets were adapted from Benoit Paul’s amazing blog post on creating multi-region KMS keys with CDK.

How To Deploy the Keys

To deploy the keys, you’ll need to run two separate stacks in the Management Account: one for the primary key, and one in each governed region for the replica keys.

const orgId = 'o-XXXYYYZZZZ'; // Replace with your organization ID
const managementAccountId = '111222333444'; // Replace with your management account ID

// Replace with home region of Control Tower
const homeRegion = 'eu-central-1';
// Replace with governed regions in Control Tower
const replicaKeyRegions = [
  'eu-west-1',
  'us-east-1',
  'eu-west-3',
];

const kmsKeyAliasName = 'alias/central-backup-vault-key';

const app = new cdk.App();

// Need to be deployed with management account credentials
new CentralBackupEncryptionKeyStack(app, 'CentralBackupEncryptionKeyStack', {
  env: {
    account: managementAccountId,
    region: homeRegion,
  },
  orgId,
  kmsKeyAliasName,
});

replicaKeyRegions.map((region) => {
  new CentralBackupReplicaKeyStack(
    app,
    `CentralBackupReplicaKeyStack-${region}`,
    {
      env: {
        account: managementAccountId, // Replace with your management account ID
        region: region,
      },
      primaryKeyRegion: homeRegion,
      orgId,
      kmsKeyAliasName,
    },
  );
});

Enabling AWS Backup in Control Tower

Once the keys are deployed, enabling AWS Backup is ready to be done through the Control Tower console.

You need to do the following steps:

• In the AWS Control Tower Console, navigating to Landing Zone settings
• Select Edit and walk through the configuration to enabling AWS Backup.
• You’ll be prompted to select an account for central backup administration and central backup storage and the KMS Key. Select the respective accounts and the multi-region KMS deployed earlier.

Behind the scenes, Control Tower will set up vaults, IAM roles, and backup plans. The process usually takes up to an hour. Finally, you can start to enable AWS Backup at the OU level.

Enabling Backup for Organizational Units

• From the Organization settings page from Control Tower, you select the OUs for that you want to enable AWS Backup.
• Scroll down to the AWS Backup section and click on Enable AWS Backup on OU.

There you go! 🎉 Now the Backup Baseline will be rolled out by Control Tower to all accounts in the selected OU, and you can start tagging resources to include them in the backup plans.

Troubleshooting

We encountered some issues during the setup of AWS Backup with Control Tower. The following steps can help you troubleshoot common problems:

Control Tower can’t roll out AWS Backup:

• Key or Policy Permission Issue: Ensure that the KMS key created in step 1 is correctly configured and has the necessary permissions for AWS Backup. (Reference)

AWS Backup cannot be enabled for the OU:

• Check the StackSet and StackSet instances of AWSControlTowerLocalBackup in the Management account for any errors.
• Check Cloud Trail events and logs for any issue related to the AWS Backup service, vault creation or other parts related to the Control Tower AWS Backup setup.
• Errors can occur due to a missing permission for a governed region.
• Re-Registering the OU can sometimes help according to the documentation under “Considerations” (Reference).

Backup Plans in Practice

Control Tower comes with four predefined tag-based backup plans. They cover the typical frequencies most teams need:

• Hourly backups with two weeks of retention (local only), uses the tag aws-control-tower-backuphourly=true.

• Daily backups with two weeks local retention and one month central retention, uses the tag aws-control-tower-backupdaily=true.

• Weekly backups with one month local retention and three months central retention, uses the tag aws-control-tower-backupweekly=true.

• Monthly backups with three months retention in both local and central vaults, uses the tag aws-control-tower-backupmonthly=true.

To include a resource, you just tag connected to the backup plan you want to implement.

If you need something more tailored, you can still define custom plans directly in AWS Backup or roll them out with AWS Organizations’ backup policies. This flexibility means you can start quickly with the defaults and refine later as your needs mature.

What to Watch Out For

There are a few caveats you should be aware of before flipping the switch:

• KMS permissions are critical. The number one reason the setup, or backup and copy jobs fail is a missing permission in one of the KMS keys. Especially, look out for having the right permissions in the member’s account KMS keys for encrypting the data of your resources to be backed up. You can find more on the required permissions to share KMS keys in How to share KMS keys using the example of EBS.

• Service coverage varies. Not all AWS services support AWS Backup, and those that do sometimes have different feature sets. For example, RDS and DynamoDB support point-in-time recovery, but not every service does. Always check the latest Feature Support List in the AWS Backup documentation.

• Restores aren’t always straightforward. To restore across accounts or Regions, you first need to copy the recovery point back to the original account or region. There’s no direct cross-account or cross-region restore option.

• Customization is limited. Control Tower gives you one central vault per Region and one central KMS key. If you need multiple vaults for separation of duties, you’ll have to build a custom approach, i.e. by using StackSets to roll out your customized AWS Backup configurations including vaults, IAM roles etc.

The Upside

For many organizations, the trade-offs are worth it. You get centralized governance without custom scripting, consistent encryption with one managed key, and ready-to-use backup plans that cover most compliance needs. Operationally, it’s far less work than stitching together backups across dozens of accounts. And from an audit perspective, having one place to track backup activity is a major win.

Lessons Learned

From real projects, a few best practices stand out:

• Test restores regularly. AWS Backup doesn’t do this for you, and a backup you can’t restore isn’t much use. You can utilize AWS Backup’s restore testing.

• Plan retention with both speed and cost in mind. Keeping a few days’ worth of local backups makes restores faster, while central vault copies serve as longer-term safe points. We recommend at least 5 days to a week of retention for your local backup vault, and a month of retention for the central backup vault for critical data.

• Follow the 3-2-1 rule where possible. Three copies, two mediums, one offsite. Control Tower gives you at least two; you can add a third with multi-Region copies.

• Strongly consider feature availability by service when working with AWS Backup for your backup strategy. Some services behave differently, e.g. backing up RDS Multi-AZ clusters for which cross-account or cross-region copy in not possible.

• Use the recommended KMS Key policy for the central backup key when enrolling AWS Backup with CT to prevent permission issues.

Final Thoughts

AWS Backup with Control Tower won’t fit every edge case, but it’s a strong foundation for centralized backups. If you already use Control Tower to govern your AWS Organization, enabling backups is a logical next step. Just make sure you’ve thought through your KMS design, your Backup Strategy, testing your restores regularly, and adjusting your backup plans to match your workloads.

With this guide, you should be well on your way to mastering AWS Backup with Control Tower and spend less time firefighting backup scripts — and more time building!

Resources For Further Reading

If you have any questions, want to share your experiences or need professional support for your Central Backup Strategy in AWS, don’t hesitate to get in touch with us!

Nora is a superluminar alumni and an AWS DevTools Hero. You can find Nora on LinkedIn and Instagram. She organises several events for the AWS Community and Women in Tech Community.