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

In Part 1, I emphasized DORA’s requirements and the overall architecture of resource backup within an organization. In this part, I will focus on backup initiation strategies, vaults, retention of the recovery points, and tagging policy.

Backup Strategies

If the resources in your AWS Organization are managed via code, aka infrastructure as code, you are on good terms. Otherwise, you will need to spend some time categorizing and structuring your resources based on their type and data retention.

First, let’s define the retention of the resources and its data based on the legal requirements. For example, as a financial entity, you must retain specific data about the customer or its transactions for between 7 and 35 years! This would mean the data deletion process, which is also a GDPR requirement, must be in alignment with the data backup process; otherwise, you will end up retaining backups that do not contain all the customer data that is legally needed.

To make the GDPR relation with a backup more understandable, look at the timeline below:

Now, let’s review the process:

1. You take daily, monthly, and yearly backups. Daily recovery points are retained for 30 days, monthly for 12 months, and yearly for 35 years.
2. Every team has a pre-defined process for triggering the data deletion from a notification received from an event bus every 35 days.
3. The customer’s personally identifiable data gets deleted, and you have the customer data in the database only for another 30 days since the daily backup recovery points are the only item containing the customer data.

What I mentioned above as an example scenario is a highly misaligned plan of action in a financial institution, but it can happen! To stay compliant and retain the data, nullifying the customer’s PII data is always easier than deleting it. Retaining the customer data in warm storage of the production database without needing it is not exactly ideal. Still, if you do not have a properly structured data warehouse that complies with the regulatory requirements and builds for compliance needs, then you do not have much of a choice.

Now that you understand the relationship between GDPR data deletion and backups and how you should consider it, we will move on to the backup policy.

In my view, AWS Backup is one of the best solutions AWS has released in the storage category for compliance and operation. You can operate AWS Backup well within the root account or delegate an administrator to a dedicated backup account to limit the root account usage and exposure for best practices. The architecture diagram I provide would work perfectly with either of them.

The goal is to create a backup policy that controls the resources deployed in any AWS organization account. A backup policy based on a legal requirement will likely be set to back up resources across multiple AWS accounts. Thus, numerous backup policies with different sets of rules are needed to satisfy the legal and compliance needs.

In this scenario, let’s assume we only need to create two backup policies: one with seven years of yearly retention (let’s call it transactions db) and another with ten years (rewards db). Both the daily and monthly backup policies are identical.

	daily	monthly	yearly
transactions db	30	365	2555
rewards db	30	365	3652

AWS Backup policy that is a part of the Organization policy only supports tagging. This means a tag-based policy is your best friend for implementing backups cross-account.

	daily	monthly	yearly	tag
transactions db	30	365	2555	db_30_365_2555
rewards db	30	365	3652	db_30_365_3652

If you look at the image above, you see that the restore testing candidate is true, but it is not part of the tag. That is because a separate tag key and value will be used for automated restore testing, which is also a DORA requirement.

Backup Vaults

There are three retention categories defined in the backup strategy daily, monthly, and yearly.

What is AWS Backup Vault?

AWS Backup Vaults are secure storage containers (virtually) within the AWS Backup service, designed to store backup copies of AWS resources such as Amazon EC2 instances, Amazon RDS databases, Amazon EBS volumes, and more. Vault provides a centralized, organized location for managing and protecting the recovery points.

Key Features of AWS Backup Vaults:

1. Secure Storage:
   • Backup vaults offer encryption for backups at rest using AWS Key Management Service (KMS) encryption keys. You can specify a KMS key to encrypt your backups for added security.
2. Centralized Management:
   • Backup vaults help in managing backups from various AWS services in a centralized place, simplifying the backup management process across multiple AWS accounts and regions.
3. Cross-Region and Cross-Account Backups:
   • AWS Backup allows you to create backup copies in different regions (cross-region backups) and share them across different AWS accounts (cross-account backups) for improved resilience against regional failures and data loss.
4. Access Control:
   • Backup vaults are integrated with AWS Identity and Access Management (IAM), allowing you to control who can access and manage backups stored in the vault. You can define detailed policies for who can create, restore, or delete backups.
5. Retention and Lifecycle Policies:
   • You can define retention policies for backups stored in the vault, specifying how long backups should be retained before they are automatically deleted. This helps in compliance with data retention regulations like DORA.
6. Monitoring and Audit:
   • AWS Backup integrates with AWS CloudTrail, providing detailed logs of backup operations such as creation, deletion, and restoration of backups. This enables auditing and tracking of all backup activities.
7. Immutable Backups:
   • AWS Backup Vault Lock is a feature that allows you to make backups immutable, meaning they cannot be deleted or altered for a specified period, which helps in protecting against accidental or malicious data loss (useful for compliance with regulations).

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

In the next part, I will elaborate on the backup policy creation, legal hold, and vault lock.

End of Part 2 – Stay tuned!