这是我想要构建的模型： 无限制的主题（我知道AWS限制目前是3000） 每个主题无限制的订阅者（AWS SNS文档未声明限制）
每个订阅者都有不同的时间表，希望收到短信或电子邮件。
如果我有10个订阅者的主题，其中5个想要早晨消息，5个想要晚间消息。时间表可以更改，并由管理员通过Web应用程序（利用API）进行管理，因此每个时间表构建一个主题并不是理想的解决方案，而且这些变化会扼杀许多3000个主题。
答案 0 :(得分：3)
SNS不支持发布到主题订阅者子集的能力，除了使用其Android / iOS推送通知功能（既不是电子邮件也不是http或短信），并且与SNS所做的其他事情有很大不同，我我不完全确定为什么亚马逊不把它作为完全不同的产品推销。
此时，只有iOS，Kindle和Android端点的推送通知才支持直接寻址
http://aws.amazon.com/sns/faqs/#Does_SNS_support_direct_addressing_for_SMS_or_Email
单个主题的订阅者数量为documented limit为10,000。这似乎是一个硬性限制;但是，每个帐户3,000个主题的限制显然不是一个硬限制，因为requesting an increase有一个记录在案的流程限制。
3,000个主题每个10,000个订阅者和10个订阅者分成2个或3个主题之间存在巨大差距，但看起来SNS仍然不是您正在尝试做的正确平台 - 限制或不限制 - 因为每次将订阅者添加到主题时，他们都必须确认他们对该主题的订阅...因此，如果您的管理员操纵主题订阅的任何操作仍然会导致a confirmation message from "AWS Notifications"被发送给每个订阅者来自Amazon SNS要求他们在后续消息发送之前选择加入，如果订户想要更改他们的交付时间表（这意味着将他们添加到新主题），这是一个必须重复的过程。您无法以编程方式跳过此步骤。
在AWS中，基于您正在考虑的内容，Simple Email Service似乎更合适（并且对收件人友好，假设您的收件人来自普通公众）平台，并确定哪些收件人的逻辑与数据库中的逻辑确定的每条消息相关联......它没有相同的定价结构，也没有发送短信（虽然通过SNS发送短信似乎相当昂贵），与SNS不同，SES每条消息没有256k的限制。
这确实会给您的应用程序带来更多负担，因为您必须为每个订阅者向SES发送消息副本，但如果传出带宽是个问题，则部署在EC2中的实例可以轻松地进行复制并将消息发送给SES。使用SES，您还可以获得bounce and complaint notifications消息。
这是我要采取的方法。
但话说回来，很难确切地说出你在问什么。