Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Eoin: Hello, today we are going to answer the question, how do you use SNS? By the end of this episode, you will know how SNS compares to EventBridge and SQS. You'll know how to use it to send messages to customers, but also for microservice communication. We'll tell you what the costs and limits are, and also how you can integrate SNS with other services in AWS. My name is Eoin, I'm joined by Luciano and this is the AWS Bites podcast. This is the fourth episode in the series all about services for events and messages on AWS. We covered SQS and EventBridge in detail already, and today we're talking about SNS, the simple notification service. Luciano, would you like to tell us how would you describe SNS?
Luciano: Yeah, so based on how we categorize the other events and messages services, I will place SNS in the category of PubSub. So you have this Publish and Subscribe API. It's interesting because it can target what is generally called in AWS A2A, which is like application to application, but also something that they call A2P, application to person, which basically means that if you publish something to an SNS topic, then that message can be delivered also as an SMS or as an email or even a push notification. By the way, this is interesting because it feels like a little bit of a legacy feature because since this feature was available in SNS, we know that now we have other services that are more specialized to do that, like Pinpoint or even third parties that you would generally use for SMS or emails like Twilio or SendGrid or for push notification, probably you would use Firebase, Cloud Messaging. So it's interesting to see that, and we have to say that also SNS is one of the oldest AWS services. It's 12 years old, I believe now. So maybe this is a little bit of a legacy feature that was built there initially, but now you will probably use other services. So in terms of advantages, what do you think are the strengths of SNS compared to other services?
Eoin: I'd say that the main strength compared to things like EventBridge and some of the other services, again, simplicity, but also really fast delivery. I think we mentioned that in the last episode that SNS is typically lower latency. It's also push-based. You don't have any polling like you do with SQS. You can have subscribers that are notified immediately. So there's lots of really good things you can do with SNS. Typically what you're doing with SNS is fan out. You're taking a message and broadcasting it to multiple subscribers.
So the things you can do with it are like event-based communication across parts of microservice architectures, similar to what we discussed with EventBridge actually. So if you've got a fan out pattern, so if you want to have the kind of behavior we talked about with SQS, where you're sending message from one system to another, and you need that durability with SNS, you can do that, but get multiple consumers involved rather than a single consumer. So you can combine SNS and SQS. For example, in our e-commerce application, a new order arrives, you can send the event to your fulfillment service, the analytic service, and your billing or invoicing service. One of the other things you can do with SNS is send handle system alerts. AWS services will often send messages to SNS when certain things happen, like CloudWatch alarms or change state. That's how you get the notifications from CloudWatch alarms. And then you can take those alarm notifications, send them by email, or send them to a webhook or a Lambda function, which could then send it to Slack or Teams or wherever you want to receive those. It's also used for code pipeline notifications. And if you use AWS config for compliance, it can send SNS messages when the compliance date changes. So I think that's a pretty... That's those are the kind of things I would generally use SNS for. How would you describe the usage of SNS? We talked through this, I think, for EventBridge and SQS. What are the steps?
Luciano: Yeah, it's interesting because we will see that compared to what we described for EventBridge, using SNS requires a little bit more work, I would say. And that's because for instance, just for starting, you need to create a topic. And a topic is effectively the place, the channel where you're going to be able to publish messages. Once you create a topic, you can create a subscription on that topic. And a subscription basically allows you to say, somebody wants to receive the messages once they are published on this particular topic. And a subscription, sometimes it's something you need to confirm.
For instance, if you do a subscription that requires the destination to be an email or HTTP or endpoints that live in another AWS account, AWS will actually ask you to confirm that that subscription needs to be confirmed before it's actually activated. And sometimes, for instance, you can receive an email and you have to click a link on that email or there are APIs that you can use if you need to do that in an automated fashion. Then at that point, once you have a topic and a subscription, you can publish one or more messages to that topic and you can use either the publish API, which gives you one message, or the publish batch, which allows you to publish more than one message with one single request. And that's interesting. But another thing that is very interesting is that very often you need to also configure what are called access control policies, which are something very similar to IAM policies, at least they have the very similar structure. But those are basically the way you can authorize, for instance, certain users to publish to a specific topic or SNS itself to be able to deliver to a queue. So give SNS the permission to use the put message API to SQS. And you can also put different limitations in places. For instance, you could say for this particular topic, I only want subscription that deliver to HTTPS, for instance. So you can use all this feature to create restrictions on how messages are consumed, but also how messages are published to the topic. Are there other interesting details that are worth mentioning in terms of, I don't know, the user experience of creating messages and consuming them? If you remember with EventBridge, we were talking about rules and how you do pattern matching.
Eoin: And SNS has kind of a similar feature called message filtering. But the important distinction there is that message filtering is based on message attributes and not the message content itself. So it's more like a filtering on metadata. So it can be used to partition and filter messages. And that works pretty well, but it just doesn't have the flexibility that you have with EventBridge. It feels like we're comparing it with EventBridge quite a lot when we mention all these features. But one of the interesting ones is that you can you can have up to 12.5 million subscribers per topic in SNS. EventBridge doesn't give you anything like that. You generally don't need it, but you would have five targets per rule in EventBridge. Of course, you can have as many rules as you want. So then I guess we should talk about pricing. And it does seem like it's a little bit cheaper than EventBridge because it's about 50 cents for a million SNS requests. And then you've got additional costs for things like HTTP notification deliveries and email deliveries. So if you want to target those endpoint types, that's something you should look at. What about reliability? With EventBridge, you have DLQ. With SQS, you can have another Q, which is a DLQ. You get that with SNS too, right? But you also have other similar features like FIFO topics, which is quite a new one for SNS. Do you want to talk about what that can give you? Yeah.
Luciano: The only thing I know about that one, I haven't used it yet, but it's basically it allows you to push messages to FIFO queues and make sure that the order is respected in the process. So end to end, you will be able to pull messages from the queue with the same order that the messages were produced in the topic in the first place. This is as much as I know. I don't know if you have any more detail that is worth sharing about that one. Yeah.
Eoin: I think the feature is, I guess the important thing is that with SNS, FIFO, the only subscriber type is an SQS queue. That's the only one that makes sense. But yeah, it's really important, obviously, I guess if you have the kind of use case that you might normally use something like Kinesis or Kafka for, where you've got strict ordering with multiple subscribers. So it's a really good addition. A lot of people were very excited when that came out. We should also talk about, since we've been compared to EventBridge, how it compares to SQS. So you've got obviously multiple consumers and you don't have durability built in. So I mean, those are really headline differences between SNS and SQS, but they combine really well, don't they? So it's very common to see SNS with SQS subscribers. I think we covered when we were talking about SQS, that if you need the best of both worlds, you can just essentially glue them together and you've got queues on the receiving end, a topic on the publication end. And once you link the two, you can even have cross account SQS subscriptions from an SNS topic. So you can imagine how that would work in a microservices context when you have services deployed in different accounts or even across applications. Yeah, there are different patterns that you can probably achieve by just combining SNS and SQS.
Luciano: So that's a very common integration, I will say. In terms of comparison with EventBridge, we already mentioned a few points. I think there are other ones that are also very interesting. And we already said, for instance, that topics need to be created in advance. In SNS, while in EventBridge, you get a default bus, you can create new bus if you want, but you get something by default. So you don't necessarily need to provision any infrastructure with EventBridge. In SNS, a subscription is bound to a topic. So you say, I want to listen for messages published in this particular topic, while in EventBridge, you listen for messages in a bus, which is kind of considered less granular if you want because a bus is more general purpose, while a topic is more specialized, at least. This will be the most common conception, in my opinion.
And the reason why is because in a topic, when you subscribe, you generally get all the messages in that topic, while in EventBridge, you generally provide rules that will allow you to select only messages with a particular structure that you are interested in consuming. So EventBridge is generally, you have the common bus for everything, and you just select things that you are interested in by providing a pattern. With SNS, you select the specific topic that has the information you want. You can probably achieve something similar with filtering, but we already mentioned that SNS filtering, you can only filter on metadata and not the message content. So you will need to craft that metadata in advance for the rules that you expect if you want to use filtering to select a subset of the messages in the topic. Also, another interesting thing that we mentioned in the previous episode that EventBridge gives you AWS events or even third-party integration events, like Salesforce or stuff like that, while in SNS, you don't have any of that. It's up to you to publish something into the different topics. SNS is much faster. Typically, you have a latency of 30 milliseconds compared to something that can be around 500 milliseconds for EventBridge. So definitely, this is probably the killer feature that is going to make SNS win against EventBridge in certain scenarios. Like when you really need good latency, SNS is your choice. EventBridge has many supported targets, while SNS is a little bit more limited. We'll mention some of them in a second. And the other interesting thing, this is very cool feature that I really like from EventBridge, that when you do HTTP targets, you can define a template that allows you to change the structure of how the HTTP request is going to be sent. Instead, with SNS, there is a standard format and that's it. So you'll need to build your APIs to accept that format. Instead, EventBridge is a lot more flexible in that sense. Or you'd have to put a Lambda function in between, I guess, if you need to transform it.
Eoin: Exactly. And then you use that seamlessness. Yeah. Do you want to tell us something about the integrations then?
Luciano: Yeah.
Eoin: So we talked at the start about the consumer targeting versus application to application cases. So you've got SMS, mobile, push, and email. But in terms of service integrations, you can target SQS endpoints, Lambda, HTTPS endpoints, and Kinesis data, firehose. So that can be a sync for all of your events. And on the publication side, S3 notifications can target SNS. API gateway can target SNS. DynamoDB. Also, SES, EventBridge itself can target SNS. But in the same account only, whereas with EventBridge to EventBridge, it's much easier to do cross-account. And Step Functions, of course, can publish to SNS, because Step Functions can call any AWS API pretty much these days. So that, I think, covers the primary integrations you'd use. Obviously, a limited subset compared to EventBridge, but that's one of the trade-offs. And I think that pretty much covers all of the details on SNS. And wraps up this part of the series. Next focus will be on streaming, which is a different ball game and should be really interesting. Before we go, I just wanted to call out one article, which is going to be in the show notes, which is from Cloud or Not blog, and it compares SNS to EventBridge. I think it's a topic people are really interested in these days, so I'd recommend you take a look at that. So thanks for listening, and we will see you in the next episode.