So my last post on AWS Backup uses a lot of Terraform code that I had written even before the post. When doing a video on the subject, I realised that for a beginner, explaining something like AWS Backup with Terraform presents two fronts to understand at the same time.

So I’m following up with another video and a blog post that does the same demo but only using the AWS Web Console.

In this, I’m going to,

  1. create the vaults and the backup plans,
  2. monitor backup operations, using the web console

The encryption keys and the resources being used to backup data are already created. Details of creating KMS keys, DynamoDB tables, and RDS instances is out of scope of this aritcle.

Setup

I’m going to use two AWS accounts in the demo.

workload_a account has the resources that should be backed up, and backup will be the cross-account backup vault. If you’re unfamiliar with cross-account backup concepts, refer to my earlier blog post and the video on the subject.

I’ll set up AWS Backup in workload_a to backup resources to the vault in the same account, and then make a copy of the backup in the cross-account vault in the backup account.

There is a DynamoDB table called tracking in the workload_a account.

There is also an RDS instance called mydb in the same account.

Both of these resources are encrypted at rest with the same KMS key which has the following starting key policy.

Dividing your KMS keys along the data classification system you have is always a good idea. A single key is being used here for demo purposes only.

A separate KMS key is used to encrypt the Backup Vault contents.

A similar KMS key is present in the backup account which can be used to encrypt vaults in that account.

The following architecture is going to be implemented with this aritcle.

Creating Vaults and Backup Plans

With the above resources to be backed up with a cross-account backup strategy, let’s first create a Backup Vault in the workload_a account.

Creating the Vault

In the Backup Console, go to “Vaults” and click “Create new vault”.

Use the KMS key created for vault encryption in the dropdown list.

Creating the External Vault

Log in to the backup account, and follow the same steps to create a vault. This time however, a Backup Vault Policy should be attached to this vault to allow other Accounts in the same Organization to be able to copy snapshots into it.

After the policy is added, the vault is ready to be used.

The same policy has to be added to the source vaults if recovery points need to be copied across accounts. We’ll do this when we get back to the workload_a account.

After the vault is created, two information from this vault is needed for the Backup Plans to be successfully set up for cross-account backups.

  1. The Backup Vault ARN - since the vault is in another account, it doesn’t appear in a dropdown in the web console
  2. The Backup Service-linked Role URL - to provide it access to the KMS key used to encrypt the RDS instance (since Backup doesn’t handle encryption for snapshots for RDS - more details in the previous article), so that it would be able to decrypt the content before copying them over.

The ARN for the Backup Service-linked Role is available in the IAM console.

If this role cannot be found in IAM (which is highly unlikely if you’re following this in order), visit the AWS Backup Console in that account. Chances are, AWS Backup hasn’t been visited for this to be created yet.

Creating the Backup Plan

Then it’s time to create a Backup Plan so that the resources, the DynamoDB table, and the RDS instance, will be included in backup jobs.

These concepts are discussed in depth in the previous articles I wrote and the videos I did on the topic.

In the workload_a account, go to the Backup console, and select “Create backup plan” in “Backup Plans” section.

After giving a name for the plan, you can define one or more rules to be executed in the Backup plan (more details about what rules are in the previous article on the subject).

Define a schedule for the rule, and select the in-account vault in the workload_a account to associate the plan-rule.

Define the backup operation window.

You can configure additional details like Point-in-time-Recovery for resources that support it, and Cold Storage, but for this case, those features aren’t needed.

Configuring Cross-account Copying

Under “Copy to Destination” section, paste in the cross-account Backup vault ARN that was copied in the previous section. When you do this, Backup warns yuou that the source account does not have a policy that allows the destination vault to copy snapshots. This sounds counter-intuitive, when we are trying to copy from the source account to the destination account. However, Backup is warning us about tomorrow, the SHTF situation, where we’ll actually need to copy data from the destination vault to the source vault so that data recovery can be done. Resources can’t be recovered from recovery points in an external vault. They have to be in the same account for recovery to happen.

