By using Terraform to change infrastructure, you can version control not only your configurations but also your state so you can see how the infrastructure evolved over time.

Let’s modify the ami of our instance. Edit the aws_instance.example resource in your configuration and change it to the following:

resource “aws_instance” “example” {

ami = “ami-b374d5a5”

instance_type = “t2.micro”

}

$ terraform apply

# …

-/+ aws_instance.example

ami: “ami-2757f631” => “ami-b374d5a5” (forces new resource)

availability_zone: “us-east-1a” => “”

ebs_block_device.#: “0” => “”

ephemeral_block_device.#: “0” => “”

instance_state: “running” => “”

instance_type: “t2.micro” => “t2.micro”

private_dns: “ip-172–31–17–94.ec2.internal” => “”

private_ip: “172.31.17.94” => “”

public_dns: “ec2–54–82–183–4.compute-1.amazonaws.com” => “”

public_ip: “54.82.183.4” => “”

subnet_id: “subnet-1497024d” => “”

vpc_security_group_ids.#: “1” => “”

The prefix -/+ means that Terraform will destroy and recreate the resource, rather than updating it in-place. While some attributes can be updated in-place (which are shown with the ~ prefix), changing the AMI for an EC2 instance requires recreating it. Terraform handles these details for you, and the execution plan makes it clear what Terraform will do.

Additionally, the execution plan shows that the AMI change is what required resource to be replaced. Using this information, you can adjust your changes to possibly avoid destroy/create updates if they are not acceptable in some situations.