What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using Amazon SNS for about two years now.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
I never needed to use technical support for this particular service.
How was the initial setup?
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.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
What other advice do I have?
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.
Which deployment model are you using for this solution?
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)