Using count to enable/disable resources in terraform 0.12 leads to odd code patterns

Hi, up until now in terraform 0.11 we were using things similar to this:

resource "aws_db_subnet_group" "main" {
  count = "${var.db_count}"
}

resource "aws_db_instance" "rds_instance" {
  # . . .
  count = "${var.db_count}"
  db_subnet_group_name = "${aws_db_subnet_group.main.name}"
}

We used count to easily disable/enable resources or whole modules, depending on certain situations. This with terraform 0.12 is not directly possible, and you have to change db_subnet_group_name to

  db_subnet_group_name = "${aws_db_subnet_group.main[count.index].name}" 

In terraform 0.11 this wasn’t necessary if count was 1. We use count to enable/disable resources, so upgrading to terraform 0.12 will mean loads of [count.index] added in order to be able to have enable/disable.

I see that it can make sense that count works like that, from the perspective of enabling and disabling things it is cumbersome. Is there another recommended way to enable or disable resources instead of using count?

3 Likes

Unfortunately its by design… not sure why noone responded to this till this date :slight_smile:

for resources where count is set – even if the expression evaluates to 1aws_instance.example returns a list of objects whose length is decided by the count. In this case aws_instance.example.id is an error, and must instead be written as aws_instance.example[0].id to access one of the objects before retrieving its id attribute value.