KMS

Some things people ask the terraform-aws-modules/kms/aws module for cannot be implemented by any module, in any registry: they are limits of Terraform and OpenTofu themselves. This page is for engineers who hit one of them. For each it says what causes it, gives the native workaround in full, and, where one exists, shows the Operational Rule that removes the need for a fork. Read the native option first; several are the right answer on their own.

terraform destroy scheduled deletion of a KMS key

Destroying a KMS key schedules it for deletion, and everything encrypted under it becomes unreadable when the window expires. prevent_destroy is the guard for that, and it cannot be passed into this module.

Why Terraform cannot fix this. lifecycle is a meta-argument block, and Terraform evaluates it before it evaluates the rest of the configuration. Its arguments therefore cannot reference a variable, a local, or anything else that is computed. That is the whole reason no module can expose prevent_destroy, ignore_changes, or create_before_destroy as an input: there is no expression a module author could put there that Terraform would accept.

The request was first filed in 2015 (#3116, closed in 2023 without a change). The module-specific asks, #18367 and #22544, have been open since 2018 and 2019, and OpenTofu carries the same request. Until one of them ships a way to set a meta-argument from outside the resource block, every module in every registry has the same limitation.

The native workaround. Raise deletion_window_in_days to the maximum of 30, which this module exposes and which gives you a month to cancel a scheduled deletion. That is a real safeguard, but it depends on someone noticing inside the window. A hard stop at plan time needs the lifecycle block on the key resource. Fork this module and add the lifecycle block to the resource yourself. That works, and module maintainers do it when they need it. The cost is ongoing rather than one-off: the fork has to be re-synced with every upstream release, and each sync needs a review to confirm the block still lands on the resource it was meant for. A wrapper module does not avoid this, because the lifecycle block still has to sit inside the resource block, which is inside the module you did not write.

The rule that answers it. lifecycle_prevent_destroy_encryption adds the block for you, server-side, while the module is being downloaded. What arrives in .terraform/modules/ is ordinary HCL with this change already in it, and nothing else about the module changes: same inputs, same outputs, same version.

 resource "aws_kms_key" "this" {
   # ... the module's own configuration, unchanged ...
+
+  lifecycle {
+    prevent_destroy = true
+  }
 }

Use the rule

This source line applies the rules above during terraform init. The inputs and outputs stay the upstream module's.

module "kms" {
  source = "https://registry.compliance.tf/terraform-aws-modules/kms/aws?version=x.y.z&add_rules=lifecycle_prevent_destroy_encryption"

  # ... the same inputs you pass today; the version is in the URL above ...
}

• Pin the version in the URL. ?version= takes an exact release; without it the registry serves the latest. Delete the version argument, which Terraform accepts only on registry-protocol sources. Several rules go in ?add_rules=, separated by commas.
• Keep the token out of the source line. Register a free compliance.tf account and configure an access token; it never goes in the source line or in git.
• Preview in the Playground, within its limits. The Rules Playground shows the diff with no account, at the version it pins for KMS, which need not be yours. It reads the module root only: a rule whose resource lives in a submodule shows no diff there even though the download applies it, and a module that publishes nothing but submodules cannot be previewed. It takes the list as ?rules= because it previews rules on their own rather than against your Baseline.

On registry.compliance.tf, or on a framework host, ?add_rules= adds to whatever Baseline your organization has Enforced; on an organization host that organization's configuration decides. A module compliance.tf builds for you carries a compliancetf-manifest.json naming every rule the build received, each with an outcome recording what it did.

Related

• Rules overview - what rules are, and how they differ from compliance controls
• Rule definitions - the HCL of every selectable rule
• lifecycle_prevent_destroy_encryption - the rule page, with limits and failure modes
• Stop paying the Terraform fork tax - why forking a module to add a lifecycle block costs more than it looks
• KMS module reference - inputs, outputs, and the controls applied to it