Amazon Simple Queue Service (SQS) | Security and Reliability Flashcards
Are there any limits specific to FIFO queue attributes?
Security and Reliability
Amazon Simple Queue Service (SQS) | Application Integration
The name of a FIFO queue must end with the .fifo suffix. The suffix counts towards the 80-character queue name limit. To determine whether a queue is FIFO, you can check whether the queue name ends with the suffix.
How reliable is the storage of my data in Amazon SQS?
Security and Reliability
Amazon Simple Queue Service (SQS) | Application Integration
Amazon SQS stores all message queues and messages within a single, highly-available AWS region with multiple redundant Availability Zones (AZs), so that no single computer, network, or AZ failure can make messages inaccessible. For more information, see Regions and Availability Zones in the Amazon Relational Database Service User Guide.
How can I secure the messages in my message queues?
Security and Reliability
Amazon Simple Queue Service (SQS) | Application Integration
Authentication mechanisms ensure that messages stored in Amazon SQS message queues are secured against unauthorized access. You can control who can send messages to a message queue and who can receive messages from a message queue. For additional security, you can build your application to encrypt messages before they are placed in a message queue.
Amazon SQS has its own resource-based permissions system that uses policies written in the same language as AWS Identity and Access Management (IAM) policies: for example, you can use variables, just like in IAM policies. For more information, see Amazon SQS Policy Examples in the Amazon SQS Developer Guide.
Amazon SQS supports the HTTP over SSL (HTTPS) and Transport Layer Security (TLS) protocols. Most clients can automatically negotiate to use newer versions of TLS without any code or configuration change. Amazon SQS supports versions 1.0, 1.1, and 1.2 of the Transport Layer Security (TLS) protocol in all regions.
Why are there separate ReceiveMessage and DeleteMessage operations?
Security and Reliability
Amazon Simple Queue Service (SQS) | Application Integration
When Amazon SQS returns a message to you, the message stays in the message queue whether or not you actually receive the message. You’re responsible for deleting the message and the deletion request acknowledges that you’re done processing the message.
If you don’t delete the message, Amazon SQS will deliver it again on when it receives another receive request. For more information, see Visibility Timeout in the Amazon SQS Developer Guide.
Can a deleted message be received again?
Security and Reliability
Amazon Simple Queue Service (SQS) | Application Integration
No. FIFO queues never introduce duplicate messages.
For standard queues, under rare circumstances, you might receive a previously-deleted message a second time. This can happen in the rare situation when a DeleteMessage operation doesn’t delete all copies of a message because one of the servers in the distributed Amazon SQS system isn’t available at the time of deletion. This message copy can be delivered again. If you use standard queues, design your application to be idempotent (that is, no errors or inconsistencies occur if you receive a deleted message a second time).
