Expand your AWS backup

‍

‍

AWS Backup is a very convenient service that allows customers to manage backups for RDS snapshots, EBS and EFS volumes, and DynamoDB tables in a unified tool. There is not even any setup required, apart from defining your intended backup plans.

The article shows how to use AWS Backup for heavy-duty tasks and extend it to offsite functions.

The basis is a backup that must meet various requirements and purposes in relation to backups, e.g:

1. ad hoc backups before potentially dangerous operations (e.g. major upgrades) - easy to implement with an on-demand backup

2. frequent and short-term backups to minimize losses in daily operation

3. long-lasting backups (often even required by law, depending on the industry with fixed retention periods)

4. offsite backups to decouple risks between source systems and backups

Most of these goals can be achieved directly with AWS Backup, but some requirements may need additional support.

Creating the basis for external data backup

To get started, all you have to do is create a backup plan and assign resources to it. The backup plan defines how a backup is to be carried out, how often and in which time window. You can also specify when the backups should expire. With this lifecycle management, you can directly address the second and third requirements mentioned above. One schedule can be used to trigger daily backups and run them quite quickly. A second plan can be used to create a monthly backup that can be kept for several years. Both plans can and should be used together.

Example of a 5-year storage plan

Which plans are executed is expressed by assignments. For test and PoC purposes, you can manually add a resource to a plan. In all other environments, this will not be sufficient. Instead, AWS Backup can assign resources to plans using tags, which is much easier and safer to implement at scale. For example, if your backup requirements dictate that production database backups must be retained for at least five years, you would create a plan that expires DB backups after five years and create an assignment that maps all RDS and EC2 instances to that plan, tagged with "key: environment, value: production". This assignment does not have to be exclusive to one plan. You can copy this assignment to another backup plan that could perform the frequent and ephemeral backups in parallel.

Declarative resource allocation

Handling external backups is more difficult and can have some very specific requirements. Since January 2020, AWS Backup offers the ability to copy backups to different regions. To enable this, simply select a target region in your backup plans. This feature has been missing for a long time and is extremely useful to create an off-site backup. Having all relevant data in another region allows for much faster recovery in the event of a total failure of your main region. Simply restore your database to your standby region and redirect your traffic. However, stating that it is a remote backup is not the whole truth. Although it creates independence in terms of location, it does not decouple the backup from the source account. Backups can be protected with vault policies - but if the (root) account is compromised, a backup at another location could also be at risk.

Saving backups to additional storage locations

Unfortunately, there is still no way to share a backup with another account. But that won't stop us from doing it anyway.

Going beyond backup functions

(To understand the following section: A segregated account is an account that can access your relevant accounts but cannot be interacted with in the other direction. Think of your IT security department or a contracted auditing firm. An admin user of a source account should never be able to interact with the segregated account to create this separation).

Using RDS as an example, we will explain the steps required to add the ability to export snapshots to a separate account to your backup. Normally, you cannot interact with snapshots in AWS Backup directly. They can only be restored to a database instance, where you can then manually run an export or dump job. However, they are visible in the RDS console as regular snapshots for some time after creation. If we work with a regular snapshot at this point, we can use all the functions and integrations of RDS directly.

First, we need to set up a trigger that responds to RDS snapshot events by calling a Lambda function. This can be done with either RDS Event Notifications or Cloudwatch Event Rules. We have found the latter to be easier to handle in automation, but the former to be more human-friendly.

To be able to export these snapshots, we need to make some preparations.

First, we need to set up two KMS encryption keys, one for export and one for import. There are several reasons for this:

   1. you cannot release an encrypted snapshot that uses the RDS standard key.

   2. the use of a separate key for the export makes it possible to define the required authorizations much more narrowly (especially important when granting access to other accounts)

   3. the disconnected account should specify an import key to enable and secure access independent of the source key after the snapshot has been imported.

Secondly, we need suitable access rights. One function enables a lean definition of permissions for RDS snapshots as well as for the KMS key. We use the recovery point tagging function to tag all backup snapshots with a specific tag.

Mark all backups with a specific encryption key ID.

Since all backup snapshots are automatically tagged with this key-value pair, we can restrict the permissions to modify, share, copy and clean up snapshots to those with exactly these tags. An example of an IAM authorization statement could look like this:

‍