AWS / Guide 8

Backup and recovery

AWS Backup, protecting backups from ransomware, restores, restore testing and disaster recovery.

AWS keeps your data durable, but it doesn't keep it safe from you: a deleted table, a script run against the wrong account, or ransomware using stolen admin credentials. That's what backups are for. This guide covers AWS Backup, protecting the backups themselves, restores, and disaster recovery.

Backup versus disaster recovery

You need both for important systems. Replication alone faithfully copies a deletion or an encrypted file to the other side.

Find what is not protected

Start by finding the gaps. Get-AwsBackupCoverage.ps1 compares EC2 instances, EBS volumes, RDS databases, DynamoDB tables and EFS file systems in each region with AWS Backup's list of protected resources, and shows the last backup time for each:

.\Get-AwsBackupCoverage.ps1 -Region us-east-1 -UnprotectedOnly

Set up AWS Backup

AWS Backup is one service for EC2, EBS, RDS and Aurora, DynamoDB, EFS, FSx, S3 and more. The pieces:

• Backup vault: where recovery points are stored, encrypted with a KMS key.
• Backup plan: schedules and retention, for example daily kept 35 days, monthly kept 12 months, with lifecycle to cold storage for long retention where the resource type supports it.
• Resource assignment: which resources the plan covers. Assign by tag (Backup = Daily), not by listing resources, so new resources are covered the moment they're tagged.

With AWS Organizations, use backup policies to push the same plans to every account from the management account (or a delegated administrator), and turn on cross-account monitoring to see every job in one place. Tag-based assignment plus a tag policy (Guide 3) that requires a Backup value means nothing is left out by accident.

# What's protected in this region, and when it was last backed up
Get-BAKProtectedResourceList | Sort-Object LastBackupTime |
    Select-Object ResourceType, ResourceName, ResourceArn, LastBackupTime

# Plans and their rules
Get-BAKBackupPlanList | ForEach-Object {
    (Get-BAKBackupPlan -BackupPlanId $_.BackupPlanId -Select BackupPlan).Rules |
        Select-Object RuleName, ScheduleExpression, @{n='KeepDays';e={$_.Lifecycle.DeleteAfterDays}}, TargetBackupVaultName
}

Protect the backups themselves

Attackers with admin credentials go after backups first. Make them hard to delete, even for administrators:

• AWS Backup Vault Lock in compliance mode: once the grace period ends, no one (including the root user and AWS) can delete recovery points before their retention ends or change the lock. Test in governance mode first; compliance mode can't be undone.
• Copy to another account: a copy rule in the backup plan sends recovery points to a vault in a separate backup account, in the same or another region. Credentials stolen from a workload account can't reach it.
• Logically air-gapped vaults go further: locked by default, encrypted with AWS-owned keys, and shareable to a recovery account through AWS RAM for restore, even if the source account is lost.
• Restrict who can delete: an SCP denying backup:DeleteRecoveryPoint, backup:DeleteBackupVault and changes to vault access policies, except for a break-glass role.
• Use a customer managed KMS key for vaults holding copies, with a key policy that allows only the backup account to use it.

Watch for failed backups

A backup nobody checks isn't a backup. AWS Backup publishes job state changes to EventBridge and can notify an SNS topic directly:

# Failed or expired backup jobs in the last 7 days
Get-BAKBackupJobList -ByCreatedAfter (Get-Date).AddDays(-7) |
    Where-Object { $_.State -in 'FAILED', 'EXPIRED', 'ABORTED' } |
    Select-Object CreationDate, ResourceType, ResourceArn, State, StatusMessage

# Notify an SNS topic when jobs fail
Write-BAKBackupVaultNotification -BackupVaultName 'bv-notes-test' `
    -SNSTopicArn 'arn:aws:sns:us-east-1:111122223333:notes-test-alerts' `
    -BackupVaultEvent BACKUP_JOB_FAILED, COPY_JOB_FAILED, RESTORE_JOB_FAILED

AWS Backup Audit Manager adds continuous checks (resources protected by a plan, minimum retention, cross-region copies, vault lock) and produces reports for auditors.

Restoring

• EC2: a restore creates a new instance from the recovery point (an AMI underneath). Restore into an isolated subnet first if you're recovering from an incident, so you don't bring the problem back.
• Single files: restore the EBS volume, attach it to a helper instance, and copy what you need. For EFS, FSx and S3, AWS Backup can restore individual items directly.
• RDS: restores always create a new database instance; point the application at it or rename. Automated RDS backups also give point-in-time restore to any second in the retention window (up to 35 days).
• Keep the details that matter: security groups, instance profile, tags and IP addresses aren't always restored as they were. Record them in a runbook, or restore with a launch template.

Test restores on a schedule

AWS Backup restore testing restores recovery points on a schedule you set, runs your validation (a Lambda function or EventBridge rule that checks the restored resource), records how long it took, and deletes the test copy. Schedule one test per critical system per month, and keep the results: they're the evidence auditors ask for, and the real recovery time you can promise.

Beyond EC2

• S3: versioning plus lifecycle rules for old versions protects against overwrites and deletes; S3 Object Lock makes objects immutable; replication copies to another region or account. AWS Backup for S3 adds point-in-time restore.
• DynamoDB: turn on point-in-time recovery (continuous backups, up to 35 days) for every production table.
• Aurora: continuous backups are built in; use AWS Backup for longer retention and cross-account copies.
• Configuration: keep infrastructure in CloudFormation or Terraform in source control. Rebuilding from code is faster and more reliable than restoring configuration.

Disaster recovery

Pick the pattern by how long the business can wait and how much data it can lose:

For servers that can't be redesigned, AWS Elastic Disaster Recovery continuously replicates EC2 or on-premises servers to low-cost staging in another region and launches full instances on failover. Run a drill at least twice a year; the first one always finds something.

Examples to try

From aws.ravindran.in: S3 versioning, S3 Object Lock, S3 replication, S3 lifecycle and RDS.