An operations team protects EBS volumes, RDS databases and DynamoDB tables across several accounts. Today each team scripts its own EBS snapshot schedule and RDS automated backups separately, and the DynamoDB tables are not backed up at all. The team wants one place to define a daily schedule and retention that applies to all of these resource types by tag, with central reporting on backup success. Which approach meets this requirement with the least ongoing scripting?
- AKeep the existing EBS snapshot scripts and RDS automated backups, and add a separate Lambda function that exports each DynamoDB table to Amazon S3 on a nightly schedule.
- BUse Amazon Data Lifecycle Manager to schedule snapshots for every resource type, since it manages EBS, RDS and DynamoDB backups from one policy.
- CEnable S3 Versioning on a central bucket and have every service write its backup artefacts there so that one bucket policy governs retention for all resource types.
- DCreate an AWS Backup plan that selects resources by tag and applies a daily backup rule with a retention period, covering the EBS, RDS and DynamoDB resources centrally. Correct
Why A is wrong: This stitches together three independent mechanisms with custom code, so it still demands per-service scripting and gives no single schedule, shared retention or central success reporting across the resource types.
Why B is wrong: Data Lifecycle Manager is a tempting single-policy answer but it only automates EBS snapshots and EBS-backed AMIs; it does not back up RDS or DynamoDB, so it cannot cover all the stated resources.
Why C is wrong: S3 Versioning only retains object versions in a bucket and does nothing to schedule EBS, RDS or DynamoDB backups, so the team would still have to build and run all the backup jobs themselves.
Why D is correct: AWS Backup is the managed service built to centralise scheduling and retention across EBS, RDS and DynamoDB through one tag-based plan, and it reports backup job status centrally without per-service scripting.