creating multiple aws_sns_topic with the same name

[abrechon]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v0.11.8

Affected Resource(s)

• aws_sns_topic

Terraform Configuration Files

resource "aws_sns_topic" "topic" {
  name = "${var.topic}"
}

Expected Behavior

Terraform should not allow creation of multiple sns topics with the same name as aws API create topic action is idempotent.

https://docs.aws.amazon.com/cli/latest/reference/sns/create-topic.html
This action is idempotent, so if the requester already owns a topic with the specified name, that >topic's ARN is returned without creating a new topic.

Actual Behavior

you can create multiple sns topics with the same name that are in fact the same topic as AWS API returns the same arn.

Steps to Reproduce

create two aws_sns_topic with the same name in different vpc's and delete one of them. both will be deleted as the state points to the same arn.

[bflad]

Hi folks 👋 Thanks for submitting this. We would certainly like to address this problem, likely more generically for all Terraform resources that could be potentially duplicated by same dimension (such as per-region and per-name). The enhancement that would be available to all Terraform resources, which we could then implement in the aws_sns_topic resource, can be tracked upstream in the Terraform Plugin SDK.

[bflad]

Hi folks 👋 Thank you for submitting this and this is an excellent use case of somewhere that Terraform and the Terraform AWS Provider could be much more helpful since in many cases they have enough information to return an error upfront during planning instead of unexpected behavior during apply.

I believe this falls under the provider-wide enhancement proposal of #14394, so by adding this link here it will add a reference to that issue so we can include it as a use case when thinking about the implementation details. Since this is likely something we will want more broadly across many resources, I'm going to close this particular issue to consolidate discussions, efforts, and prioritization on the topic while the reference would serve as the cue to make this specific resource one of the initial implementations. I would suggest those 👍 upvoting and subscribing here to do so on #14394 so we can appropriately gauge interest. Please feel free to provide feedback there.

Thanks again!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!