Troubleshooting CrowdSec Error Parsing SQS Messages No Records Found In S3 Notification

This article addresses a common issue encountered while using CrowdSec with Amazon S3 and SQS: the “Error while parsing SQS message: no records found in S3 notification.” This error typically arises when CrowdSec fails to properly interpret SQS messages containing S3 notification events. This comprehensive guide will explore the root causes of this issue, provide step-by-step troubleshooting instructions, and offer solutions to ensure seamless log processing. Understanding the intricacies of SQS message parsing and S3 notification formats is crucial for maintaining robust security monitoring with CrowdSec. Let's dive deep into how to resolve this error and optimize your CrowdSec setup.

What Happened?

The issue arises when configuring CrowdSec to ingest logs from S3 using SQS notifications. Specifically, when the sqs_format is set to s3notification, CrowdSec encounters an error during the parsing of the SQS message. This indicates that the expected S3 notification format is not being correctly identified within the SQS message body. The debug logs reveal that messages are being received from SQS, but the parsing process fails due to the absence of S3 notification records.

The user configuration involves setting up an S3 data source with SQS integration, utilizing the use_time_machine feature and specifying the SQS queue details. The initial configuration snippet looks like this:

source: s3
use_time_machine: true
sqs_format: s3notification
polling_method: sqs
sqs_name: https://sqs.eu-west-3.amazonaws.com/ACCOUNTID/example-queue-name
aws_region: eu-west-3
labels:
 type: sqs

Despite this configuration, CrowdSec logs display the following error messages:

time="2025-07-08T13:08:11Z" level=debug msg="Received 5 messages from SQS" method=sqsPoll queue="https://sqs.eu-west-3.amazonaws.com/ACCOUNTID/example-queue-name" type=s3
time="2025-07-08T13:08:11Z" level=error msg="Error while parsing SQS message: no records found in S3 notification" method=sqsPoll queue="https://sqs.eu-west-3.amazonaws.com/ACCOUNTID/example-queue-name" type=s3

Commenting out the sqs_format parameter to trigger the fallback mechanism did not resolve the problem. To further investigate, the user manually inspected the SQS messages using the AWS CLI:

aws sqs receive-message --max-number-of-messages 1 --queue-url https://sqs.eu-west-3.amazonaws.com/ACCOUNTID/example-queue-name

The output revealed that the SQS message encapsulates an SNS notification, which in turn contains the S3 event data. This nested structure is crucial for understanding the parsing failure. Specifically, the Message field within the SQS response holds a JSON string that represents the SNS notification, and this JSON string contains the Records array with S3 event details.

{
 "Type" : "Notification",
 "MessageId" : "REDACTED",
 "TopicArn" : "arn:aws:sns:eu-west-3:ACCOUNTID:REDACTED",
 "Subject" : "Amazon S3 Notification",
 "Message" :
 "{\n \"Records\":[{\"eventVersion\":\"2.1\",
 \"eventSource\":\"aws:s3\",
 \"awsRegion\":\"eu-west-3\",
 \"eventTime\":\"2025-07-08T13:00:08.276Z\",
 \"eventName\":\"ObjectCreated:Put\",
 \"userIdentity\":{\"principalId\":\"AWS:REDACTED\"},\"requestParameters\":{\"sourceIPAddress\":\"REDACTED\"},\"responseElements\":{\"x-amz-request-id\":\"REDACTED\",
 \"x-amz-id-2\":\"REDACTED\"},\"s3\":{\"s3SchemaVersion\":\"1.0\",
 \"configurationId\":\"REDACTED\",
 \"bucket\":{\"name\":\"REDACTED\",
 \"ownerIdentity\":{\"principalId\":\"REDACTED\"},
 \"arn\":\"arn:aws:s3:::REDACTED\"},
 \"object\":{\"key\":\"AWSLogs/REDACTED/elasticloadbalancing/eu-west-3/2025/07/08/269104449425_elasticloadbalancing_eu-west-3_app.REDACTED.REDACTED.log.gz\",
 \"size\":2178,\"eTag\":\"REDACTED\",
 \"sequencer\":\"REDACTED\"}}]}\