这是我想要构建的模型: 无限制的主题(我知道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消息。
这是我要采取的方法。
但话说回来,很难确切地说出你在问什么。