Skip to content
Ask AI about this
Help improve this page

Neptune DB clusters should be encrypted at rest

Neptune clusters store graph data that often models relationships between sensitive entities: identity graphs, fraud networks, knowledge bases with PII. Unencrypted storage means that anyone with access to the underlying EBS volumes or exported snapshots can read raw data without any authentication barrier.

Encryption at rest cannot be enabled after cluster creation. A missed setting at launch time means a full data migration to a new encrypted cluster, which for large graph datasets can take hours and require application downtime.

Retrofit consideration

Neptune does not support enabling encryption on an existing unencrypted cluster. You must create a new encrypted cluster, migrate data (e.g., using neptune-export and bulk loader), and redirect application endpoints. This requires downtime or a blue-green cutover.

Implementation

Choose the approach that matches how you manage Terraform.

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

  storage_encrypted = true
}

What this control checks

The aws_neptune_cluster resource passes when storage_encrypted is set to true. It fails when the argument is omitted or set to false. To use a customer-managed key instead of the default aws/neptune service key, set kms_key_id to the ARN of the desired aws_kms_key. Both arguments are fixed at cluster creation and cannot be changed afterward, so the plan-time check is the only meaningful enforcement point.

Common pitfalls

  • Encryption cannot be added post-creation

    Set storage_encrypted = true from day one. Neptune has no modify path for enabling encryption on an existing cluster, so adding it later causes Terraform to plan a destroy-and-recreate. That destroys all cluster data unless you snapshot first and restore to a new encrypted cluster.

  • Default KMS key limits cross-account snapshot sharing

    Snapshots encrypted with the default aws/neptune key can't be shared across AWS accounts. If cross-account snapshot access is part of your architecture, provision a customer-managed aws_kms_key with the appropriate key policy before you create the cluster.

  • Snapshot restore does not automatically remediate encryption gaps

    Restoring an unencrypted Neptune snapshot using snapshot_identifier doesn't convert the result into an encrypted cluster. Plan a migration to a freshly created encrypted cluster and verify storage_encrypted = true on the target before decommissioning the source.

  • lifecycle prevent_destroy does not prevent Terraform replacement

    Adding storage_encrypted = true to an existing unencrypted cluster resource triggers a Terraform replacement. A lifecycle { prevent_destroy = true } block makes the apply fail rather than silently dropping your data, but the migration problem still exists. Snapshot first, build a new encrypted cluster, then cut over.

Audit evidence

Auditors expect Config rule evaluation results showing all Neptune clusters as compliant for neptune-cluster-encrypted (or an equivalent custom rule), plus CLI output from aws neptune describe-db-clusters filtered to StorageEncrypted and KmsKeyId per cluster. If policy requires a customer-managed key, the KmsKeyId value gets cross-referenced against the organization's approved key inventory.

Security Hub findings or CSPM scan reports showing this control passing across all accounts and regions give the clearest picture for multi-account environments.

Framework-specific interpretation

PCI DSS v4.0: For Neptune clusters that store or index cardholder data, Requirement 3 calls for stored account data to be rendered unreadable. Encryption at rest satisfies that. A customer-managed KMS key with appropriate access policies also covers the key management expectations under 3.6 and 3.7.

NIST Cybersecurity Framework v2.0: PR.DS under the Protect function covers confidentiality of data at rest. Neptune storage encryption is one approach to meeting this for graph data that would otherwise be readable from raw EBS volumes or exported snapshots.

Tool mappings

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

  • Compliance.tf Control: neptune_db_cluster_encryption_at_rest_enabled

  • AWS Config Managed Rule: NEPTUNE_CLUSTER_ENCRYPTED

  • Checkov Check: CKV_AWS_44

  • Powerpipe Control: aws_compliance.control.neptune_db_cluster_encryption_at_rest_enabled

  • Prowler Check: neptune_cluster_storage_encrypted

  • AWS Security Hub Control: Neptune.1

  • KICS Query: 98d59056-f745-4ef5-8613-32bca8d40b7e

  • Trivy Check: AWS-0076

Last reviewed: 2026-03-09