Versions after 2.2.0-alpha1 destroy existing interface VPC endpoint security group associations #165
Description
Describe the Bug
Changes were made in v2.2.0 and v2.3.0 to specify the first security_group_id in security_group_ids as part of the interface_endpoint resource, and add a aws_vpc_endpoint_security_group_association resource for the rest. Applying this to existing interface VPC endpoints results in a plan where Terraform will destroy the association for the first security group and remove the security group from the endpoint:
# module.vpc.module.vpc_endpoints.aws_vpc_endpoint_security_group_association.interface["<interface_vpc_endpoints_key>[0]"] will be destroyed
# (bec***se key ["<interface_vpc_endpoints_key>[0]"] is not in for_each map)
- resource "aws_vpc_endpoint_security_group_association" "interface" {
- id = "<id>" -> null
- replace_def***lt_association = true -> null
- security_group_id = "<id>" -> null
- vpc_endpoint_id = "<id>" -> null
}
It's unclear how users with existing interface VPC endpoints are supposed to migrate to the new versions.
Expected Behavior
Security group associations for existing interface VPC endpoints should not be destroyed when upgrading to new versions. Alternatively, there should be some guidance on how to migrate.
Steps to Reproduce
Use version 2.2.0-alpha1 of the cloudposse/vpc/aws//modules/vpc-endpoints module to create an interface VPC endpoint with a security group. Upgrade to v2.3.0 and create a plan to observe that Terraform wants to destroy the aws_vpc_endpoint_security_group_association resource for that endpoint, which will result in an outage.
Screenshots
No response
Environment
Module version: 2.3.0
Terraform version: 1.11.2
AWS provider version: 5.100.0
Additional Context
Our solution was to create our own aws_vpc_endpoint_security_group_association resource for each existing interface VPC endpoint, and add a moved block to move the old resources to our new ones. That prevented Terraform from wanting to destroy the security group associations.