Amazon SNS Reviews

Amazon SNS is used for application alerts to notify admins when errors occur. It is implemented in data pipelines to trigger Lambda functions when new files land in S3. Amazon SNS is also used in microservices communication and user notification, as well as in IoT integration.

In our event management platform, Amazon SNS notifies the faculties. Amazon SNS is used in our applications, including ERP sites and other projects for institution operations.

Amazon SNS helps with microservices decoupling and SaaS scalability in our projects. When Lambda triggers, a proper notification is provided to the faculty or student, which is generated automatically due to the Lambda function.

Amazon SNS has many features, including message filtering, multi-protocol support, security and compliance, and global reach. Beyond Lambda triggers and microservices communication, Amazon SNS shines with all these features. It is not just a notification tool; it is a versatile backbone for an event-driven system.

Amazon SNS has impacted our organization positively due to all the notifications. For example, when a student uploads a file to Amazon S3, Amazon SNS immediately publishes an event that triggers a Lambda function, which scans the file for security, processes metadata, or even sends a notification to faculty. This automation ensures real-time processing without manual intervention, and it is something emphasized in training sessions as a practical DevOps workflow.

Amazon SNS is strong, but there are a few areas where it could be improved. These areas include a better dashboard and user interface with more intuitive monitoring and visualization of topics and subscriptions, granular policy controls, compliance templates, cost transparency, and advanced retry logic.

Additional areas for improvement include enhanced monitoring tools with a built-in dashboard and real-time message flow visualization to help track delivery more easily, and simplified debugging with clearer error messages and diagnostics when subscription fails to reduce troubleshooting time.

I have been using Amazon SNS for more than one and a half years.

Amazon SNS is very stable.

Amazon's scalability is very strong. It provides massive throughput, supports millions of messages per second, and ensures real-time communication even during traffic spikes. Messages are replicated across multiple availability zones for durability and reliability. Amazon SNS scales automatically with demand, so no manual provisioning is required. It integrates seamlessly with auto-scaling groups, CloudWatch alarms, and AWS Lambda, making it ideal for microservices and serverless workflows.

The customer support for Amazon SNS has been solid overall. The quality depends on the level of engagement chosen.

Before adopting Amazon SNS, different approaches were experimented with, including manual email and SMS alerts. Initially, custom scripts that sent emails or SMS directly through Amazon SES or third-party gateways were relied upon. Direct Lambda invocations were also used in some cases, where services called Lambda functions directly. While functional, this created tight coupling between services and made the architecture harder to maintain. Amazon SNS was adopted due to the scalability, decoupling, reliability, and cost-effectiveness.

Amazon SNS was very straightforward in terms of pricing and setup. It is purely pay-as-you-go, charged based on the number of messages published and delivered with different rates depending on the protocol. There is no upfront setup cost. Topics and subscriptions were simply created directly in the AWS console or via CLI.

A clear return on investment has been achieved after adopting Amazon SNS for automation and microservices communication. Time is saved because manual monitoring and alerting used to take 30 to 60 minutes per incident, whereas with Amazon SNS plus Lambda automation, responses now happen in seconds, cutting operational overhead by 40% to 50%. Additionally, fewer errors occur because human error in missed alerts or delayed responses has dropped significantly. With Amazon SNS fan-out to multiple subscribers, approximately a 70% to 80% reduction in errors has been achieved compared to manual workflows.

Several alternatives were evaluated before settling on Amazon SNS. These alternatives include Amazon SQS (Simple Queue Service), Amazon SES (Simple Email Service), and third-party tools such as SendGrid, Mailgun, and Brevo.

Start small and scale fast by beginning with a simple use case, such as triggering a Lambda on file upload. Once reliability is observed, expand into multi-service fan-out. Do not allow every subscriber to receive every message; attribute-based filtering saves compute time and reduces cost. Logging and monitoring are essential as they make compliance and troubleshooting much easier down the line. Apply IAM policies and KMS encryption so that only trusted producers and subscribers interact with your topic. This review has been given a rating of 9.

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. 

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.

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. 

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.