Skip to main content

Cross-Account, Cross-Region Backups in AWS

A good backup is essential for any company, whether it’s a small startup or a large thriving corporation. Data loss is frequent, and is not always a result of malicious attackers. 90% of data breaches involve human factors. Data loss is a huge deal and may lead to downtimes, which according to a report from 2016, cost of downtime is $9,000 per minute.

Well timed backups (among other things) can help with disaster recovery. It can save you a lot of headaches and sleepless nights, allowing you and your organization to mitigate the damage as much as possible and swiftly get back to business. It’s well worth investing in a Backup Service for your business.

“You can never have too many backups” is a phrase that you’ll hear quite often in the tech industry, it outlines the importance of having backups. However, all things considered, there are a lot of nuances one needs to consider when creating backups, from the amount of backups to the time of the backups, storage of all the backups, managing backup versions etc.
First, let’s look at the properties of what a “Good” backup is. This will help us get a good understanding of the different nuances mentioned and how we could go on about implementing them.

Good Backups

Generally speaking a good backup should cover some of the following cases.

  • Backups should be cheap. It is essential to have your backups take as little of your financial resources as possible. This includes the storage, the process of backing up, the process of recovery etc.
  • A good backup should be reliable. It shouldn’t be ephemeral, it should be long-lived. If I backup a file now, I want it to be accessible ages later in the same shape as I stored it.
  • Backups should be secure. Your backup data is as important as your current workload data. There is no reason your backup should be lacking in the security.
  • A good Recovery Time Objective (RTO) & Recovery Point Objective (RPO) should be considered when backing up your data. A small RTO & RPO window usually means high cost, similarly a large RTO & RPO window means more damage during the downtime. There needs to be a balance between the two.
  • Additionally, a good backup needs to be highly available. This is done by usually storing the backup offsite; something that has been popularized by the 321 Backup Strategy.

These are some of the properties of what a good and meaningful backup is. Well the next question becomes; how does one create backups? Enter the world of Backup as a Service (BaaS). Backup Services allow you to easily handle all of your data backups on the cloud. High-quality backup services offer the option to store multiple backup copies in various locations, ensuring Highly Available Backups. One such backup service, provided by AWS, mainly for AWS services, is the AWS Backup Service.

AWS Backup

AWS Backup Service provides easy access to backups in AWS. Instead of backing up data service-to-service, AWS Backup provides a centralized place to manage all of your backups. AWS Backup Service also provides some nifty features like tag based backups, policy-based backups, lifecycle management and cross account backups, which we’ll get into later. For now, let’s discuss the other features AWS Backup Service provides.

Centralized Backup Management

As mentioned above, instead of creating backup, service-to-service, AWS Backup provides a centralized dashboard to handle all of your backups. All of this is done using Backup Policies. This dashboard also provides a history of all the backups and backup related activity logs.

Policy Based Backups

At the heart of AWS Backup lies its Backup Policies, known as backup plans. Enabling the user to define their own backup requirements that meet the specific business and regulatory compliance requirements. Multiple backup plans can be created to further optimize your RTO and make sure you have the latest backups available.

Lifecycle management policies

Much like S3’s lifecycle management policies, AWS Backup also provides lifecycle policies for your backups to keep the costs down, automating the process of transitioning the backups from warm storage to cold storage and expiring old backups.

Cross-Region & Cross-Account Backups

A major advantage of using AWS Backup is having the ability to centralize your backups in one or more dedicated accounts. AWS Backup provides the ability to not only backup into another account, but also copy the backups in a region different from your current workload region. This ensures that your backups are highly available, and are readily available to be deployed into another region if your current workload region goes down for some reason.

Creating a Cross-Account Cross-Region Backup System

Let’s implement what we’ve learned. We’ll build a Backup System inside AWS that will backup the resources in your workload account and copy it over to another AWS Account in the same Organization.

Some prerequisites before diving into the actual solution:

  • You need to have an AWS organization setup, where you have a dedicated workload account and a backup account. To learn more about AWS Organizations, click here.
  • For encryption, KMS Keys don’t support copying backups to other accounts. Therefore we’ll be using CMKs instead.
  • RDS, Aurora, DocumentDB, and Neptune don’t support cross-account & cross-region copy in a single go. Instead, AWS documentation suggests you use a lambda to copy from Workload Account to the Backup Account in the same region. Then copy the backups to the final destination region. Here’s a blog explaining it in detail.
  • Create the AWSBackupDefaultServiceRole using the steps in this link.
  • Enable the Cross Account Backup from the Backup Settings.

Prepping the Encryption keys

Let’s create CMKs in order to encrypt the backed up resources, known as recovery points in AWS Backup. A standard AWS CMK will do fine, just make sure that the AWS Backup service can use the CMK as well. Your CMK policy should look like the following. You can further fine tune this policy to conform to POLP (Principle of Least Privilege).

Backup Vaults & Backup Policies

Backup Account

In the Backup Account, create a Backup Vault encrypted with the CMK you created, in a region other than where your workload services belong to. I’ll be using Ireland (eu-west-1). Don’t forget to copy the ARN of the Vault.

A note on cost optimization: You can optimize your costs here by seeing which region costs the least in terms of backing up, restoring and also cross region data transfer.

DestinationBackupVault; the vault which will house all of our workload backups

For the Access Policy, add a new permission to “Allow access to a Backup vault from organization”.

Access Policy for the Backup Vault

Workload Account

Backup Vault

In the Workload Account, create a backup vault encrypted with the CMK you just created, in the region where your workload services reside. For me, it’s Frankfurt (eu-central-1).

WorkloadBackupVault; the vault from where all of our backups will be copied cross account

Backup Policies

Now let’s create some backup policies which will instruct AWS Backup to backup specified resources to the Backup Account.

Navigate to Backup Plans and create a new Backup Plan. In the Backup Rule Configuration section, for the Copy to Destination, select the region you want your backups to end up in- in the backup account. Copy and paste the ARN of the Backup Vault you created in the Backup Account. Create the plan.

Backup Rule Configuration

For the Resource Assignment, select the Default Role. Select the specific types of resources you want to backup. I’ll be backing up EBS volumes tagged Backup: True for this example. You can use any supported service for this such as a Dynamodb table for data migration across AWS accounts, an RDS Aurora cluster or even an S3 bucket. Note: As of now RDS, Aurora, DocumentDB, and Neptune do not support a single copy action that performs both cross-Region AND cross-account backup. You can choose one or the other. You can also use a AWS Lambda script to listen for the completion of your first copy, perform your second copy, then delete the first copy.

Resource Selection Settings for EBS

Resulting Backup Plan

Now that we have everything in place, all that’s left to do is wait for the Backup Job to run and backup your resources.


In the Jobs tab, you can see the job’s status.

Wait for a few minutes and the Copy Job should start copying the created Backup Recovery point to the destination vault.

You can verify that the copy job succeeded by looking at the backup vault in the backup account. You should see a new recovery point with the Source Account ID of your Workload Account.

You can now restore this snapshot in the backup account. Or as the intended purpose, copy it back to the workload account, either to the same region or another region and start using it again.

Where to go next

Now that you have learned what AWS Backup is and how we can offload our backups to another AWS account, the next step is to optimize the entire process. You could start by optimizing your RPOs & RTOs, find that sweet spot where you minimize the downtime while also not spending too much financial resources. You can even expand this knowledge to create a Hub-Spoke for the Backups; one workload account sending backups to multiple backup accounts.


About The Author(s)


Related Articles

Related Articles