We all know by now that AWS provides a plethora of services designed to help you with developing a rich set of cloud-ready applications; but with so many different services to choose from, how do you make the right set of choices to begin with? That's exactly what we will be learning and exploring in this section, starting with a brief understanding and comparison of a few commonly used AWS messaging services, as depicted in the following diagram:

• Amazon SNS: Amazon SNS, or Simple Notification Service, is a synchronous, managed service that provides the end user with the ability to deliver or send messages to one or more endpoints or clients. This works by using a Publisher–Subscriber-like model, as depicted in the following diagram:

One or more publishers or producers post a message to a corresponding SNS topic without knowing which subscribers or consumers will ultimately consume the message. The producer also doesn't wait for a response back from the consumers, thus making SNS a loosely-coupled service. It is the consumer's task to subscribe to the topic and get notified of the incoming messages. SNS supports a variety of consumer implementation options, such as email, mobile push notifications or SMS, HTTP/HTTPS notifications, and even Lambda functions.

• Amazon SQS: Amazon SQS, or Simple Queue Service, on the other hand, is an asynchronous managed service that provides users with the ability to push and pull messages from a queue. Here too, one or more producers can be used to push messages into the queue, which a corresponding set of consumers on the other end consume and process the messages one at a time. An important point to note here is that, unlike its counterpart, SNS, where the consumers are notified of a new message, here, the consumers have to poll the queue in short intervals of time for newer messages. Once a message is found, the consumer has to process it and then delete it from the queue. The process is shown here:

• Amazon Kinesis: Amazon Kinesis functions a lot like Amazon SQS; however, it is fundamentally designed and optimized for high-throughput data writes and reads. Here, instead of a queue, you are provided with a stream that consumers can use to read from multiple times. The stream is automatically trimmed after a span of 24 hours, so, unlike your consumers from the queue, here you are not required to delete the messages once they are processed:

Similar to Amazon Kinesis, AWS also provides a streaming functionality with DynamoDB as well, called DynamoDB streams. Using this feature, you can basically enable real-time changes to certain items within your tables in the form of a stream. And, finally, you also get the standard request–reply model of messaging using a combination of Amazon API Gateway, ELBs, AWS Lambda, and other services. This mode of communication is also synchronous in nature and can be used to fit a variety of use cases, as per your requirements.

Keeping these basic differences in mind, let's now move forward and learn more about SNS.