Amazon SNS Reviews

A specific example of how I use Amazon SNS for the pub-sub model in my day-to-day work is that we use it for messaging, real-time notifications, and for creating event-driven architecture using other AWS services, and for multi-protocol support and security.

I do not have anything else to add about my main use case or how Amazon SNS fits into my architecture.

When I mention real-time capabilities and integration with other AWS services, specific integrations or real-time features that stand out most to me are S3 bucket events including creating a bucket, creating an object, updating an object, modifying an object, and deleting an object. Additionally, with CloudWatch alarms, when I get an alarm on CloudWatch, it will notify me via email using Amazon SNS. The same applies to application events.

Amazon SNS has impacted my organization positively because using it, we are able to create an event-driven architecture and send notifications for events or incidents.

Amazon SNS has helped my team respond faster, improved reliability, and saved time. Specifically, because of it, we are able to identify events as soon as possible. It saves our time and we can also process them as soon as possible.

I chose that rating for Amazon SNS because, as I mentioned, you also need SQS, so it is a two-service job. It also does not provide filtering and routing, there is no message ordering, and it does not provide a retry mechanism.

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.

I have been using Amazon SNS for two to three years. I am a customer of the solution.

It is a scalable solution.

The server team in my company uses Amazon SNS. I am not sure about the configuration part of the solution.

The initial setup of Amazon SNS was easy.

The solution is deployed on the cloud services by AWS.

One can use the tool for free.

I would recommend the product to others since it is a free solution that provides notifications. With the help of your mobile and email, you can easily monitor and track the activities in your user environment or back-end.

I rate the overall product an eight out of ten.

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. 

Message flow could continue to improve. 

Messages should flow through a gateway without the need for a mediator. The gateway could check security and vulnerability before transferring messages to the receiver side. 

I have been using the solution for a few years. 

The solution is very stable in terms of sending notifications. I rate stability a nine out of ten. 

The scalability is good and is rated a nine out of ten. 

The solution is hassle free so there isn't much need for support. If flaws do happen on the AWS side, we just backup, delete, and recreate the service. 

Support is good and easily resolves any issues with backups. Support is rated a nine out of ten. 

Positive

The setup is easy, takes less than ten minutes, and is rated an eight out of ten. 

The solution has no up-front costs because you pay based on the number of messages you publish. If you don't publish messages, then you don't pay. 

The pay-as-you-go model is a very nice option compared to the model for other services like VPCs, Load Balancer, and IPS DVs. There is no need to provision use by the year, month, or minute. 

Pricing is rated a ten out of ten. 

The solution functions as a single message service like RabbitMQ.

IBM MQ has problems because it is a long process to create and it is much slower than the solution. 

Compared to other products, the solution is the best messaging service available. I rate the solution an eight out of ten. 

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.

The most valuable feature of Amazon SNS is speed. It's really fast. 

In future releases, I want to see if the platforms that SMS can reach. It would be a good way to improve it. More platforms to be able to use it.

I have been using it for a month. I use the latest version.

I would rate the stability a ten out of ten. 

It is very scalable. I would rate the scalability a ten out of ten.

The customer service and support are good. 

Positive

The deployment is pretty easy. It is software as a service. 

I have seen an ROI. 

The pricing is very cheap. 

Have a developer ready to know what he's doing, and pretty documentation, really. As soon as it's really pretty much straightforward for a developer to use.

Overall, I would rate the solution a ten out of ten. 

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 have been using this solution for approximately one year.

The solution is stable, but the documentation is not good enough. In addition, the configuration level of any service in AWS requires a significant amount of knowledge. For example, even a mobile engineer that wants to create a server in Elastic Beanstalk needs a high level of expertise.

It is a scalable solution. It provides support and makes it easy to enlarge your virtual machine in AWS and Elastic Beanstalk. It's hard to get it to run, but once it's running, it works.

The initial setup was complex and not easy. I rate the initial setup a two out of ten. However, after the setup, everything runs smoothly.

