Well, that was really quite a lot to learn and try out, but we are not done yet! There are still a few things that you ought to try on your own with SNS, as well as with SQS. First up, Amazon SNS mobile push notifications.
We have already touched upon the fact that Amazon SNS can be used to send notifications to a variety of subscribers, including HTTP, HTTPS endpoints, Amazon SQS, and AWS Lambda, but one other key feature recently added is SNS' ability to push notifications directly to your applications on mobile devices. This is called SNS mobile push notifications and, as of now, SNS supports the following push notification services:
- Amazon Device Messaging (ADM)
- Apple Push Notification Service (APNS) for both iOS and macOS
- Baidu Cloud Push (Baidu)
- Google Cloud Messaging (GCM) for Android
- Microsoft Push Notification Service (MPNS) for Windows Phone
- Windows Push Notification Services or Windows Notification Service (WNS)
It's pretty easy and straightforward to get started with mobile push notifications. All you need is a set of credentials for connecting to one of the supported push notification services, a device token or registration ID for the mobile application and device itself, and an Amazon SNS configured to send push notification messages to the mobile endpoints.
The other important feature worth trying out is the configuration of server-side encryption for your Amazon SQS queue. You can leverage SSE to encrypt and protect data stored in your queue, however, this feature is only available in the US East (N. Virginia), US East (Ohio), and US West (Oregon) regions at present.
Encrypting the queue can be done at the time of the queue's creation, as well as after the queue has been created. Old messages present in the queue, however, are not encrypted if the SSE is switched on in an existing queue.
You can configure SSE for an existing queue simply by selecting it from the SQS dashboard and selecting the Configure Queue option present in the Queue Actions drop-down menu. Here, check the Use SSE checkbox to enable the server-side encryption on your queue. At this time, you will be prompted to select a customer master key (CMK) ID which you can leave to the default value if you do not have an CMK of your own. Once done, set a duration for the Data key reuse period of between 1 minute and 24 hours. Click on Save changes to apply the recent modifications to the queue.
You can read more about SSE and how to enable it on a new queue, at https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-create-queue-sse.html.
Last, but not the least, I also recommend that you try out the dead letter queue feature provided by Amazon SQS. Dead letter queues are nothing more than queues that you create for storing messages that could not be processed by your application's main processing queue. This comes in really handy when you need to debug issues in your application or the messaging system. However, it is very important to note that the dead letter queue of a standard queue is always a standard queue, and the same applies for a FIFO-based queue as well.
You can configure any queue within your account to be a dead letter queue for another queue by simply configuring the Redrive Policy of your application's main queue. To know more about dead letter queues and how they work, check out https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html.