Neptune DB clusters should have deletion protection enabled

Neptune graph databases often store relationship-heavy datasets (fraud graphs, knowledge graphs, identity maps) that are expensive or impossible to reconstruct from other sources. A single delete-db-cluster API call, whether from a misconfigured pipeline, an overly broad IAM policy, or a compromised credential, permanently destroys the cluster and its data.

Deletion protection adds a deliberate two-step process: an operator must first disable the flag, then delete the cluster. This friction prevents accidental or unauthorized removal and gives monitoring time to catch the configuration change before the deletion goes through.

Retrofit consideration

Enabling deletion protection on a running Neptune cluster requires a modify operation but causes no downtime. The change applies immediately.

Implementation

Choose the approach that matches how you manage Terraform.

Terraform resources

Use AWS provider resources directly. See docs for the resources involved: aws_neptune_cluster.

resource "aws_neptune_cluster" "this" {
  backup_retention_period        = 7
  cluster_identifier             = "pofix-abc123"
  enable_cloudwatch_logs_exports = ["audit"]
  neptune_subnet_group_name      = "example-neptune-subnet-group"
  skip_final_snapshot            = true

  deletion_protection = true
}

What this control checks

The control evaluates aws_neptune_cluster resources. deletion_protection must be set to true; when omitted, Terraform defaults it to false, which fails the control. No other resource types or arguments are involved. Add deletion_protection = true to the cluster resource block and the control passes.

Common pitfalls

Terraform destroy blocked by deletion protection
With deletion_protection = true, running terraform destroy fails with an AWS API error. You must set deletion_protection = false, apply, then destroy. Teams sometimes use a variable override to disable it in non-production environments, which is fine, but make sure production workspaces never inherit that override.
Default value is false
Omitting deletion_protection from the resource block is the same as setting it to false. Terraform won't warn you, the cluster deploys without protection, and this control fails. Set it explicitly every time.
Snapshot-based restores do not inherit deletion protection
Snapshot restores don't carry over configuration from the source cluster. When using snapshot_identifier on aws_neptune_cluster, deletion_protection defaults back to false regardless of the original cluster's setting. Set it explicitly on every restored resource.

Audit evidence

AWS Config rule evaluation results showing all Neptune DB clusters as compliant, or equivalent output from a CSPM tool, satisfy this requirement. Console screenshots of the Neptune cluster detail page showing "Deletion protection: Enabled" on the configuration tab are accepted.

CloudTrail logs for ModifyDBCluster events with DeletionProtection toggled off provide change history. If deletion protection was ever disabled, auditors will want a corresponding change ticket or approval record justifying the temporary removal.

Framework-specific interpretation

NIST Cybersecurity Framework v2.0: Neptune cluster deletion is a high-impact administrative action. CSF 2.0 Protect covers the data safeguard itself; Govern covers the expectation that such actions require deliberate authorization rather than a single unchecked API call. Deletion protection enforces exactly that, and both functions apply.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

Compliance.tf Control: neptune_db_cluster_deletion_protection_enabled
AWS Config Managed Rule: NEPTUNE_CLUSTER_DELETION_PROTECTION_ENABLED
Checkov Check: CKV2_AWS_58
Powerpipe Control: aws_compliance.control.neptune_db_cluster_deletion_protection_enabled
Prowler Check: neptune_cluster_deletion_protection
AWS Security Hub Control: Neptune.4

Last reviewed: 2026-03-09