Adding condition to existing Terraform code that was successfully run - amazon-web-services

Question

As I'm working with an existing terraform code that has been run successfully against AWS, I discovered I'd like to reuse the code in a different region without having to have a 2nd set of the same code. Some of the code affects global services which means I don't need it to be rerun in the other regions, so I would like to include the count = "${var.alreadyrun}" == "yes" ? 1 : 0 , in some of the terraform modules.
However, when I add the above line to the existing code for the specific modules, when I run terraform plan against the same region it was already run against, it tells me it's going to destroy and re-add those modules. I don't want to destroy and the recreated modules, I just want to skip it and move on to the next. Is there a way I can do this?

Answer 1

Adding count to a module block causes Terraform to track multiple instances for that block, and so the address of the module will change from something like module.example to be like module.example[0] instead, and so by default Terraform will assume you want to destroy the old module instance with no instance key and create a new one with instance key zero.
However, if you are using Terraform v1.1 or later you can add an additional declaration to tell Terraform that you want to "move" the existing module instance to a new address instead. For a module "example" block, that would look like this:
module "example" {
source = "./modules/example"
count = var.enable_example ? 1 : 0
# ...
}
moved {
from = module.example
to = module.example[0]
}
There are more details on moved blocks in the Terraform documentation section Refactoring.
As a side-note, when declaring a conditional module or resource based on a n input variable like this it's more typical to name it something like enable_example as I showed above, rather than a name like "already run", because a Terraform configuration should typically declare a desired state rather than describing how to reach that state.
You might also wish to investigate the possibility of splitting your Terraform configuration into multiple parts so that there's a "global" configuration that you use only once and then a "regional" configuration that you use for each region. That will then avoid the need to treat one of the regions as "special", also being responsible for the global infrastructure, and thus create a clearer dependency graph between all of your configurations for future maintainers to understand.
Both of those suggestions are away from your direct question, though; a moved block as I described above is the more direct answer.