Click on the “Allow” button to add a policy that allows the backup account to copy data into this vault.

Click on “Create Plan” to continue.

Selecting Resources to be Included in the Plan

The next step is to include resources in this backup plan. Next screen provides the way to do this. For each resource, a new Resource Assignment can be created, but if the resources are tagged in an orderly manner, it could be same Resource Assignment. Additionally, the same Resource Assignment can define mutiple specific types of resources. AWS Backup plans are really flexible in this manner.

Resources Assignments can also be created, after a plan is fully created, by clicking on “Assign Resources” in the “Resource Assignments” section.

Give a name to the Resource Assignment and define the IAM role to be used when the resources are backed up. This IAM role should have decrypt permissions on the KMS keys used by the resources for encryption at rest, and encrypt permissions on the KMS key used by the in-account vault (the vault in the workload_a account. This can be the default role created by AWS, or it could be a custom role. In any case, the role should work if the AWSBackupServiceRolePolicyForBackup and AWSBackupServiceRolePolicyForRestores managed policies are attached.

Select “Include specific resource types” and select the DynamoDB table and the RDS instance.

Click on “Assign Resources” to complete this step.

Configuring KMS Key Permissions for Backup and Cross-Account Copying

There’s one more step to perform before a successful cross-account backup can be done.

First, how AWS Backup handles encryption and decryption of resource data differs from resource type to resource type. This was explained in detail in the previous articles on this topic, but in brief, DynamoDB encryption and decryption is managed by AWS Backup because it supports “Independant Encryption” where as RDS does not. Because of this, the KMS key policy for RDS data (which is the same key for DynamoDB in this case) needs to be modified to allow in-account AWS Backup service-linked role to perform encryption and decryption.

Secondly, if you refer to the design diagram above, I’ve mentioned that the service-linked role for Backup in the backup needs the decrypt permissions on the RDS instance KMS key (critical_data), for the copy operation to be successful. This too has to be included in the KMS key policy.

Add the following statements to the KMS key policy, replacing the Principal ARNs with proper values. (the ARN of the service-linked Role for Backup in the workload_a account for the first statement, and the ARN of the service-linked Role for Backup in the prod account that was copied in the step that created the vault in the backup account)

{
    "Sid": "Enable in account Backup service specific encryption",
    "Effect": "Allow",
    "Principal": {
        "AWS": "<ARN of the service-linked role for Backup in workload_a account>"
    },
    "Action": [
        "kms:GenerateDataKey",
        "kms:DescribeKey",
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:CreateGrant"
    ],
    "Resource": "*"
},
{
    "Sid": "Allow cross-account backup service specific encryption",
    "Effect": "Allow",
    "Principal": {
        "AWS": "<ARN of the service-linked role for Backup in backup account>"
    },
    "Action": [
        "kms:GenerateDataKey",
        "kms:DescribeKey",
        "kms:Decrypt",
        "kms:CreateGrant"
    ],
    "Resource": "*"
},

Monitoring Backup Process

Now that the vaults and the backup plans are created, and permissions are taken care of, AWS Backup will start executing Backup jobs in the scheduled window. The progress of these jobs can be monitored in the “Jobs” section, where there are separate tabs for “Backup Jobs” and “Copy Jobs” (and “Recovery Jobs” which is another article).

The jobs in the “Backup Jobs” tab indicates data being copied from resources to the in-account vault in the workload_a account.

The Recovery Points can be seen in the vault in the workload_a account.

When a “Backup Job” is completed, if the rule that created the job is configured to copy data to another vault, a “Copy Job” will soon be created. That indicates the recovery points being copied from the source vault (in workload_a account) to cross-account vault (in prod account).

When these jobs are done, the Recovery Points can be seen in the cross-account vault in the backup account.

Conclusion

This is basically how the entire design discussed in the article on cross-account backups is implemented. Another article discussed in detail how to do the same with Terraform.

There are newer features like automated recovery testing to be explored, and I’ll follow this up with a video and an article on those areas soon.