Terraform 1.5: Using prevent_destroy to Enable Cost‑Saving Instance Lifecycle

Goal

Reduce recurring hourly charges for a low‑traffic application by periodically destroying non‑critical compute resources while keeping essential stateful components alive.

Constraints & Uncertainty

The prevent_destroy lifecycle block is documented to protect specified resources, but its interaction with count or for_each when scaling down raises questions. Remote state backends with locking add another layer of complexity, especially when automated scripts trigger terraform destroy during off‑peak windows. DNS propagation delays and cold‑start latency also need to be accounted for in the overall cost‑saving strategy.

Unresolved Questions

1. How can we configure lifecycle { prevent_destroy = true } on critical resources while allowing count‑controlled compute instances to be destroyed and recreated without breaking dependencies?
2. What state‑drift mitigation steps are required when external auto‑scaling groups modify resources that Terraform does not manage directly?
3. Can a scheduled terraform destroy be reliably integrated with remote backend locking to avoid race conditions during idle‑period cost optimization?