It took four months to deploy and create a production level with API for our mobile application. Because we create our Java-based server in Elastic Beanstalk, we purchase a domain and create a certificate, but there is no good UI to manage our certificate in the system. This means we need to use the call to command line tools. It's very old-fashioned.

The pricing is the same across regions. For example, the solution costs the same in Turkey, France and Germany. It would be good if pricing were tailored by region.

Pricing is important to us. AWS has different kinds of support for startups and individual developers. We always choose the most supporting platform. For example, AWS gave us $1,000 for two years. We proceeded with it and decided that we would learn how to build our product in AWS in those two years.

I rate this solution an eight out of ten.

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.

The mobile push notifications are the most valuable. Previously, we used to use Firebase Cloud Messaging (FCM) for this functionality. It is a Google service for sending push notifications. We used to run into problems while sending notifications to iOS devices but SNS made it a lot better. I think FCM just added that functionality while we were moving to SNS cause under the hood, SNS is actually using FCM. 

A major advantage of using SNS though is that we can see all the metrics on our AWS account itself, which makes it a lot easier instead of using a third-party service for this particular functionality.

A major issue with AWS as a whole is that it has a lot of services that do the same thing, and people get confused about which one to use in which scenario. Previously, we used to use SNS for connecting microservices. SNS has around six types of subscribers. We can subscribe to Lambda, HTTP, HTTPS, SMS, email, and push notifications. We used to use HTTP endpoints and Lambda for connecting to microservice systems. About a year ago, AWS released EventBridge, which is a better service for connecting microservices.

I have been using Amazon SNS for about two years now.

It has never crashed until now. I did not face any issue as far as SNS is concerned. There are cases where messages are lost, and they are not sent. If you have not set up a dead letter queue, then you would just lose those messages. Initially, I did not know about the dead letter queue, but eventually, I set it up. It is a lot more secure now. Even if the messages are not sent, we can get all those messages in a queue so that you can do whatever you want with it.

Another thing is that they have recently added 100% CloudWatch support. Basically, if you just add CloudWatch support, it logs each and every message that you get in the SNS system. If you are sending a single message to 10 different subscribers, CloudWatch will have 10 different logs for each of those subscribers. If a single message fails, you get the entire log of what happened. It is a bit costly though especially when you have thousands/millions of subscribers out there but it is a very solid feature. It allows us to get feedback on whatever went wrong in any incident.

It is automatically scalable because AWS handles the scalability for you. You don't have to do anything about scaling the service in any way. 

It is a part of the serverless architecture. All services that are a part of the serverless architecture are auto-scaled.

I never needed to use technical support for this particular service.

We can set it up in multiple ways. We can just use the AWS console to set it up, and it is very easy to set it up that way. However, since we're an enterprise, we had to set it up using a Cloudformation template. It was a bit more complex than using the console, but still, I would say it was a lot easier than any other service. The deployment took around 15 minutes.

This product does not require any kind of deployment plan. You use a cloud formation template to create the initial topics. After that, you just need to add subscribers to the topic, which can be done in many ways (even using the SDK).

You don't need a specific team to handle SNS itself. It's a fairly easy service to manage.

Since moving to SNS push notifications, we have had a lot better coverage. Previously, we could not send push notifications to iPhone devices. There was some issue with FCM while sending notifications to iPhones. After we moved to SNS, we are were able to send push notifications to iPhone devices. It works perfectly fine.

The pricing of push notifications and email services is quite fair but if you're planning to use it for sending SMS, then it's a bit on the costlier side. Maybe, It is because we don't have proper providers in my country.

I would say that going through the AWS pricing page would be the best solution to find the exact pricing for the services you need.

People should know when to use this solution. With so many AWS products out there, people are not sure which product to use in which scenario. SNS should be used only when you want a server-to-client connection, not when you need a server-to-server connection. For a server-to-server connection, you can use EventBridge. If you want a server-to-client connection and a one-to-many or many-to-many connection, you should use SNS. If you want a one-to-one connection, you should use SQS. You can go through the entire documentation and see if your particular use case requires you to use SNS or not.

