I'm working SNS Push notifications into an app that I'm building, and I'm wondering how to handle user notification settings? What I don't understand is if SNS provides a way to manage a user who wants to receive notification type "A", but not type "B". A more real-world correlation is managing a Facebook user who wants notifications for comments, but not likes. Does SNS provide an easy way to manage this?
I can manage it myself through my own servers/databases, but this seems like something that SNS should be able to do.
I would suggest each notification type is a different SNS topic. That way the user can control each topic he is subscribed too. That puts more work for you in your app but this way you get to your designed goal of allowing each user to subscribe to each a different type of notification.
Topics are free but SNS messages sent are charged.
FREE TIER: Each month, Amazon SNS customers receive 1,000,000 Amazon SNS Requests, 100,000 HTTP notifications, 1,000 email notifications and 100 SMS notifications for free.
Cost calculator: http://calculator.s3.amazonaws.com/index.html
SNS Pricing Details: https://aws.amazon.com/sns/pricing/
No. SNS does not provide a way to manage users to subscribe based on notification types
In fact there is no implicit notification type definitions. Although you can have that as part of your payload.
So you can either
Have different topics for different notification types and then attach subscribers based on which type of messages they are interested in
Have a type definition defined within the payload and then let the filtering happen at the subscribers. But keep in mind that this will be costly affair because all subscribers receive all notifications and you can soon exhaust your free limit. Also the subscribers will receive unnecessary load
Related
What are the best practices around how to structure your subscriptions in SNS. On my current project, we are processing long running jobs for files, which can take some minutes to process, and we have an optional notification a client can receive when their job finishes. This callback notification can be of different integration formats, such as HTTP Post, message to an SNS Topic and in the future more.
Originally I was planning to do a subscription per customer, but then I instead opted for doing a subscription per integration. That is I had a message attributes of type callbackType which could be of HTTP or SNS. If callbackType=HTTP there there should be another attribute called httpUrl, if it is callbackType=SNS there should be a topicArn. Then in my queue I had 2 different Lambda subscriptions one for each callbackType which would do the actual callback.
On the one hand this is great because I don't need to create a new subscriptions for each customer, and the retry logic is reused. But on the other the throttling is not per customer, but per integration, which means customers are not as isolated as they would be. Additionally we have at least one customer who wants us to forward this message to their SNS topic, so they need to grant access to our Lambda function's role as I understand, which another customer might have to do the same again for the same role ideally.
Is this the right approach? Or should I rather be having one subscription map to one customer, or is one subscription mapping to many customers ok? I don't need the subscribe unsubscribe functionality of SNS I am more interested in any tradeoffs I might be missing with this approach.
For application integration I would consider using Amazon EventBridge instead of Amazon SNS.
Create a custom event bus with two event rules that are listening for custom events. One for the message with callbackType SNS and one for HTTP, both triggering their respective Lambda function as you describe.
There is no restriction on the rate of events that can be received from AWS services or other AWS accounts. If you send custom events to your event bus, the PutEvents API quotas apply.
When I publish to a topic it hits ALL subscribers ALWAYS?
I have a topic with several subscriptions, sometimes I want to publish a message to just one of those subscriptions.
Is there a way to do this or do I need to create another topic and have the subscription in 2 topics? In that case I'm bugging the user (assuming this use case is to message users) twice right?
Yes -- when a message is sent to an Amazon SNS topic, all subscribers receive the message.
If you wish to contact a specific subscriber, your code will have to contact them directly (eg via email).
Amazon SNS also has the ability to send an SMS message to one or more recipients without using an SNS Topic. So, if your desired recipients are on SMS, this is a simple task.
I am sending many messages but the subscribers change very often (per message), how can can i choose my specific subscribers on every message? the number of possibilities is too much to create topic to each combination.
You can't. A message is delivered to all subscribers of the SNS topic.
Once you subscribe an endpoint to a topic and the subscription is
confirmed, the endpoint will receive all messages published to that
topic. Source
You can manage the endpoints yourself on the back end. You then publish to an individual endpoint. For large groups you will have to build in flood protection.
We have got a strange requirement and we would like to send SMS to our clients based on the assets they are monitoring. Each asset can have 100s of subscribers and there are 1000s of assets so obviously, we can not create one SNS topic per asset. We have the assets and their list of subscribers in a RDS instance on AWS.
Is there anyway with SNS to make the list of its subscribers dynamic, each time we publish a message to it we also supply the list of subscriber this message should be sent to? What are my other options or another AWS service? Lambda maybe? Please advise. thanks
I finally used SNS for this purpose. Each time I need to sent an alert, I call a lambda and supple lambda with the list of subscribers and the message for that asset. Lambda will go ahead, create a new topic, add the subscribers to it, publish the message to it and when everything is done, removes the topic. Works great.
AWS SNS for sending sms had limitation like only for US or North America region. This point should be double checked before making such choice. If your users only from USA - so quite good. In other cases I would recommend to take a look on https://www.nexmo.com/, clickatell.com or Twilio. They provide nice API and can be managed very easy.
We're using AWS SNS (Simple Notification Services) as one of the mechanisms of sending out notifications for users. That means, there are notifications sent through SMS (using AWS SNS) / Emails / automated calls.
But any time, if a user unsubscribes from any of these three methods, We should stop sending further alerts to the user in all the three modes.
Currently I don't have a way in API to check if a subscription request has been opted-out (by sending a STOP message), so that we can block the other two modes of communications as well.
Is it possible, in SNS? I've tried looking into the list of API, console and Amazon Forums.
I've figured out that this below behaviour of AWS SNS (for SMS end points) can be a workaround.
Although currently there is no way of getting a list of endpoints (users) who unsubscribe by responding STOP to 30304 (Amazon's short number.)
But, when we subscribe a user for a topic, AWS creates a subscription record with subscriptionArn = "PendingConfirmation"
If the user responds STOP (opts out), the subscription record is deleted from the topic. If the user subscribes to it, the subscription's subscriptionArn changes to some valid ARN (Amazon's resource Number) from "PendingConfirmation".
ListSubscriptionsByTopic API lists the user subscription even if it is in "PendingConfirmation" state.
So for now, only way to know if a user has unsubscribed from the topic would be, maintaining a list of users with their end points (phone numbers / email ids) and comparing it at later point of time with the list of available list of subscriptions. If something has disappeared, it means they've unsubscribed.
Of course, it can't be real-time. But this is the only workaround that is available for now.
As an additional info, if a subscription is pending for more than 72 hours, it is automatically deleted.