Terraform Life Cycle Rules

Day 9 of #30daysofawsterraform challenge

Do you really want to prevent someone from accidental deletion of resources, improve the security and improve the manageability of infrastructure in Terraform? Here is the Terraform life cycle rules comes into play.

Today I have covered "Terraform life cycle rules" with practical hands-on.

§ What is Terraform life cycle rules:
1. Terraform Lifecycle rules gives you fine-grained control over resource behavior, preventing unwanted changes and ensuring stability in production environments.

§ Meta-Arguments:

○ create_before_destroy:
1. It allows to create replacement resource first, before destroying the old one.
2. Ensures zero downtime
Eg:
resource "aws_instance" "nandan_ec2" {
ami = "ami-0ff8a91507f77f867"
instance_type = "t2.micro"
region = var.region

      tags = var.tags

      lifecycle {
        create_before_destroy = false
      }
    }

ü Usecases:
1. Updating an AWS Load Balancer that must always remain online
2. Rotating EC2 instances in an Auto Scaling group
3. Updating an RDS instance when you want zero downtime
4. Replacing an S3 bucket with the same configuration safely

○ prevent_destroy:
1. Protects resources by blocking any operation that would delete them.
Eg:
resource "aws_s3_bucket" "production_logs" {
bucket = "nandan-production-logs"

      lifecycle {
        prevent_destroy = true
      }
    }

ü Usecase:
1. Protecting production databases
2. Preventing deletion of S3 buckets holding logs or critical data
3. Safeguarding VPCs, subnets, and networking components
4. Security groups protecting production resources
5. Stateful resources that should never be deleted

○ ignore_changes:
1. Tells Terraform to ignore changes to specified resource attributes.
Eg:
resource "aws_autoscaling_group" "app_servers" {
desired_capacity = 2

    lifecycle {
ignore_changes = [
  desired_capacity,  # Ignore capacity changes by auto-scaling
  load_balancers,    # Ignore if added externally
]

}
}

ü Use Cases:
1. Auto Scaling Group capacity (managed by auto-scaling policies)
2. EC2 instance tags (added by monitoring tools)
3. Security group rules (managed by other teams)
4. Database passwords (managed via Secrets Manager)

○ replace_triggered_by:
1. Used to force the replacement of a resource when another resource or value changes.
Eg:
resource "aws_instance" "web" {
ami = var.ami_id
instance_type = "t2.micro"

      lifecycle {
        replace_triggered_by = [
          var.ami_id
        ]
      }
    }

ü Use Cases:
1. Replace EC2 instances when security groups change
2. Recreate containers when configuration changes
3. Force rotation of resources based on other resource updates
4. For immutable infrastructure patterns

○ precondition:
1. Validates conditions BEFORE Terraform attempts to create or update a resource. Errors if condition is false.
Eg:
resource "aws_instance" "web" {
ami = var.ami
instance_type = var.instance_type

      lifecycle {
        precondition {
          condition     = contains(["t2.micro", "t3.micro"], var.instance_type)
          error_message = "Only t2.micro and t3.micro are allowed!"
        }
      }
    }

ü Use Cases:
1. Validate deployment region is allowed
2. Ensure required tags are present
3. Check environment variables before deployment
4. Validate configuration parameters

○ postcondition:
1. Validates conditions AFTER Terraform creates or updates a resource. Errors if condition is false.
Eg:
resource "aws_instance" "web" {
ami = var.ami
instance_type = "t2.micro"

      lifecycle {
        postcondition {
          condition     = self.public_ip != ""
          error_message = "Instance must have a public IP assigned!"
        }
      }
    }

ü Use Cases:
1. Ensure required tags exist after creation
2. Validate resource attributes are correctly set
3. Check resource state after deployment
4. Verify compliance after creation

Devops #Terraform #AWS

Thanks to Piyush sachdeva The CloudOps Community