问题描述
有关如何在SNS中构建订阅的最佳实践是什么？在我当前的项目中，我们正在处理长时间运行的文件作业，这可能需要花费几分钟的时间，并且有一个可选的通知，当作业完成时客户端可以收到客户端的通知。该回调通知可以具有不同的集成格式，例如HTTP Post，发送到SNS主题的消息以及将来的更多消息。
最初，我打算为每个客户进行订阅，但是后来我选择了为每个集成进行订阅。也就是说，我有一个类型为callbackType的消息属性，该属性可以是HTTP或SNS。如果callbackType=HTTP应当有一个名为httpUrl的属性，如果是callbackType=SNS则应该有topicArn。然后在我的队列中，我有2个不同的Lambda订阅，每个callbackType都有一个，可以进行实际的回调。
一方面，这很棒，因为我不需要为每个客户创建新的订阅，并且重用逻辑可以重用。但是另一方面，节流不是每个客户，而是每个集成，这意味着客户没有像他们那样孤立。另外，我们至少有一个客户希望我们将此消息转发到他们的SNS主题，因此，据我所知，他们需要授予对Lambda函数的role的访问权限，另一位客户可能需要对此做同样的事情理想情况下是相同的角色。
这是正确的方法吗？还是我应该将一个订阅映射到一个客户，还是将一个订阅映射到许多客户？我不需要SNS的订阅退订功能，我对使用这种方法可能会失去的权衡更为感兴趣。
解决方法
对于应用程序集成，我会考虑使用Amazon EventBridge而不是Amazon SNS。
使用两个正在监听custom event bus的事件规则创建一个custom events。一种是针对带有callbackType SNS的消息，另一种是针对HTTP的消息，它们均会触发您所描述的各自的Lambda函数。
对可以从AWS服务或其他AWS账户接收的事件的速率没有限制。如果您将自定义事件发送到事件总线，则应用PutEvents API quotas。