Backup Events

• Automatically:

  • Copy AWS Backup backups to a different account ("Central Backup" if you use Control Tower or follow multi-account best practices).

  • Delete original backups after copying -- but wait to save money with incremental backups.

  • Copy backups to a second region, whether for compliance, disaster recovery preparedness, or just peace-of-mind.

• Get started quickly, or customize.

  • Try the sample backup vaults, or "bring your own vaults" (BYOV).

  • Try the default aws/backup KMS key, which lets you experiment by backing up unencrypted EFS file systems -- or "bring your own key" (BYOK) to back up any resources that AWS Backup supports.

  • Create 3 CloudFormation stacks from 1 template for a minimum installation, or deploy across many accounts and regions with a StackSet.

Jump to: Quick Start • Minimum Account Layout • Multi-Account, Multi-Region Install • Security

---

Quick Start

1. Check prerequisites.

   If you have already used AWS Backup from the AWS Console, to make a backup in one AWS account (your "main account") and copy it to another AWS account ("your backup account"), you are ready to try the quick-start. Find your o- Organization ID in the lower left corner of the AWS Organizations console page.

   For complex environments, or if you are new to AWS Backup...

   Check that:

   • AWS Organizations is configured.
   • Every AWS account where you intend to install Backup Events is in your organization.
   • In the management account, under AWS Organizations → Services → AWS Backup, "Trusted access" is enabled.
   • Under AWS Organizations → Policies, "Service control policies" are enabled.
   • Under AWS Backup → My account → Settings → Cross-account management, all options are enabled, including "Cross-account monitoring" and "Cross-account backup".
   • Under "Service opt-in" (scroll up), EFS (for the quick-start) and any other relevant services are enabled.
   • In every AWS account where you intend to install Backup Events, the AWSBackupDefaultServiceRole exists. If you use the AWS Console, AWS Backup creates this role the first time you make an on-demand backup in a given AWS account. Otherwise, see Default service role for AWS Backup.
   • Permissions are sufficient and service and resource control policies (SCPs and RCPs), permissions boundaries, or session policies do not interfere with the installation or operation of Backup Events. Check with your AWS administrator!

2. Log in to the AWS Console as an administrator, in the AWS account where you would like your backups to be stored.

   • You will need to paste your backup account number several times. Open the menu at the top right corner of the AWS Console and copy the Account ID.

3. Switch to your main region, that is, the region where most of your resources (housed in a different account) are.

   • Your main region will double as the alternate for your backup region.

4. Create a CloudFormation stack "With new resources". Under "Specify template", select "Upload a template file", then select "Choose file" and navigate to a locally-saved copy of backup_events_aws.yaml [right-click to save as...]. On the next page, set:

   • Stack name - Copy and paste from "For Reference"
   • AWS Organization ID - From quick-start Step 1
   • Backup AWS account - From quick-start Step 2
   • Backup region - Specify a different region that you do not use much
   • Alternate for backup region - From quick-start Step 3
   • Days (from creation) to keep original backups - Note, but do not change this, for the quick-start. With incremental backups, aim to keep the previous one long enough for the next scheduled backup to complete.

5. Stay in the same AWS account but switch to your backup region.

6. Create a stack from the same template. Set exactly the same parameter values as in quick-start Step 4.

7. Note your backup account number before leaving (you will need it to create one more stack, but it will not be available to copy), then switch to your main AWS account.

8. Switch to your main region (from quick-start Step 3).

9. Create a stack from the same template. Set exactly the same parameter values as in quick-start Step 4.

10. Create a minimal EFS file system.

    • Give it a name that you will recognize.
    • Select "Customize".
    • Select One Zone.
    • Deselect "Enable automatic backups".
    • Change "Transition into Archive" to None.
    • Deselect "Enable encryption of data at rest" (important for this quick-start).
    • Change "Throughput mode" to Bursting.

11. When your file system is ready, go to AWS Backup → My account → Dashboard → Create on-demand backup.

    • Change "Resource type" to EFS and select your new file system.
    • Change "Total retention period" to 14 days.
    • Change "Backup vault" to BackupEvents-Sample (important).

12. Watch for completion of the backup job, and then creation and completion of a copy job. At that point, the original backup should show a "Retention period" of 8 days (instead of the initial 14 days).

    Switch to your backup AWS account and check for copies of your backup in the main region and the backup region.

13. In case of trouble, focus on the main region and check, in both accounts unless otherwise noted,

    • The BackupEvents CloudWatch log group(s)

    • The BackupEvents SQS queue (not in the backup account)

    • CloudTrail → Event history. Tips: Change "Read-only" to true to see more events. Select the gear icon at the right to add the "Error code" column.

