Terraform Wants to Destroy Production

Step 1 — Understand the symptoms

The plan is explicit about the mechanism, if you read past the summary line: identifier is changing, and that field is annotated # forces replacement. In most cloud providers' Terraform resources, certain arguments can't be updated in place — changing them means the provider has to destroy the existing resource and create a new one to match the new configuration. For aws_db_instance, identifier is exactly that kind of argument.

The confusing part is that nobody in this PR touched identifier directly. That's the actual mystery worth chasing — not "is this plan scary," but "what changed that would cause Terraform to think this resource's identifier needs to be different."

Step 2 — Identify the likely bottleneck

A module version bump can absolutely cause this without anyone touching resource-level config directly. If the new module version changed how it constructs the identifier argument internally — a different naming convention, a new variable interpolated into it, a default value that changed — then from Terraform's perspective, the desired identifier for this resource is now different from what's actually deployed, and that's forces-replacement by definition, regardless of how small the PR diff looks from the outside.

This is the specific danger of pinning to a module without deeply reading its changelog: the module's interface might look unchanged (same inputs, same outputs) while its internal resource construction changed in a way that's invisible until you read the actual plan diff.

Step 3 — Investigation

Before applying anything:

• Read the full plan diff for the destroyed resources, not just the summary count. What's actually changing on each of the three, and does the reason line up with what the PR was supposed to do?
• Check the module's changelog or diff between the old and new pinned versions. If it's a public module, the release notes usually call out breaking changes explicitly — including changes to how identifier or similarly load-bearing fields are computed.
• Check Terraform state directly — terraform state show aws_db_instance.primary — to see the identifier as Terraform currently understands it, and compare that against what the new plan wants it to be.
• Check for configuration drift — was this resource ever modified outside Terraform (a console change, a manual fix during an incident) that the state file doesn't fully agree with? Drift is a common, separate cause of unexpected replacement plans.
• Look at the resource's lifecycle block, if one exists. A prevent_destroy = true guard on the production database would normally catch exactly this — its absence here is itself worth noting.

Step 4 — Recommended action

Don't apply. A plan that wants to destroy and recreate a production database is exactly the kind of change that needs a deliberate, reviewed decision — not an approval based on the PR's diff looking small. Pin the module version back, reproduce the plan, and confirm whether the replacement disappears; if it does, that confirms the module version bump is the actual cause, and the fix is either finding a version that doesn't change identifier construction or explicitly handling the rename with a proper migration (which for a stateful resource like a database usually means a snapshot-and-restore path, not a blind terraform apply).

This is also the moment to check whether prevent_destroy should be added to this resource going forward — a guard that makes Terraform refuse to plan a destroy on this specific resource without deliberately removing the lifecycle block first, so a future version bump can't silently reach this same situation again.

Step 5 — Engineering lesson

terraform plan telling you what it's going to do is not the same as that plan being safe. The tool did its job correctly here — it surfaced a real, consequential change caused by a dependency bump, exactly as designed. The risk isn't in Terraform's behavior; it's in treating "the PR diff is small" as a proxy for "the plan is safe," when the two can diverge completely the moment a module changes underneath a version pin.

Production Terraform changes deserve the same scrutiny as production database migrations, because for a stateful resource, that's exactly what a forced replacement is.