Day 9 of the 30 Days of AWS Terraform series focuses on Terraform Lifecycle Rules — powerful controls that decide how Terraform creates, updates, replaces, and destroys resources.
Until now, Terraform felt automated.
Today, it became safe, predictable, and production-ready.
Lifecycle rules are critical for:
Preventing accidental deletions
Reducing downtime during updates
Enforcing compliance
Controlling replacement behavior
Validating infrastructure conditions
🎯 Why Lifecycle Rules Matter
By default, Terraform follows a simple rule:
Destroy first → then create
This can cause:
Application downtime
Accidental deletion of critical resources
Unwanted rollbacks
Loss of compliance
Lifecycle rules allow us to override default behavior safely.
🔹 What Are Terraform Lifecycle Rules?
Lifecycle rules are Terraform-native controls applied inside a resource block:
lifecycle {
...
}
They define how Terraform should treat resource changes, not what the resource is.
🔑 Lifecycle Rules Covered
1️⃣ create_before_destroy — Zero Downtime Updates
Problem:
Terraform destroys the old resource before creating the new one → downtime.
_
Solution:
lifecycle {
create_before_destroy = true
}_
Behavior:
New resource is created first
Old resource is destroyed only after
Ensures zero downtime
Demo Insight:
When set to false, EC2 was destroyed first → downtime occurred.
✅ Use for: EC2, ALB, ASG, resources behind traffic
❌ Avoid for: Resources that must remain unique (e.g., fixed IPs)
2️⃣ prevent_destroy — Protect Critical Resources
Problem:
terraform destroy can delete everything — including production resources.
Solution:
lifecycle {
prevent_destroy = true
}
Behavior:
Terraform blocks deletion
Even terraform destroy fails
Resource is protected unless rule is removed
Demo Result:
Terraform throws an error and refuses to destroy the resource.
✅ Use for:
Databases
S3 buckets with data
Production infra
3️⃣ ignore_changes — Allow External Modifications
Problem:
Terraform overwrites manual or automated external changes.
Solution:
lifecycle {
ignore_changes = [desired_capacity]
}
Demo:
Auto Scaling Group desired capacity modified manually in AWS Console
terraform apply did not revert the change
Behavior:
Terraform ignores changes for specified attributes.
✅ Use for:
Auto Scaling Groups
Resources modified by external systems
Ops-driven configurations
4️⃣ replace_triggered_by — Replace When Dependency Changes
Problem:
Changing a dependency doesn’t always recreate dependent resources.
Solution:
lifecycle {
replace_triggered_by = [aws_security_group.main]
}
Behavior:
When security group changes
EC2 instance is automatically replaced
This enforces dependency-driven replacement.
✅ Use for:
Security groups
AMI changes
Config-dependent resources
5️⃣ Preconditions & Postconditions — Policy Enforcement
Problem:
Terraform allows invalid or non-compliant infrastructure.
Solution:
lifecycle {
precondition {
condition = contains(keys(var.tags), "compliance")
error_message = "Compliance tag is required"
}
}
Behavior:
Precondition → validated before resource creation
Postcondition → validated after resource creation
Deployment fails if conditions are not met
Demo:
Missing mandatory tag caused Terraform to fail
Fixing tag allowed successful deployment
✅ Use for:
Compliance
Security policies
Organizational standards
🏁 Conclusion
Day 9 transforms Terraform from automation into controlled orchestration.
Lifecycle rules give you:
Safety
Reliability
Compliance
Predictability
Zero-downtime updates
Mastering lifecycle rules means you can confidently manage real production AWS infrastructure with Terraform.
_
Next up:
👉 Terraform Lifecycle + Advanced Scenarios & Best Practices 🚀_
Top comments (0)