Mastering AWS Backups: DORA Compliance with Robust Backup & Restoration Strategies – Part 3

In Part 1 and Part 2, I covered the legal basis, backup strategies, and retention and briefly touched on vaults. In this part, I will cover policy creation in the root or backup delegated account, configuring Vaults & its compliance lock, legal holds, and resource selection.

Vaults Configuration

To begin with, let’s create three standard vaults for all the recovery points: daily, monthly, and yearly.

We’ll need to repeat this step for monthly and yearly vaults.

Once the vaults are created, we can add specific policies to them. Let’s not forget that one of DORA’s requirements is about who can access the recovery points, which also includes who can delete them. Click on all the vaults, edit the access policy, and add this policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": {
                "AWS": "*"
            },
            "Action": [
                "backup:DeleteBackupVault",
                "backup:DeleteBackupVaultAccessPolicy",
                "backup:DeleteRecoveryPoint",
                "backup:StartCopyJob",
                "backup:UpdateRecoveryPointLifecycle"
            ],
            "Resource": "*"
        }
    ]
}

As you can see, the policy denies anyone deleting the recovery points, starting a copy job (be it in the same account or any account outside the organization), and it prevents modification of recovery point lifecycle.

Vault Compliance Lock

Firstly, let’s explain what is Vault Compliance Lock, its variants, and features:

Backup vault is a container that stores and organizes your backups. When creating a backup vault, you must specify the AWS Key Management Service (AWS KMS) encryption key that encrypts some of the backups placed in this vault. Encryption for other backups is managed by their source AWS services.

What is Vault Lock?

A vault lock enforces retention periods that prevent early deletions by privileged users, such as the AWS account root user. Whether you can remove the vault lock depends on the vault lock mode.

How many modes of Vault Locks are there:

• Vaults locked in governance mode can have the lock removed by users with sufficient IAM permissions.
• Vaults locked in compliance mode cannot be deleted once the cooling-off period (“grace time“) expires if any recovery points are in the vault. During grace time, you can still remove the vault lock and change the lock configuration.

Governance Mode allows authorized users some flexibility to modify or delete backups, while Compliance Mode locks down backups completely, preventing any changes until the retention period is over. Compliance Mode offers stricter control and is often used in environments requiring regulatory compliance. In contrast, the Governance Mode is more suitable for operational governance, where authorized personnel may still need to manage backups.

Let’s enable the Vault Lock in compliance mode. Why compliance? Because it simplifies the audit process and demonstrates the deletion protection, the auditors will not request additional proof if they are not already familiar with AWS Backup features.

Once the vault lock is created, it enters the state of “Compliance lock in grace time”. The message indicates that the lock can be deleted within the next three days.

Backup Policy Creation

As explained previously, you have two options:

1. Manage cross-account backup policies from the root account
2. Delegate an account to administer the backup policies

I will use the root account for policy creation as it is my test organization account. Still, it would be best if you tried to have a delegated administrator to avoid using the root account for day-to-day operations.

Click on Backup policies from the AWS Backup console under the “My Organization” section, then click “Create backup policy.” I will create two similar backup policies except for the retention period:

1. 30_365_2555
2. 30_365_3652

You might wonder how many backup policies you would need to create if you have many cases in your organization due to different retentions per resource or the data the resource contains. Suppose you require many policies due to retention requirements, as explained previously, then using infrastructure as code is a must, and a Terraform object and a loop would create policies for you with a single resource.

In the screenshots you can see that my backup policy and plan within the policy is named after the retention tag structure that I have created. Followed by, the backup rule which retains the daily backups for 35 days and replicates a copy of the recovery points into another vault in a different region or account.

IMPORTANT: as of now, AWS Backup does not support the replication/copy of recovery points in cross-region AND cross-account. You must decide which one is more important.

In the architecture diagram, which I will reshare at the bottom of the article, you can see that the replication plan is to implement eu-west-1 or Sovereign Cloud. AWS European Sovereign Cloud is a new isolated region that is being launched next year and is meant to be used for highly regulated entities and governments within Europe. You can read more about it here: https://aws.amazon.com/compliance/europe-digital-sovereignty/

In the resource assignment section, I choose the default service role and use the backup key of “backup” with the value “30_365_2555”.

With this policy created, I can now back up all resources across my AWS Organization that are tagged with the proper tag key and value and are attached to the backup policy. Simple!

Continuous Backup

AWS Backup supports a feature called Continuous Backup. It provides point-in-time recovery (PITR) for Aurora, RDS, S3, and SAP HANA on Amazon EC2 resources. Continuous Backup continuously tracks changes to the resources and enables the ability to restore them to any specific second within a defined retention period. This significantly reduces data loss (close to none) during an incident.

A few important points to remember:

• Continuous backup is generally safer because it captures data changes continuously and allows for recovery at any specific point in time, offering better protection against data loss between scheduled snapshots.
• Snapshot backups are typically faster to recover because they represent a complete, point-in-time state of the resource, so there’s no need to reconstruct incremental changes.
• Continuous backups are limited to 35 days.

Policy Attachment

AWS Backup Policy Attachment allows us to assign the backup plans to resources running across the AWS Organization OUs or Accounts. By attaching the backup policy to an OU within the organization called “Prod”, all my resources are not being backed up.

In this part, we have created the vaults, vault lock, and backup policy and finally attached the policy to specific OU targets.

As a reminder, here is what the target architecture diagram looks like:

In the next part, I will elaborate on AWS Backup Legal Holds, Audit Manager,

End of Part 3 – Stay tuned!