14. Delete the EFS file system and all of its AWS Backup backups (or let the backups expire, at a small cost).

    • You will not be able to fully delete a Backup Events CloudFormation stack as long as backups remain in the stack's sample vault. This prevents the proliferation of unmanaged vaults.

Accounts and Regions

The region codes are examples. Choose the regions you use, noting some differences in AWS Backup Feature availability by Region.

Minimum Account Layout

Region→ Account ↓		Main	Backup
	Region code→ Account ID ↓	us-east-1	us-west-2
Main	000022224444	All resources
Backup	999977775555	All backups	All copies of backups

• There is nothing to install in the backup region of the only resource account, if you do not keep any resources there.

Typical Account Layout - Extra Region

Region→ Account ↓		USA East Coast	USA West Coast	Backup
	Region code→ Account ID ↓	us-east-1	us-west-1	us-west-2
Web server	000022224444	Resources	Resources
API layer	111133335555	Resources	Resources
Database	888866664444	Resources	Resources
Backup	999977775555	Backups from this region	Backups from this region	Copies of backups from other regions

• It would also be OK to keep resources in us-west-2. Second copies of any backups from the backup region go to an alternate that you configure, such as us-east-1.

Advanced Installation

Multi-Account, Multi-Region (CloudFormation StackSet)

1. Delete any standalone Backup Events CloudFormation stacks in the target AWS accounts and regions.

2. Complete the CloudFormation prerequisites for creating a StackSet with service-managed permissions.

3. Review the Backup Events prerequisites in Step 1 of the quick-start.

   • If the AWSBackupDefaultServiceRole is not present in every AWS account where you intend to install Backup Events, define and disseminate a custom role, perhaps by creating your own CloudFormation StackSet. (If you write a CloudFormation template, set RoleName for a consistent name.) The trust policy must allow "Principal": { "Service": "backup.amazonaws.com" } to to "sts:AssumeRole" . Attach the arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup AWS-managed IAM policy. Choose one region in which to deploy your role; roles are account-wide.

4. In the management account (or a delegated administrator account), create a CloudFormation StackSet. Under "Specify template", select "Upload a template file", then select "Choose file" and upload a locally-saved copy of backup_events_aws.yaml [right-click to save as...].

   • Set parameters as in Step 4 of the quick-start.
   • IAM role name for copying backups - Change if you defined and disseminated a custom role, above.

5. Deploy to your backup account and main/resource account(s), in your backup region and main/resource region(s) (including the alternate for your backup region).

Installation with Terraform

Terraform users are often willing to wrap a CloudFormation stack in HashiCorp Configuration Language, because AWS supplies tools in the form of CloudFormation templates. See aws_cloudformation_stack . Paul favors CloudFormation because all AWS users have access, the setup effort is minimal, and those with a support plan can get CloudFormation help from AWS.

Wrapping a CloudFormation StackSet in HCL is much easier than configuring and using Terraform to deploy and maintain identical resources in multiple AWS accounts and regions. See aws_cloudformation_stack_set .

Security

In accordance with the software license, nothing in this section creates a warranty, an indemnification, an assumption of liability, etc. Use this software at your own risk. You are encouraged to evaluate the source code.

Security details...

Security Design Goals

• Least-privilege roles for the AWS Lambda functions

  • The role for the function that reduces retention of original backups after they have been copied can access backups in any vault in the same AWS account and region. Tampering with the function's source code or environment variables would allow switching vaults. The backup AWS account acts as a security barrier; the function and its role are never created there. (Issue: backup or recoveryPoint ARNs, do not include the vault name, and there is no condition key such as backup:VaultARN.)

• Readable IAM policies, formatted as CloudFormation YAML rather than JSON, and broken down into discrete statements by service, resource or principal

• Tolerance for slow operations and clock drift in a distributed system

  • The function that reduces retention of original backups after they have been copied applies a full-day margin.

• Option to encrypt logs and queued event errors at rest, using the AWS Key Management System (KMS)

• Least-privilege SQS queue policy

• Option to use custom vaults (with custom KMS keys) and a custom role for AWS Backup

Security Steps You Can Take

• Prevent modification of the components, most of which are identified by BackupEvents in ARNs and in the automatic aws:cloudformation:stack-name tag.

• Prevent arbitrary invokation of the AWS Lambda functions. See comments in the CloudFormation template, including an observation about the limitations of Lambda's AddPermission operation.

