Resource Hijacking for sns_topic and sqs_queue

[fabiodouek]

Terraform and AWS Provider Version

Terraform v1.11.3
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v5.100.0

Affected Resource(s) or Data Source(s)

• aws_sqs_queue
• aws_sns_topic

Expected Behavior

Existing SQS queues and SNS topics, which are not referenced in the TF state file should not be hijacked and auto imported into the state file.

Actual Behavior

I created an SNS topic and a SQS queue via the AWS console.
I then created a new terraform module, defining both aws_sns_topic and aws_sqs_queue. In the name attribute, I specified the same name as the one I created manually.

When I ran terraform plan, it shown that the SNS topica and the SQS queue would be created.
When I ran terraform apply, it said that the resource was created (even though it was already existing).

It seems that the TF provider is always taking an optimistic approach when creating resources.
In case where the AWS API is idempotent (in case of SQS and SNS), the provider should take a pessimistic approach and query for the resource before creating it.

Relevant Error/Panic Output

Sample Terraform Configuration

Click to expand configuration

Steps to Reproduce

1. Create an SQS queue and an SNS topic via the console
2. Create a module with aws_sqs_queue and aws_sns_topic. Define only the name attribute for both and reference the same names you used to create the resources manually
3. Run terraform init / terraform plan / terraform apply

Debug Logging

Click to expand log output

GenAI / LLM Assisted Development

n/a

Important Facts and References

The current behaviour is concerning, as it could lead to data loss and cause operational outages, since resources not managed by the state file can suddenly be automatically imported into the state (when it shouldn't), and a subsequent change could either update/destroy these resources.

This seems to be a related issue. #4160
The explanation in the above ticket doesn't seem to be correct. The fact the API is idempotent shouldn't lead to resource hijacking in TF, these are completely different concerns. The AWS provider should provide a level of abstraction and be aligned with the AWS API behaviour.

Would you like to implement a fix?

No

[github-actions]

Community Guidelines

This comment is added to every new Issue to provide quick reference to how the Terraform AWS Provider is maintained. Please review the information below, and thank you for contributing to the community that keeps the provider thriving! 🚀

Voting for Prioritization

• Please vote on this Issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize it.
• Please see our prioritization guide for additional information on how the maintainers handle prioritization.
• Please do not leave +1 or other comments that do not add relevant new information or questions; they generate extra noise for others following the Issue and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.
• For new resources and data sources, use skaff to generate scaffolding with comments detailing common expectations.