Amazon SNS Reviews

Our company uses the solution as a message-oriented middleware to provide message delivery from the publisher to the subscriber. 

When we create a lambda function or an SNS, the solution publishes the message to a group of distributions in Teams or Outlook. 

Messages easily flow from publisher or application to subscriber. You can also flow messages from publisher to SNS with an https-like mediator. Amazon SQS is there, so message queue services are also there. The message transports to the service provider such as Redshift, the SQ bucket, Teams, Splunk, or any other message service.

The solution has no up-front costs. 

Messages flow much more quickly than in the past. They used to run a bit late after being published. 

Considering the setup we use in our company, Amazon SNS is useful due to its most basic functionalities, like the notification services. Amazon SNS provides notifications if any server is down, the utilization of the servers, the traffic part, any interruptions in the server, and when you need to export some logs from CloudWatch to S3. You have to subscribe to the kind of emails you want to receive from Amazon SNS to review the information the tool provides, which is free of cost.

I don't mind if, in the future, Amazon SNS plans to provide any future configuration from AWS at a good price.

In the future, there needs to be an update in Amazon SNS. If you are going to initiate Amazon SNS configuration and set up the tool in your organization, the configuration phase is carried out one by one. For example, if I get 50 servers, I have to go through the configuration phase and initiate the Amazon SNS topic, for which you need to provide a proper SNS configuration that could take a lot of time. I expect Amazon SNS to provide some capabilities to allow the configuration process to be done in a single script.

Amazon SNS needs to provide a bulk uploading system to users in the future.

It is a notification service for the device. If we need to notify anybody from your mobile or data form.  

We found that the notification is pretty much wireless. It happens with notifying customers, notifying themselves, everything. So That's how we have been it has been a company. It covers pretty much anything that I need.

We use this solution because the integration between the features is excellent. The production level services can communicate with each other easily. For example, we can implement a Dynamo DV and a couple of different triggers to communicate with Lambda. We implemented SNS modules into Lambda and Lambda communicated with SNS.

There needs to be more documentation on the integration with different platforms. For example, creating an Apple integration and learning how to build the SNS platform is difficult.

The pricing can also be better.

We use this SNS for sending out notifications to the endpoints. The endpoints could be the email address or distribution lists or another channel. In my company, I use the SNS notifications for a Slack channel, as well as an email distribution list. 

It is an ETL tool. It's used for data extraction, loading and getting an output. It's also used for data analytics and data engineering. We have configured the SNS in such a way that the developers can work on the Matillion tool run multiple jobs in their language. Whenever there's any success in the job which they run, a notification will be triggered for which SNS is used on the cloud.

The best aspect of this solution is its simplicity. We just have to create topics and can have as many subscriptions as we want under any topic we create.

I have been using Amazon SNS within my Learning Management System or LMS. I use SNS with .NET services to send push notifications to mobiles to tell parents about the progress of their kids. We send push notifications to mobile devices and emails. 

Amazon SNS is a pretty reliable service, and it is fully managed. We don't have to manage anything. Amazon totally manages everything for us. We just have to integrate the SNS service with our microservice or backend service and trigger an action to throw notifications or messages. We just trigger a notification to go to all subscribers.

I am using the latest version of this solution in my current product, which has .NET code. This solution is deployed on the cloud. We are using Elastic Beanstalk for .NET deployment and Amazon SNS for our server. We then send notifications to subscribed users or specific devices that are interested in or have subscribed to our topic.

It enables easy engagement of our users with our product. We often track users' interest to find out how they have been performing with our app or the system. Based on the performance, we recommend or send push notifications. Based on these notifications, users open our app and spend some time on our system. If we use it properly, it increases our growth exponentially.

My primary use case for Amazon SNS is for push messaging. We have a chatting application in my project library and so we have the mobile to mobile service for push notifications.

We build solutions for our clients, they ask us to implement all the documents and features for them.

SNS can be used for a lot of things. There are six different subscriber types available at the moment and among them, we use the SMS, email, and push notifications. We use the SMS and Email services to notify admins whenever something goes wrong, but our primary use case is to send push notifications to our mobile devices (customers).

The backend engineers work on setting it up on AWS and most of the features like SMS, Email, etc do not need any frontend intervention, but yes for push notifications, the frontend needs to use the SDK to capture and display them.

Previously, we had to use FCM, which was a completely separate service from Google. Whenever we had some issues with the notification center, that is, if the sending failed due to any reason (the reason could be anything like the user didn't have a proper internet connection, or if the application was not working for some reason), we had to go to the Firebase console to figure out what happened and which notifications were lost specifically. We were not using Firebase for any other application. Our entire stack is inside the AWS service and we had to use Firebase only for such instances, which was a drag.

Now that we're using SNS, we can leverage CloudWatch logs. We can also have a dead letter queue to store the messages that were failed. Later on, at any point in time, we can just check the queue and see the failed messages. We can also send a message from this queue to our admins so that they can easily and directly receive an SMS whenever a notification sending fails. All these features made SNS a lot more solid.