AWS SNS灵活发布至主题订阅者的子集？

Question

这里是我要构建的模型： 无限的主题（我知道AWS限制是目前3000）每个主题 无限用户（AWS SNS文件未规定限制）

每个用户都会有不同的时间表他们希望收到短信或电子邮件。

如果我有10个订阅者的主题，其中5个想要早晨消息，5个想要晚上消息。日程表可以更改，并由管理员通过网络应用程序（利用API）进行管理，因此每个日程安排构建一个主题并不是理想的解决方案，并且这些变体会咀嚼3000个主题中的很多主题。

Answer 1

SNS不支持发布到主题订阅者子集的能力，除了使用其Android/iOS推送通知功能时，它既不是电子邮件也不是http，也不是短信，而且与SNS所做的其他一切不同，我不完全确定亚马逊为什么不把它作为一个完全不同的产品进行推广。

此时，直接寻址仅支持推送通知到iOS，点燃，和Android端点

^{http://aws.amazon.com/sns/faqs/#Does_SNS_support_direct_addressing_for_SMS_or_Email}

的documented limit的用户数量单个主题是10,000。这似乎是一个硬性限制;然而，每个账户3,000个主题的限制显然不是硬性限制，因为有一个文档化的过程可以达到该限制。

每个10,000个订阅者的3,000个主题与2个或3个主题的10个订阅者之间存在很大差距，但它似乎仍然不像您想要做的那样是正确的平台 - 限制或没有限制 - 因为每次订阅者被添加到主题时，他们都必须确认他们对该主题的订阅...因此，如果您的管理员操纵主题订阅的任何内容仍然会导致a confirmation message from "AWS Notifications"被从Amazon SNS发送给每个订阅者要求他们在随后的消息可以交付之前选择加入，而这是一个过程，如果用户想要改变他们的交付时间表（这意味着将他们添加到新的主题），这将是不得不重复的过程。您无法以编程方式跳过此步骤。

在AWS中，Simple Email Service看起来像是一个更合适的（并且对收件人友好，假设您的收件人来自公众）平台，它基于您正在考虑的内容以及确定哪些收件人与每条消息都由您的数据库中的逻辑决定......它没有相同的定价结构，并且它不会执行SMS（尽管通过SNS的SMS看起来非常昂贵），并且与SNS不同，SES不会每条消息有256k限制。

这会给您的应用程序带来更多的负担，因为您必须将消息的副本发送给每个订阅者的SES，但是如果出站带宽是个问题，那么部署在EC2内部的实例可以轻松地处理复制并将消息传输到SES。使用SES，您的邮件中还会获得bounce and complaint notifications。

这是我会采取的方法。

但是再一次，很难确切地告诉你要问什么。