Skip to main content
emnode
Sign up
Compliance Medium severity

AWS Security Hub · DocumentDB

DocumentDB.2: DocumentDB adequate backup retention

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub DocumentDB.2 check?

DocumentDB.2 checks that a cluster's backup retention period meets a configured minimum. It reports FAILED when the period is below the threshold: the `minimumBackupRetentionPeriod` parameter defaults to 7 days (accepting 7 to 35), while a new cluster defaults to just 1 day.

Why does DocumentDB.2 matter?

Backup retention is the difference between a quick recovery and permanent data loss. Logical corruption, an accidental mass delete, a buggy migration, or a ransomware event often isn't noticed for days: a one-day point-in-time-recovery window gives no margin, whereas a 7-to-35-day window turns most of those incidents into a routine point-in-time restore instead of a disaster.

How do I fix DocumentDB.2?

  1. Inventory every cluster's current retention period.
  2. Decide the right window per system rather than blanket-setting one value; critical stores warrant longer.
  3. Raise `BackupRetentionPeriod` in place with `modify-db-cluster`; the change is online with no downtime.
  4. Bake the retention floor into provisioning templates so new clusters don't ship at the 1-day default.

Remediation script · bash

# Set a 7-day backup floor on production databases below it (skip read replicas).
for db in $(aws rds describe-db-instances \
    --query 'DBInstances[?ReadReplicaSourceDBInstanceIdentifier==`null` && BackupRetentionPeriod<`7`].DBInstanceIdentifier' --output text); do
  aws rds modify-db-instance --db-instance-identifier "$db" \
    --backup-retention-period 7 --no-apply-immediately
done

# Turn on DynamoDB point-in-time recovery (instant, no downtime).
aws dynamodb update-continuous-backups --table-name prod-orders \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

# Stop any snapshot in the account from being shared publicly, ever.
aws ec2 enable-snapshot-block-public-access --state block-all-sharing

Full walkthrough (console steps, edge cases and verification) in the lesson Configure backups and retention.

Is DocumentDB.2 a false positive?

A genuinely disposable cluster is the legitimate fail. A throwaway dev, demo, or CI cluster whose data is fully regenerable from seed scripts or a source system has no recovery value, so keeping the 1-day default (or any window below 7 days) is a reasonable, intentional cost choice, yet the control reports FAILED because it compares BackupRetentionPeriod against the minimumBackupRetentionPeriod parameter and nothing else. The cleaner fix is to tune the parameter rather than suppress: if a class of clusters legitimately needs a lower floor you can lower minimumBackupRetentionPeriod for the control, but since that applies account-wide, the usual move is to keep the 7-day floor and suppress the specific throwaway clusters' findings (workflow status SUPPRESSED via BatchUpdateFindings or an automation rule keyed on a tag) with a note recording that the data is regenerable.

Full lesson Configure backups and retention Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for DocumentDB controls ↗ Check your own account for DocumentDB.2 →
Part of the learning path Lock down access

More DocumentDB controls