• Prevent use of the function roles with arbitrary functions. See comments.

• Log infrastructure changes using AWS CloudTrail, and set up alerts.

• Instead of relying on sample vaults, on default aws/ KMS keys, and on the AWSBackupDefaultServiceRole , define custom equivalents with least-privilege resource- and/or identity-based policies tailored to your needs.

Advice

• Test Backup Events in your AWS environment. Please report bugs.

• You could base automated alerts on the information sources in Step 13 of the quick-start, but what really counts is the presence and restorability of final backups. Automated restoration testing and a backup policy with a flexible replacement algorithm (in case the backup from the first day of the month is unavailable, substitute the one from the second day, and so on, within a reasonable limit) is a better initial investment. AWS Backup restore testing looks promising!

• Set lifecycles in your backup plans, and when making on-demand backups, but specify 7 days minimum before backups are transitioned to cold storage / the "archive tier". Allow time for cross-account and cross-region copies to complete, and for original backups to be scheduled for deletion. If the original backup or the first copy enters cold storage too soon, you pay to store it for 90 days, and possibly to retrieve it for copying.

• Compare backup storage costs over time to assess the success of your NewDeleteAfterDays setting (which is applied to original backups, after they have been copied to your backup account), of incremental backups (if applicable), and of the lifecycles you choose when creating backups (which apply to the two copies in your backup account).

• Be aware of other AWS charges including but not limited to: data transfer, encryption/decryption, key management, and early deletion from cold storage. AWS Backup relies on other AWS services, each with their own charges.

Related

• (Code) Automate cross-account backups of RDS and Aurora databases with AWS Backup
  Enrique Ramirez, AWS Database Blog, October 14, 2021

• (Code) Introducing cross-account targets for EventBridge Event Buses
  Chris McPeek, AWS Compute Blog, January 21, 2025

Going Deeper

• AWS Backup and AWS CloudFormation
  AWS Backup Developer Guide

• What's New: KMS Multi-Region Keys
  June 16, 2021, AWS Security Blog, Jeremy Stieglitz, Ben Farley, and Peter Zieske

Motivation

What motivated this work? ...

Paul discovered the AWS Database blog post and sample code through a colleague, who had used it to back up a fleet of RDS databases with default KMS encryption. Thank you, Eugene, for always surveying the landscape first!

To back up a new Aurora database fleet, Paul wrote native Terraform and adopted the sample AWS Lambda function Python source code. Given the importance of the backups, Paul wrote least-privilege IAM policies for custom roles. He had already created customer-managed, multi-region, cross-account KMS keys for the new databases.

Later, he added a function to rewrite AWS Backup lifecycle objects, so that backups could be deleted after they had been copied. Paul does not remember what he put in that fuction, and he has moved on from the company, but he does remember wishing for a simpler, self-documenting function.

So, Paul decided to write a new solution from scratch, on his own behalf. The benefits?

• One CloudFormation template replaces AWS's three separate templates. Advanced users can create a StackSet for deployment at scale. Whether the current AWS account and region match the backup account and backup region determines backup source and target strings, and which resources to create.

• On-demand backups work, too. AWS's solution depends on a copy step available in backup plans but not on-demand backup requests.

• Advanced users can provide a multi-region KMS key. (For now, Paul is not publishing his test key definitions and key policies. The risk that an LLM will treat a general example as specific, and that the security of some important system will be compromised, is too great. If you need help with multi-region, cross-account KMS encryption keys, least-privilege IAM policies, etc., contact Paul!)

• Object-oriented Python code interprets backup job completed events and copy job completed events. A superclass covers the many similarities and a subclass, the few differences. The same primitives serve for copying a backup to a different account, reducing the original backup's retention, and copying the copy to a different region.

• The function to reduce retention of backups that have been copied is simple. Minimum retention periods under various rules are added to a list. At the end, the highest minimum is applied.

• From resource accounts, EventBridge directly invokes a Lambda function in the backup account. Cross-account invokation, introduced in January, 2025, eliminates a custom event bus. Paul goes further than the AWS Compute blog post and sample code, restricting permissions as much as possible.

Enjoy!

Licenses

Scope	Link	Included Copy
Source code files, and source code embedded in documentation files	GNU General Public License (GPL) 3.0	LICENSE-CODE.md
Documentation files (including this readme file)	GNU Free Documentation License (FDL) 1.3	LICENSE-DOC.md

Copyright Paul Marcelin

Contact: marcelin at cmu.edu (replace "at" with @)