Neptune.5: Neptune clusters should have automated backups

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub Neptune.5 check?

Neptune.5 checks whether a Neptune DB cluster has automated backups enabled with a retention period at or above the threshold. It fails if automated backups are not enabled, or if the backup retention period is set to less than seven days. Automated backups are continuous and enable point-in-time recovery, distinct from manual snapshots.

Why does Neptune.5 matter?

A short or zero retention window means a corruption, bad migration or ransomware event discovered a few days late leaves you no clean point to restore to. Seven days gives a realistic recovery runway and is the floor the control enforces. Unlike manual snapshots, automated backups also support point-in-time recovery to any moment within the window.

How do I fix Neptune.5?

Audit BackupRetentionPeriod across clusters with describe-db-clusters.
Set it to seven days or more with modify-db-cluster (--backup-retention-period); the change applies immediately with no downtime.
Set a backup window that avoids peak load, noting the modest storage cost for retained backups.
Default a compliant retention period in your IaC so new clusters never trip the finding.

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 Neptune.5 a false positive?

A short retention period can be deliberate on a throwaway cluster: a dev, test or ephemeral analytics environment whose graph is rebuilt from a pipeline on demand, where backups add cost with no recovery value. The control compares BackupRetentionPeriod against minimumBackupRetentionPeriod, whose seven-day value is the Security Hub default parameter rather than a fixed rule (an org can tune it anywhere from 7 to 35 days), so any such cluster fails even though seven days of backups is genuinely the wrong call there. Rather than padding retention on disposable clusters, scope these resources out (suppress the finding for the specific cluster ARN, or move non-production accounts to a separate Security Hub configuration) and keep the seven-day floor enforced where the data actually matters.

Full lesson Configure backups and retention Step-by-step remediation with CLI, code and persona-specific context.

AWS documentation for Neptune controls ↗ Check your own account for Neptune.5 →

Part of the learning path Lock down access

Neptune.1 Neptune clusters should encrypt at rest
Neptune.2 Neptune clusters should export audit logs to CW
Neptune.3 A Neptune snapshot is shared publicly
Neptune.6 Neptune snapshots should be encrypted at rest
Neptune.7 Neptune clusters should have IAM DB auth
Neptune.9 Neptune clusters should span multiple AZs