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。

這是我會採取的方法。

但是再一次，很難確切地告訴你要問什麼。