1. Introduction to SNS
SNS is Amazon’s simple notification service. It’s a web service that makes it easy to set up, operate, and send notifications from the cloud. It provides developers with a highly scalable, flexible, and cost-effective capability to publish messages from an application and immediately deliver them to subscribers or other applications. Amazon SNS follows the publish-subscribe or Pub Sub message messaging paradigm, with notifications being delivered to clients using a push mechanism that eliminates the need to periodically check or pull for new information and updates.
With simple APIs requiring minimal upfront development effort, no maintenance or management overhead, and pay-as-you-go pricing, Amazon SNS gives developers an easy mechanism to incorporate a powerful notification system with their applications. So the first thing you should really pick up from this SNS is a messaging service. Basically, you use SNS to receive messages about You can have Cloud Watch tied into it. You can configure an SMS to send you an email, a message to your phone, and so on. So SNS is a push mechanism. It pushes out messages as opposed to SQS, which pulls. So, when you set up an SQS, you have your EC, which are two instances that constantly pull or pull messages from the SQS platform. So this is where it’s going to come up in the exam.
They’ll say, “I’ve got this scenario.” Should I use SNS or SQS? And it’s all about whether or not you need to push messages out to people or whether you need to pull things from the queue. So just remember that going into the exam, push notifications to Apple, Google, Fire OS, and Windows devices, as well as Android devices in China, with Badu Cloud Push. Besides pushing cloud notifications directly to mobile devices, Amazon’s SMS can also deliver notifications via SMS text message or email. Furthermore, it can deliver to Amazon’s Simple Queue service provider to any HTTP endpoint, so keep that in mind. In the last lecture or a couple of lectures ago, we talked about using SQS to fan out across multiple queues. And basically, what you do is have SQS send a notification to SNS, and then that will push it out to other SQS queues. So you can combine SQS and SNS to design your applications to prevent messages from being lost. All messages published to Amazon SNS are stored redundantly across multiple availability zones. So let’s talk about topics. Topics in SNS allow you to group multiple recipients.
A topic is an access point for allowing a recipient to be dynamically subscribed to receive identical copies of the same notification. One topic can support deliveries to multiple endpoint devices. For example, you can group together iOS, Android, and SMS recipients. When you publish once, SMS delivers appropriately formatted copies of your message to each subscriber. So you don’t have to worry about formatting your SMS message separately for SMS and email. Amazon will do that for you depending on the type of device that you select as a subscriber to your SNS topic. So your SNS benefits are that it’s instantaneous push-based delivery. There’s no polling. There are simple APIs and easy integration with applications. There’s flexible message delivery over multiple transport protocols. It’s inexpensive; you pay as you go, with no upfront cost. A web-based AWS management console offers the simplicity of a point-and-click interface.
So with SNS versus SQS—and this is a popular exam topic—they’re both messaging services. In AWS, SNS pushes SQS polls or pools messages. And in terms of the pricing, your users pay fifty cents per one million Amazon SNS requests, or six cents per one hundred thousand notifications of deliveries over HTTP, seventy-five cents per one hundred notifications of deliveries over SMS, and then $2 per 100,000 notifications of deliveries over email. So, basically, the pricing is broken down based on your delivery mechanism as well as the number of requests. Okay? And that covers our SNS. Covers SNS? From an exam point of view, there’s not a lot of it in the exam. One thing I will show you in the next lecture is just how to set up a topic and then subscribe. The main thing that comes up in the exam is whether or not I think it’s when you’re sending email; I can’t remember exactly, but it’s talking about the data format of SNS, which is basically JSON. So if you are looking at different SNS data types, just remember that it is Jason, and we’ll go and take a look at that in the next level when we just set up a standard email message. Okay? So join me for the next lecture if you’ve got the time. Thanks a lot. Bye.
2. Creating an SNS Topic
Okay. Hello, cloud gurus, and welcome to this lecture on SNS. And I thought we’d just create a topic and then push some notifications out to that topic. So if you’re on your console, just go to SNS. And then you can see here that we have the option to create a new topic. So topics are basically like a subject, for example, and then you add subscriptions under this topic, and then anything that you publish to this topic will go out to your various subscriptions.
So let’s go in and create a topic name. We’ll call it my test SNS topic. Just cut and paste that, hit create, and there you go; you can see it’s created. There’s your Amazon resource name, the topic owner, the region that the topic sits within, and then the display name. So now that I’ve got this topic, it’s great, but it’s not going to do anything unless I create a subscription. So in here, you can see we’ve got an https email with Jason’s Amazon SQS and application. Now a topic that did come up in an exam was formatting, so just remember it’s not XML, it’s Jason. So let’s just go ahead and see what this actually looks like. The endpoint would be my email address, which is [email protected], and if we hit subscribe, there we go; it’s saying a confirmation message will be sent to the subscribed endpoint.
Once the subscription has been confirmed, the endpoint will receive notifications from this topic. So you always have to confirm your subscription. You can’t just add people, create a mailing list, for example, and then just start randomly spamming people. It won’t actually push out SNS messages until that subscriber has confirmed. So do you remember that when it comes up in the exam, subscriptions will expire after three days if they are not confirmed? So if I go across here, I’ll be able to see my SNS topic, and here it is, in JSON format. So we’ve got our key-value pairs. So, our subscription confirmation type, message ID, token, topic, Amazon resource name, and the message you’ve chosen to subscribe to this topic. Here’s the subscribe URL; it’s a timestamp and a signature, so just click on the subscribe URL, and there we go. It just basically says that I’ve now subscribed to the topic. Here it says “pending confirmation” if I just refresh the page and then open up my topic, which was my SNS topic.
You can see now that I’ve got a subscription ID, so I can go ahead and publish another message. I can say this is a second test. Hello world. So you set your TTL here. So the TTL is the time to live, and it’s the number of seconds since the message was published. When you use TTL, messages that remain undeliverable for the specified time will expire. So if you set a TTL of, say, 300 seconds, or five minutes, that basically says if this is not delivered within that five-minute period, it will expire. So I’m just going to leave that blank for now, and you can check here. You’ve got two options. Use the same message body for all protocols, or use different message bodies for different protocols. So here you could select this, and then you could change your protocols and then enter in your message so it would be in a different format. Essentially, I’m just going to say that it’s annoying that it deletes itself. If you select that button, I’m just going to say, “Hello, world.” Two, hit “publish message.” And then, if we come back here, you can see my inbox. I just got it.
This is a second test, and it’s in JSON format again. As a result, the key value pair type is notification. Here’s your message ID, your topic, Amazon resource name, subject, message timestamp, signature version, your signature, the signing certificate, URL, the unsubscribe URL, and then your message attributes. Surprisingly, these key value pairs can occasionally appear in the exam. So send yourself a couple of messages and read them to get a feel for them. It’s always going to have a subject, a message, and a timestamp. It’s always going to have a signature, and it’s always going to have the topic Amazon resource name. We’ve got our message ID and our Amazon resource name. We’ve also got our signing certificate URL, which is our signing certificate. And then we’ve got our unsubscribe URL. If we click on this, it will unsubscribe us from that topic. So that’s it. That’s all you really need to know for this lecture. If you do have any questions, please let me know. And that’s pretty much all you need to know for this section of the course. If SNS does come up and something hasn’t been covered by our course, please let me know and I’ll add it as always. but if not, please move on to the next section. Thank you.
3. SNS Summary
So I just really want to give you some exam tips. The first thing to remember is that SNS consists of a topic, and inside each topic you have different subscribers. Each subscription method can be a different protocol. It could be HTTP, it could be email, it could be SQS, etc. And every time you see an exam question where it’s talking about the need for push-based delivery, I want you to think of SNS.
The other thing that can and does come up is what protocols are used. To summarize, it was http://www.amazon.com/sqs/json/ followed by application. And then the final thing was that messages can be customised for each protocol, which you saw in our practical demonstration. So that’s it for Amazon SNS. If you do have any questions, please let me know. Please let me know if anything comes up in the exam that I haven’t covered. And if you have the time, feel free to move on to the next section. Thank you.
