DynamoDB tables should have deletion protection enabled

A single DeleteTable API call can permanently destroy a DynamoDB table and all its items. Deletion protection adds a two-step requirement: someone must first disable protection, then issue the delete. This matters in environments where multiple teams share an AWS account or where CI/CD pipelines run with broad IAM permissions. Without it, a misconfigured automation script or a compromised credential can wipe production data in seconds.

Point-in-time recovery and on-demand backups help, but restoring a large table takes time and may not capture the exact state before deletion. Prevention is cheaper than recovery.

Retrofit consideration

Enabling deletion protection on an existing table requires no downtime and has no performance impact. That said, if your Terraform state currently has deletion_protection_enabled = false or omits the argument entirely, applying the change triggers an in-place update.

Implementation

Choose the approach that matches how you manage Terraform.

Use the compliance.tf module to enforce this control by default. See get started with compliance.tf.

module "dynamodb_table" {
  source  = "registry.compliance.tf/terraform-aws-modules/dynamodb-table/aws"
  version = ">=5.0.0"

  attributes = [
    {
      name = "id"
      type = "S"
    }
  ]
  hash_key = "id"
  name     = "abc123"
}

This control is enforced automatically with Compliance.tf modules. Start free trial

If you use terraform-aws-modules/dynamodb-table/aws, set the right module inputs for this control. You can later migrate to the compliance.tf module with minimal changes because it is compatible by design.

module "dynamodb_table" {
  source  = "terraform-aws-modules/dynamodb-table/aws"
  version = ">=5.0.0"

  attributes = [
    {
      name = "id"
      type = "S"
    }
  ]
  hash_key = "id"
  name     = "abc123"

  deletion_protection_enabled = true
}

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

resource "aws_dynamodb_table" "this" {
  attribute {
    name = "id"
    type = "S"
  }

  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "id"
  name         = "pofix-abc123"

  deletion_protection_enabled = true
}

What this control checks

In aws_dynamodb_table, deletion_protection_enabled must be true. Omitting the argument defaults to false, which fails the control. No additional resources or IAM changes are needed. It fails when the argument is absent or explicitly set to false.

Common pitfalls

Default value is false

The deletion_protection_enabled argument on aws_dynamodb_table defaults to false when omitted. Existing Terraform modules or copy-pasted configurations that predate this feature will fail the control unless explicitly updated.

Terraform destroy blocked unexpectedly

With deletion_protection_enabled = true, terraform destroy will fail because AWS rejects the DeleteTable call. You must set the argument to false, apply, then destroy. This is the intended behavior but catches teams off guard during environment teardown.

Global tables require protection on each replica

For DynamoDB global tables, deletion protection is a per-table setting. If you manage replicas through replica blocks on aws_dynamodb_table, verify that replica tables also have deletion protection enabled. The setting does not automatically propagate from the primary.

IAM permissions can bypass the intent

A principal with dynamodb:UpdateTable can disable deletion protection and then delete the table. Deletion protection is not a substitute for least-privilege IAM policies. Pair it with SCPs or IAM condition keys to restrict who can toggle the setting.

Audit evidence

AWS Config rule evaluation results showing all DynamoDB tables COMPLIANT for a rule checking deletion_protection_enabled is the primary evidence artifact. The DynamoDB console shows deletion protection status under 'Additional settings.' CloudTrail logs for CreateTable and UpdateTable events should show DeletionProtectionEnabled: true in the request or response parameters, confirming the setting was applied and has not been reverted. For continuous coverage, a Config conformance pack or third-party compliance scanner report with passing evaluations across the audit period is the strongest proof.

Tool mappings

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

Compliance.tf Control: dynamodb_table_deletion_protection_enabled
AWS Config Managed Rule: DYNAMODB_TABLE_DELETION_PROTECTION_ENABLED
Powerpipe Control: aws_compliance.control.dynamodb_table_deletion_protection_enabled
Prowler Check: dynamodb_table_deletion_protection_enabled
AWS Security Hub Control: DynamoDB.6

Last reviewed: 2026-03-09