Security Considerations for SNS – AWS Security Fundamentals – SCS-C02 Study Guide

Security Considerations for SNS

The following points present some of the security considerations and best practices when using SNS:

• Apply only the permissions needed to fulfill the duty of the job (the principle of least privilege):
  • An application sending and receiving messages from one or more topics doesn’t need administrative permissions for those topics, such as the ability to create additional topics or modify or delete the topic. Leave those privileges to another specialized role rather than granting full access to all users and roles.
• Enforce encryption for data in transit for messages:
  • Use the secure HTTPS rather than the insecure HTTP when sending messages from an SNS topic to avoid becoming vulnerable to man-in-the-middle attacks.
• Use VPC endpoints to access Amazon SNS:
  • Route your requests from hosts in your VPC through VPC endpoints rather than the public internet; this limits topic access to only the hosts within a particular VPC.

Simple Queue Service (SQS)

The managed queue example at the beginning of this section referenced a queueing system wherein requests could be held until they were ready to be processed. This type of queue enables you to break apart or decouple your application in a cloud-native manner.

The simplicity of the SQS setup and use makes it appealing to many developers and organizations. SQS comes in two flavors: standard queues and First In First Out (FIFO) queues. Standard queues allow at least one-time delivery, whereas FIFO queues are capable of exactly one-time delivery of messages placed in the queue. Messages get processed exactly once but delivery can happen multiple times due to technical issues or high loads. The other significant difference between the two types of queues is that with FIFO queues, the messages are processed in the exact order in which they are received. A standard queue makes its best effort to try and preserve the ordering of the messages received. However, if a message is received out of order, it will not shuffle or re-order the messages to retain the original message order.

SQS is a distributed queue system spread out across different regional nodes. This is one of the design features that provides SQS its benefits, such as high scalability, availability, reliability, and durability. SQS also allows Server-Side Encryption (SSE), either through the service key provided by AWS via KMS or a custom key provided by you. You can also control access to the SWS via access policies that have access to the messages that are either produced or consumed.

Messages are placed in the SQS queue by producers. They are then distributed across the queue components for redundancy as shown in Figure 2.7. The graphic depicts two different application components inside three different containers. The first is a disparate application (the producer) that produces the messages and sends them to the queue. The second and third components are the two consumers that read the messages from the queue. The SQS service is distributed throughout different Availability Zones in a region, and each message is stored at least twice on different nodes for redundancy purposes.

Figure 2.7: SQS distributed queue

When the consumer is ready to process a message, it uses either a long or short polling technique to see if there are any messages in the queue for processing. If the consumer detects one or more messages it can process, it pulls down (or processes) the messages. The messages are only flagged, and the visibility timeout begins. Once the consumer has successfully processed the messages and deleted them, they are removed from all nodes of the distributed queue.

Messages must be deleted by the consumer once they have been processed successfully. Because of the nature of the distributed system that SQS runs on, once a consumer has pulled down a message for processing, it is marked so that no other consumers can pull it down. There is a timeout period in which the consumer must acknowledge that the message was processed. If the SQS service never receives this acknowledgment, the flag is removed from the message, and it becomes available for another consumer to process.

Note

There are other queueing services offered by AWS, such as open-source message brokers or Amazon MQ, which is a managed service. This chapter will not go into great detail regarding these services since the basic concepts of queueing tasks are the same. Still, this service offers more advanced features, such as high availability and durability of messages across regions.