SQS Audit Logging with CloudTrail: Track API Calls (2026)

SQS audit logging with CloudTrail is less about what messages are being sent and more about who is telling SQS to send or receive them.

Let’s see this in action. Imagine you’ve got a queue named my-processing-queue and you want to know who’s been messing with it. You’ve got CloudTrail enabled and logging to an S3 bucket named my-audit-logs-bucket.

Here’s a snippet from a CloudTrail log file in S3, showing a SendMessage API call:

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "AIDAJ3XYZEXAMPLEID",
        "arn": "arn:aws:iam::123456789012:user/developer-jane",
        "accountId": "123456789012",
        "accessKeyId": "AKIAIOSFODNN7EXAMPLE",
        "userName": "developer-jane"
    },
    "eventTime": "2023-10-27T10:30:00Z",
    "eventSource": "sqs.amazonaws.com",
    "eventName": "SendMessage",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "203.0.113.25",
    "userAgent": "aws-sdk-java/1.11.500 Linux/5.4.0-107-generic java/11.0.12",
    "requestParameters": {
        "messageAttributes": {},
        "messageBody": "{\"order_id\": 12345, \"status\": \"processing\"}",
        "queueUrl": "https://sqs.us-east-1.amazonaws.com/123456789012/my-processing-queue",
        "delaySeconds": 0,
        "messageDeduplicationId": "dedup-12345-abc",
        "messageGroupId": "group-12345"
    },
    "responseElements": {
        "messageId": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
        "sequenceNumber": "112233445566778899"
    },
    "requestID": "1a2b3c4d-5e6f-7890-abcd-ef1234567890",
    "eventID": "fedcba98-7654-3210-fedc-ba9876543210",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "123456789012"
}

This log tells us:

Who: developer-jane (an IAM user) made the call.
What: Performed the SendMessage operation.
When: 2023-10-27T10:30:00Z.
Where: In the us-east-1 region.
To What: The queue my-processing-queue.
From Where: The request originated from IP 203.0.113.25.

The core problem SQS audit logging solves is a lack of visibility into control plane operations on your queues. You can configure SQS to send messages to other AWS services (like Lambda or SNS), and you can configure SQS to deliver messages to your applications. You might even have SQS logging enabled for data events, which logs message content (though this is generally discouraged for large volumes). But what if you need to know who deleted a queue, who changed its access policy, or who sent a specific message to a dead-letter queue? That’s where CloudTrail comes in. It captures all the API calls made to SQS.

CloudTrail records API calls made by a user, role, or an AWS service. When you enable CloudTrail for SQS, it captures events like:

CreateQueue
DeleteQueue
SendMessage
ReceiveMessage
DeleteMessage
PurgeQueue
AddPermission / RemovePermission (for queue policies)
SetQueueAttributes

These events are sent to your configured CloudTrail delivery location, most commonly an S3 bucket. You can then use Amazon Athena, CloudWatch Logs Insights, or other log analysis tools to query these logs.

The key configuration is enabling CloudTrail in the first place, and ensuring it’s set up to log management events for SQS. For data events (which would log SendMessage, ReceiveMessage, DeleteMessage content), you’d need to configure that separately, which is often more expensive and less common for pure auditing.

When you look at requestParameters in the log, you see the exact arguments passed to the SQS API. For SendMessage, this includes messageBody, messageAttributes, queueUrl, and importantly, messageGroupId and messageDeduplicationId if you’re using FIFO queues. For ReceiveMessage, you’d see MaxNumberOfMessages, VisibilityTimeout, and WaitTimeSeconds (for long polling). This level of detail is crucial for debugging or security investigations.

The userIdentity block is your primary audit trail for who performed the action. This can be an IAM User, an IAM Role (which would show the assumed role and the principal that assumed it), or even an AWS service (like lambda.amazonaws.com). Understanding the type and arn here is fundamental to tracing actions back to their source.

The sourceIPAddress tells you where the request came from. This could be an EC2 instance’s private IP, an on-premises IP address if you’re using Direct Connect or VPN, or an internet IP if the call was made from outside your VPC.

The responseElements give you the outcome of the API call from SQS’s perspective. For SendMessage, this is the messageId and sequenceNumber. For DeleteMessage, it would be empty, indicating success.

The most surprising true thing about SQS audit logging is that you might be logging message content without realizing it if you’ve enabled data events for SQS in CloudTrail, and this can be a significant cost and security concern. Most users think of CloudTrail as purely for API call metadata, but data events are a distinct category that captures the actual data flowing through a service. For SQS, this means potentially logging every single message sent and received.

Here’s how you might query these logs using Amazon Athena. Assuming your CloudTrail logs are in S3 bucket my-audit-logs-bucket and you’ve set up an Athena table for them, you could run a query like this to find all DeleteMessage calls targeting your queue:

SELECT
    eventTime,
    userIdentity.userName,
    requestParameters.queueUrl,
    requestID
FROM
    "my_cloudtrail_database"."my_cloudtrail_table"
WHERE
    eventname = 'DeleteMessage'
    AND region = 'us-east-1'
    AND requestParameters.queueUrl LIKE '%/my-processing-queue'
    AND eventType = 'AwsApiCall'
ORDER BY
    eventTime DESC
LIMIT 100;

This query filters for DeleteMessage events in us-east-1 that targeted a queue ending in my-processing-queue. It shows the timestamp, the user who performed the action, the queue URL, and the request ID, ordered by the most recent.

The eventType: "AwsApiCall" is standard for management operations. managementEvent: true further confirms it’s a control plane action. If you were looking at data events (which is less common for pure audit logging of who did what), you’d see eventType: "DataEvent".

The core benefit of this logging is accountability and security. If a queue is accidentally or maliciously deleted, you can trace who did it and when. If sensitive data is being sent to the wrong queue, you can identify the source of the SendMessage call. This is indispensable for compliance and operational integrity.

The next concept you’ll likely run into is correlating these SQS API calls with actual application behavior or other AWS service logs, especially when investigating complex distributed systems.

More Deep Dives in Sqs