SQS
Last updated: Nov 3, 2026
Rationale
Amazon SQS (Simple Queue Service) is the service that Fluid Attacks uses for message queuing in the cloud. With it, a producer can send work to a consumer and continue without a wait for the result. Thus, the queue holds traffic peaks, and the consumer does not get too much load or lose messages.
Fluid Attacks chose Amazon SQS over other alternatives for these reasons:
- It is a fully managed serverless service. Fluid Attacks does not provision or scale brokers, and it pays for each request.
- It complies with many certifications from ISO and CSA. Many of these certifications make sure that the entity uses best practices for secure cloud-based environments and information security.
- It supports FIFO queues with message groups and deduplication. Thus, the consumer processes the events of one entity in sequence, and a send that occurs again does not make duplicates.
- It is a native event source for Lambda. This includes partial batch responses, which let a consumer try again only the messages that failed.
- It supports dead-letter queues with redrive policies. Thus, SQS moves a message that continues to fail to a different queue for inspection. The message does not block the queue and does not disappear.
- It supports server-side encryption with KMS.
- It sends queue metrics to CloudWatch, for example, the age of the oldest message and the number of visible messages. Fluid Attacks uses alarms on these metrics to find consumers that do not process messages.
- Fluid Attacks can write its resources as code with Terraform. An in-house Terraform module creates the queues of Fluid Attacks. This module applies the same retention, visibility timeout, and dead-letter conventions to all the queues.
Alternatives
Fluid Attacks does not evaluate alternatives at this time. SQS is the queue that Lambda consumes natively. EventBridge already does the scheduling and event routing tasks that SQS does not do.
Usage
Fluid Attacks uses Amazon SQS for these tasks:
- Hold the audit and usage events that Tracks receives until a Lambda consumer writes them to Aurora (refer to Platform audit logs). A FIFO queue with a message group for each entity keeps the events of each entity in sequence.
- Hold the GitLab webhook events for the GitLab bot and the merge request reviewer of Fluid Attacks. Thus, the webhook receiver answers immediately, and a worker processes each merge request in sequence.
- Hold the dead-letter queue of the DynamoDB Streams triggers of the Fluid Attacks platform. If the Lambda invocation of a stream record fails, the queue keeps the record for inspection at a later time.
- Hold the batches of the runtime agent until a scheduled job of the Fluid Attacks platform processes them. This queue is not a Lambda event source, because its batches are too large for a Lambda invocation.
Fluid Attacks does not use Amazon SQS for these tasks:
- Scheduling of recurrent workloads or event routing between AWS services. Fluid Attacks uses EventBridge for these tasks.
- Long jobs or jobs that use much CPU. Fluid Attacks sends these jobs to Batch.