Finally, I would say, I'd rate Amazon SNS a nine out of ten. In my tenure of using it for two years, it has helped me in a lot of ways. It is a lot more solid than similar tools out there.

We use this solution for its notification service alert functionality.

We have found the key feature of this solution to be the simplicity of sending out notifications.

We would like the integration with third party applications to be improved within this solution.

We have been working with this solution for around four years.

We have found this solution to be quite stable.

We believe this to be a scalable solution, but have not needed to increase our usage level to date.

We have found the customer support for this solution to be pretty good.

The initial setup of this solution was very straightforward, but there were challenges in integrating with third-party applications.

We implemented this solution in-house.

We would rate this solution an eight out of ten.

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.

We would like to have the option when someone leaves the organization or moves to another team, to remove notifications. Currently this needs to be done manually by the company admin. 

Secondly, we would like to separate notifications for instances when there are multiple jobs in progress and to be able to create specific alerts for new jobs that are started. 

I have been using this solution for five years. 

This is a stable solution. I have not faced any issues so far. I would rate it a nine out of ten for stability.

This is a scalable solution. We can create as many topics as we want. I would rate it a ten out of ten for scalability. 

We have not needed to contact support. We are site reliability engineers and if we encounter any issue, we figure it out ourselves. We do research and try to come to a solution. 

It is straightforward if you have knowledge of AWS services. A layman or somone new to AWS will not know what to do. I would rate the set up a ten out of ten. 

I would rate this solution a ten out of ten. It is user friendly and broadly used in the market. 

We use this solution for the communication lines between departments in our organization.

There are 300 people using SNS in my organization. They are mostly developers.

It's a simple communication service that allows us to communicate with customers.

There could be more integration with other solutions. Right now, I can communicate in five different ways within a minute. I would like there to be more options for integration, like with Slack or Microsoft Teams for example.

I have been using this solution for three years.

It's stable.

It's scalable.

I would rate their technical support three out of five.

The initial setup was very easy. I would rate the setup four out of five.

The implementation was done in-house.

Their pricing is competitive. I would rate the cost four out of five.

I would rate this solution nine out of ten.

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.

Push notifications are the most valuable. I have mostly used push notifications for my system. Amazon SNS supports all devices for push notification services. It supports iOS, Android, and Windows notifications. 

It provides reliable push notification services. We have queues, and we can track which notifications have failed or had some issues. We can then figure out the issue. We can also debug the issue because of which our push notification didn't reach the end users.

I recently worked with Firebase, and it provides an option to create a marketing campaign with a title and a specific image to inform our audience about something. We just design the campaign and then use the push notifications. It would be good if Amazon also adds a similar feature.

I have been developing products for five to six years. I have been working with Amazon SNS for four years.

It is the most stable product in the market.

It is scalable. If you are a startup, they provide a free quota, and after that, they start charging. It is scalable for our needs. We pay based on our usage. The more users we add on, the more we pay.

We have been using this notification system for four years. Currently, we don't have any plans to expand our usage.

I have not used their technical support.

I have been using Google Firebase for two years. In one application, I was using Firebase Realtime Database, so we preferred to use their real-time notification as well. Firebase does the same thing and sends notifications to subscribed devices.

With Firebase, we use real-time messages for push notifications, whereas with Amazon, we use Amazon SNS. I found Amazon SNS to be more stable than Firebase. Firebase provides only push notifications, whereas Amazon SNS provides emails, mobile messages, and push notifications. It is a hub of many things. Therefore, it is good to use one solution for multiple things.

You can easily create services. It is a very simple process.

It was a quick deployment. We bought a service that we can consume within our service. We can have a microservice and put our credentials on a server, and then we can send notifications to our subscribers by using that specific key. I also manage or maintain it on my own.

It is the cheapest solution in the market. It is on a monthly basis. After a month, you are build based on your usage. There are no additional costs to the standard licensing fees.

It is a good service. I would recommend it to my colleagues if they want to implement push notifications with SNS. Overall, I am very happy with this service.

I would rate Amazon SNS a ten out of ten.