Enhancement: Expose "Subscription Filter Policy" for AWS SNS Topic Subscriptions

[hashibot]

This issue was originally opened by @rbwestmoreland as hashicorp/terraform#17072. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Enhancement

• Provider: aws
• Resource: aws_sns_topic_subscription

Please expose the "Subscription Filter Policy" feature for the aws_sns_topic_subscription resource.

A subscription filter policy is a simple JSON object that enables your subscriber to receive only the subset of messages it’s actually interested in, as opposed to receiving every single message published to the topic.

When a message is published to the topic, Amazon SNS will attempt to match the incoming message attributes to the subscription attribute that defines a filter policy. If they match, Amazon SNS will then deliver the message to the corresponding subscriber.

References

• New Feature Announcement: https://aws.amazon.com/blogs/compute/simplify-pubsub-messaging-with-amazon-sns-message-filtering/
• AWS Console Example (See "Step 4"): https://aws.amazon.com/getting-started/tutorials/filter-messages-published-to-topics/
• AWS Docs: https://docs.aws.amazon.com/sns/latest/dg/message-filtering.html

[ddcprg]

Anyone working on this one? We are interested in this feature and I'll be glad to look at it if no one else is

[ddcprg]

I've scanned through the sns_topic_subscription code quickly. For some reason the subscription attributes have been implemented as independent attributes (actually only the RawMessageDelivery has been exposed.) This limits the addition of new subscription attributes easily so I was wondering whether this is general guideline or whether was just a design decision for this specific resource (?)

[bflad]

Hi folks, this issue is a duplicate of #2554, so closing this one in preference of the earlier issue to consolidate discussion and any effort. You will be happy to know there is an open PR for implementing this in #2806, which is almost ready to 🚢 !

For some reason the subscription attributes have been implemented as independent attributes (actually only the RawMessageDelivery has been exposed.) This limits the addition of new subscription attributes easily so I was wondering whether this is general guideline or whether was just a design decision for this specific resource (?)

@ddcprg AWS implements each of their service APIs differently. In this case, the original implementation decision a few years ago has some some pros (additional validation we can perform) and cons (we need to specifically implement each attribute), but this likely will not change anytime in the near future. Architecturally speaking, I do not think we have a stance or guideline whether to map 1:1 with Terraform attributes or not, although in a general sense we would probably lean towards with the mapping as the plan-time validation provides some great benefits which potentially outweigh being slightly behind enhancements. TL;DR Most resources are implemented using what should give the best user experience with their respective service API.

[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!