Terraform Life Cycle Rules

Today marks the Day 9 of 30 Days of Terraform challenge and in this blog, we will deep dive into the Terraform Life Cycle Rules. Life Cycle in terraform is one of the important meta-arguments that is needed to improve the Infrastructure mangeability and to Operationalize it.

Types of LifeCycle Rules:

Terraform Lifecycle rules are something that controls how a resource is created, modified or deleted. These are used to improve Security, Accidental deletion or modification of resources. There are a total of 5 lifecycle rules defined such as Ignore_changes, craete_before detsroy, prevent_destroy, replace_triggered_by, pre_and_post_validation

1. Ignore_Changes:

If we keep this Ignore changes lifecycle rule on any resource, then the Terraform will ignore the changes that were done outside of Terraform and will not perform any changes on that specific resource.

For example, We have created an EC2 instance with instance_type of t2.micro but when someone modified the instance type to t3.micro through AWS UI, then If we included that resource under ignore_changes, then terraform won't try to revert the changes when you execute terraform apply again.

resource "aws_instance" "web_server" {
  ami           = ami-345678987654
  instance_type = var.instance_type

  tags = var.tags
  )

  lifecycle {
    ignore_changes = [
      instance_type
    ]
}

In the above example, you can see we have included instance_type under ignore_changes lifecycle rule, So even if u modify instance_type it will not be affected in the next terraform run.

2. create_before_destroy:

In this lifecycle rule, New resource will be created first before termination of existing resource.

A simple example would be a daily use case like we have created an EC2 instance with a specific ami-id under a specific region, But for some reasons we would like to modify the ami-id or the region, In that case we will edit them and run terraform apply. Then the new resource will create first and old EC2 will be terminated after that. If for some reason new Ec2 instance didn't come up, Old instance will also not be terminated leading top terraform throwing an error.

resource "aws_instance" "web_server" {
  ami           = ami-345678987654
  instance_type = var.instance_type

  tags = var.tags


  lifecycle {
    create_before_destroy = true
  }
}

This ensures zero downtime during instance updates (e.g., changing AMI or instance type)

You can always check how this works by toggling true or false in the lifecycle rule.

Using this approach would helps us in below use cases:

1. Prevents service interruption
2. Maintains resource availability during updates
3. Reduces deployment risks
4. Enables blue-green deployments

3. prevent_destroy:

This Terraform Life Cycle rule will help us in preventing Terraform from destroying a resource. If destruction is attempted, Terraform will throw an error.

This Life Cycle rule is used in multiple Use Cases:

✅ Production databases
✅ Critical S3 buckets with important data
✅ Security groups protecting production resources
✅ Stateful resources that should never be deleted

resource "aws_s3_bucket" "critical_data" {
  bucket = "my-critical-production-data"

  lifecycle {
    prevent_destroy = true
  }
}

You can always check how this works by toggling true or false in the lifecycle rule.

Benefits of using this Lifecycle rule are:

✅ Protects against accidental deletion
✅ Adds safety layer for critical resources
✅ Prevents data loss
✅ Enforces manual intervention for deletion

4. replace_triggered_by:

This Terraform Lifecycle rule is used to force a resource replacement when specified dependencies change, even if the resource itself hasn't changed. We can use this life cycle rule when we want dependent resource changes require recreation, For immutable infrastructure patterns or When you want forced resource rotation

You can use a example of Replacing EC2 instances when security groups change. Here we have triggered the replacement of EC2 instances when change in Security groups rule is detected.

resource "aws_security_group" "app_sg" {
  name = "app-security-group"
  # ... security rules ...
}

resource "aws_instance" "app_with_sg" {
  ami           = data.aws_ami.amazon_linux_2.id
  instance_type = "t2.micro"
  vpc_security_group_ids = [aws_security_group.app_sg.id]

  lifecycle {
    replace_triggered_by = [
      aws_security_group.app_sg.id  # Replace instance when SG changes
    ]
  }
}

Some of the Benefits of using this Lifecycle rule were:

✅ Ensures consistency after dependency changes
✅ Forces fresh deployments
✅ Useful for immutable infrastructure patterns

5. Pre and Post Validations:

pre_validation:

Validates conditions BEFORE Terraform attempts to create or update a resource. Errors if condition is false.

For example, we want to create an S3 bucket with a specific tag, and if that tag doesn't exist, s3 bucket creation shouldn't happen.

resource "aws_s3_bucket" "regional_validation" {
  bucket = "validated-region-bucket"

  lifecycle {
    precondition {
      condition     = contains(var.allowed_regions, data.aws_region.current.name)
      error_message = "ERROR: Can only deploy in allowed regions: ${join(", ", var.allowed_regions)}"
    }
  }
}

Benefits of using this Lifecycle rule were:

✅ Catches errors before resource creation
✅ Enforces organizational policies
✅ Provides clear error messages
✅ Prevents invalid configurations

post_validation:

Validates conditions AFTER Terraform creates or updates a resource. Errors if condition is false.

resource "aws_s3_bucket" "compliance_bucket" {
  bucket = "compliance-bucket"

  tags = {
    Environment = "production"
    Compliance  = "SOC2"
  }

  lifecycle {
    postcondition {
      condition     = contains(keys(self.tags), "Compliance")
      error_message = "ERROR: Bucket must have a 'Compliance' tag!"
    }

    postcondition {
      condition     = contains(keys(self.tags), "Environment")
      error_message = "ERROR: Bucket must have an 'Environment' tag!"
    }
  }
}

Benefits of using this lifecycle rule were:

✅ Verifies resource was created correctly
✅ Ensures compliance after deployment
✅ Catches configuration issues post-creation
✅ Validates resource state

Conclusion:

Terraform lifecycle rules are essential for building resilient AWS infrastructure. They help prevent outages, protect critical data, ensure compliance, and maintain predictable behavior during updates. With these tools, you control not only what resources get created, but how they behave throughout their lifecycle.

This marks the Day 9 of 30 days of Terraform challenge. See you in the next blog.

Below is the Youtube Video for reference: