Amazon SNS

SNS is much cheaper and easier to integrate.

Amazon Simple Notification Service (SNS) is well integrated in AWS and has been there since the early days of public cloud. It is a cost effective and very inexpensive solution to meet the needs of event notifications and custom messaging. Wish to share that there is considerable number of developers who can easily build solutions using AWS SNS. So, training costs are minimal. Other solutions are emerging and we are seeing a great usage especially of Firebase notifications because of its very neat integration with open source cross platform hybrid app frameworks like ionic, xamarin. SNS needs to become better and should have plugin support for the mobile application developers using low code/no code tools too.

Amazon’s SNS is incredibly easy to set up compared to the more powerful, but complex, Kafka flavours.
SNS’s core advantages are –
· no setup/no maintenance
· either a queue (SQS) or a topic (SNS)
· various limitations (on size, how long a message lives, etc)
· limited throughput: you can do batch and concurrent requests, but still achieving high throughputs would be expensive
· SNS has notifications for email, SMS, SQS, HTTP built-in.
· no "message stream" concept

Overall, it would be the best choice to get into the concepts of Pub/Sub concepts as although it has limitations it can provide significant capabilities and solutions

I worked with Adobe Campaign 2 years ago and comparatively, SNS is way better and easier to integrate with. There's a lack of latency with SNS and better customer support. Easier to group with subscriptions and easier to work from the command line with the use of the SDK. All in all a superior product

No obvious difference. We chose AWS SNS, as we are an AWS EdStart company and built on the AWS stack already.

SNS helps in integrating with other AWS components which are used in development such as Lambda, APIGW, S3 and DynamoDb easily. If used with third party software like PagerDuty, it makes the development and integration more complex. It is used mostly for publishing and subscribing events which is better as compared to other third party softwares.

We use AWS and becasue Amazon SNS can be easily integrated with AWS.

Amazon Simple Notification Service and PagerDuty have been used by various organizations. Amazon SNS is ideal if you're within an AWS environment. PagerDuty is used when we are working outside of Amazon Web Services. Though PagerDuty is more expensive than Amazon SNS they do have better reporting capabilities in specific areas.

SNS is already integrated with other AWS services. I can reuse lists or topics.

We have looked at other service providers, including the local service providers as well, but Amazon SNS stood ahead of all in terms of service availability across the globe and cost-effective plans per notification SMS. Moreover, we can also use Amazon SNS along with other AWS services to create a better ecosystem, which definitely helps it to stand out.

Common confusion between SNS and SQS. SNS directs information to its subscribers without any effort on the subscribers or individuals' end. SQS gathers the information and then the individual has to almost go find it. They do similar things but in a space where information can cost you thousands of dollars in sales, the efficiency of SNS is better suited for my type of clients.

We have opted ultimately for AWS SNS once configuration was set topics and subscriptions setup. Site 24 and US Monitor are considerations to this product, but incur cost outside of Amazon, so not best for starting up for our needs.

The main reason we chose Amazon SNS is for easy integration with all the workflows in AWS. The other alternatives can be (and really are) best in specific points, but the main strength of SNS is that is one service of AWS, so we don't need to complicate things in our developments.

Our company prioritizes using AWS offerings unless there is a strong use case for using something within Azure. SQS is a similar service that solves different problems and we are using it in conjunction with SNS.

Our clients are mostly on AWS, so it was easy for us to use Amazon Simple Notification Service (SNS) and to integrate it with current applications.

We use EC2 instances to train ML model against a heavy volume of data. When the model is trained (i.e. loss reduces to a certain level), we push notification to all the stakeholders to notify them the new model is available. To achieve it, SNS is the most simple and cost effective way.

We use a lot of services from AVS, and it's easy to set up all services between each other.

Many products, including PagerDuty, can be used to notify stakeholders when alarms are triggered. SNS is only suitable for non-emergency email alerts, and integration with CloudWatch is its only advantage. If you want to be notified of an issue by email, SNS can be configured in seconds. It is not suitable for any of PagerDuty's other use-cases.

As a pub/sub system, SNS is somewhat similar to Apache Kafka. Queues may be suitable for some use-cases; Amazon SQS may be appropriate in these cases.

SNS is much more customizable compared to SES and allows for many more delivery methods. While it is better for email-based notification services, not being able to send notifications via SMS limits your app functionality considerably. Being able to switch message delivery types is an invaluable tool for any application deployment.

As I mentioned previously, I wish we had gone with a different service such as a Mixpanel or OneSignal as they are reputable in the space and are known for their strong support and documentation. AWS SNS was the way to go for us at the time we chose it due to the fact that we were getting into using AWS Microservices and felt it would be best to stay the course.