Closed tomstachura closed 7 years ago
Hi @tomstachura, not sure if you already got an answer to this but that is intended.
I didn't write this module but I do use it. What essentially happens is it creates one public route table and then associates all the public subnets to that one route table. That's why you noticed that it's not being iterated through, while each private subnet is associated to their own private route table.
For public subnets, you really only need one route table with a route to the internet gateway. It's a different story for the private ones.
Closing this issue, because #33 has been closed also and I think it answers this issue also. Please reopen, if this is still an issue.
Pardon my ignorance - I am not an expert in this.
In this snippet:
resource "aws_route_table_association" "private" { count = "${length(var.private_subnets)}" subnet_id = "${element(aws_subnet.private..id, count.index)}" route_table_id = "${element(aws_route_table.private..id, count.index)}" }
resource "aws_route_table_association" "public" { count = "${length(var.public_subnets)}" subnet_id = "${element(aws_subnet.public.*.id, count.index)}" route_table_id = "${aws_route_table.public.id}" }
For private subnets the 2 different route tables are iterated through, while for the public subnet, the same route table is used for both (no iteration).
Is that correct, or should the public subnets be associated to the different route tables?