DocumentDB clusters should have deletion protection enabled
A single mistyped aws docdb delete-db-cluster command or an overly broad IAM policy can destroy a production DocumentDB cluster and all its data in seconds. Deletion protection adds a mandatory two-step process: someone must first explicitly disable the flag before the cluster can be removed. This cheap safeguard catches automation errors, compromised credentials performing destructive actions, and honest human mistakes during maintenance windows.
Rebuilding a DocumentDB cluster from backups takes time and risks data loss between the last snapshot and the deletion event. Enabling deletion protection costs nothing and prevents an entire class of outage.
Retrofit consideration
Enabling deletion protection on a running cluster is a non-disruptive in-place update in Terraform. Coordinate with teams that rely on terraform destroy workflows in non-production environments, as they will need to disable the flag before teardown.
Implementation
Choose the approach that matches how you manage Terraform.
Use AWS provider resources directly. See docs for the resources involved: aws_docdb_cluster.
resource "aws_docdb_cluster" "this" {
backup_retention_period = 7
cluster_identifier = "pofix-abc123"
db_subnet_group_name = "example-docdb-subnet-group"
enabled_cloudwatch_logs_exports = ["audit", "profiler"]
master_password = "ChangeMe123!"
master_username = "dbadmin"
skip_final_snapshot = true
deletion_protection = true
}
What this control checks
The control checks that deletion_protection is set to true on each aws_docdb_cluster resource. When omitted, the AWS provider defaults to false, leaving the cluster unprotected. A cluster passes only with an explicit deletion_protection = true; it fails when the attribute is false or absent.
Common pitfalls
Default value is false
Omit
deletion_protectionfromaws_docdb_clusterand the cluster is unprotected. Unlike some AWS resources, there is no provider-level override, so every cluster definition needs an explicitdeletion_protection = true.Terraform destroy blocked without lifecycle handling
Running
terraform destroyfails against a protected cluster because AWS rejects theDeleteDBClusterAPI call. Teams working in ephemeral or test environments often add a variable to toggle the flag or use a two-phase destroy process. If you don't account for this upfront, CI/CD pipelines will break at teardown.Cluster recreation resets the flag
If a Terraform change forces replacement of the
aws_docdb_cluster(for example, changingengine_versionin a way that requires recreation), the new cluster uses whatever value is in configuration. Ifdeletion_protectionis omitted, it defaults tofalse. Always verify the attribute is explicitly set totrueafter any plan that shows a destroy/create cycle.Instances vs. cluster confusion
Deletion protection applies at the
aws_docdb_clusterlevel, not on individualaws_docdb_cluster_instanceresources. Instances within a protected cluster can still be deleted individually. This control targets the cluster-level setting only.
Audit evidence
AWS Config rule evaluation results showing all DocumentDB clusters compliant with deletion protection enabled. Console screenshots of the cluster configuration page showing "Deletion protection: Enabled" work as visual evidence. CloudTrail logs for ModifyDBCluster API calls with DeletionProtection set to true establish when remediation occurred. Security Hub findings or third-party CSPM output, filtered to this specific check, provide continuous coverage across all accounts and regions.
Related controls
Tool mappings
Use these identifiers to cross-reference this control across tools, reports, and evidence.
Compliance.tf Control:
docdb_cluster_deletion_protection_enabledAWS Config Managed Rule:
DOCDB_CLUSTER_DELETION_PROTECTION_ENABLEDPowerpipe Control:
aws_compliance.control.docdb_cluster_deletion_protection_enabledProwler Check:
documentdb_cluster_deletion_protectionAWS Security Hub Control:
DocumentDB.5
Last reviewed: 2026-03-09