Reputation: 8107
What are the best practices around how to structure your subscriptions in SNS. On my current project, we are processing long running jobs for files, which can take some minutes to process, and we have an optional notification a client can receive when their job finishes. This callback notification can be of different integration formats, such as HTTP Post, message to an SNS Topic and in the future more.
Originally I was planning to do a subscription per customer, but then I instead opted for doing a subscription per integration. That is I had a message attributes of type callbackType
which could be of HTTP
or SNS
. If callbackType=HTTP
there there should be another attribute called httpUrl
, if it is callbackType=SNS
there should be a topicArn
. Then in my queue I had 2 different Lambda subscriptions one for each callbackType
which would do the actual callback.
On the one hand this is great because I don't need to create a new subscriptions for each customer, and the retry logic is reused. But on the other the throttling is not per customer, but per integration, which means customers are not as isolated as they would be. Additionally we have at least one customer who wants us to forward this message to their SNS topic, so they need to grant access to our Lambda function's role
as I understand, which another customer might have to do the same again for the same role ideally.
Is this the right approach? Or should I rather be having one subscription map to one customer, or is one subscription mapping to many customers ok? I don't need the subscribe unsubscribe functionality of SNS I am more interested in any tradeoffs I might be missing with this approach.
Upvotes: 0
Views: 170
Reputation: 51624
For application integration I would consider using Amazon EventBridge instead of Amazon SNS.
Create a custom event bus with two event rules that are listening for custom events. One for the message with callbackType SNS and one for HTTP, both triggering their respective Lambda function as you describe.
There is no restriction on the rate of events that can be received from AWS services or other AWS accounts. If you send custom events to your event bus, the PutEvents API quotas apply.
Upvotes: 2