SQS Encryption at Rest: KMS and SSE Configuration (2026)

SQS encryption at rest using KMS and SSE is actually a multi-layered defense where the primary bottleneck isn’t SQS itself, but how KMS keys are managed and accessed.

Let’s see it in action. Imagine you have an SQS queue, my-secure-queue, and you want to ensure its messages are encrypted.

{
  "QueueArn": "arn:aws:sqs:us-east-1:123456789012:my-secure-queue",
  "Attributes": {
    "KmsMasterKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcdef12-3456-7890-abcd-ef1234567890",
    "KmsDataKeyReusePeriodSeconds": "300"
  }
}

Here, KmsMasterKeyId points to your AWS KMS Customer Master Key (CMK). KmsDataKeyReusePeriodSeconds is set to 300 seconds (5 minutes). This means SQS will request a data key from KMS, use it to encrypt/decrypt messages for up to 300 seconds, and then discard it. This dramatically reduces KMS API calls.

The core problem SQS encryption at rest aims to solve is protecting sensitive message data when it resides in SQS queues. AWS offers two main mechanisms: Server-Side Encryption (SSE) with SQS-managed keys (SSE-SQS) and SSE with AWS Key Management Service (KMS) (SSE-KMS). SSE-KMS is where the complexity and potential pitfalls lie. When you choose SSE-KMS, SQS acts as a client to KMS. It requests a data key from KMS, uses that data key to encrypt your message payload, and then encrypts the data key itself using your specified CMK. When a consumer retrieves a message, SQS decrypts the data key using the CMK and then uses the decrypted data key to decrypt the message.

The most surprising thing about SQS encryption at rest is that the performance impact isn’t directly from SQS encrypting/decrypting, but from the rate limits and latency of KMS API calls, especially when KmsDataKeyReusePeriodSeconds is set too low or the KMS key policies are overly restrictive.

Consider a scenario where you have high message throughput. If your KmsDataKeyReusePeriodSeconds is, say, 60 seconds, SQS will be making KMS GenerateDataKey and Decrypt calls much more frequently. If your application is also making many SQS SendMessage and ReceiveMessage calls, you can quickly hit KMS API request limits.

Here’s how to diagnose and fix common issues:

Problem: AccessDeniedException when sending or receiving messages. Diagnosis: Check the KMS key policy for your CMK. The SQS service principal (sqs.amazonaws.com) needs kms:GenerateDataKey and kms:Decrypt permissions. Fix: Add the following to your KMS key policy:
```
{
    "Sid": "Allow SQS to use the key",
    "Effect": "Allow",
    "Principal": {
        "Service": "sqs.amazonaws.com"
    },
    "Action": [
        "kms:GenerateDataKey",
        "kms:Decrypt"
    ],
    "Resource": "*"
}
```
Why it works: This explicitly grants SQS the necessary permissions to interact with your KMS key for data key operations, resolving the access denial.
Problem: High latency or ThrottlingException on SQS operations, especially during peak load. Diagnosis: Monitor KMS API call rates and SQS SentMessage or ReceiveMessage latency. Check your KmsDataKeyReusePeriodSeconds attribute. Fix: Increase KmsDataKeyReusePeriodSeconds. A common value is 300 (5 minutes). For very high throughput, you might consider 3600 (1 hour), but be mindful of the trade-off with security. Why it works: This setting allows SQS to reuse a single data key for a longer period, significantly reducing the number of GenerateDataKey and Decrypt calls to KMS, thus lowering the chance of hitting KMS API limits and reducing latency.
Problem: KmsKeyDisabledException or NotFoundException. Diagnosis: Verify the KmsMasterKeyId in your SQS queue attributes matches the ARN of an active and existing KMS CMK. Fix: Ensure the KMS CMK is enabled and the ARN is correctly specified in the SQS queue’s KmsMasterKeyId attribute. If the key was deleted, you’ll need to create a new one and update the SQS queue. Why it works: SQS cannot perform encryption or decryption operations if the specified KMS key is disabled or doesn’t exist.
Problem: Messages are not being encrypted when sent, or are being received unencrypted. Diagnosis: Double-check the KmsMasterKeyId and KmsDataKeyReusePeriodSeconds attributes on the SQS queue. Ensure they are set correctly and not empty. Fix: Update the queue attributes using the AWS CLI:
```
aws sqs set-queue-attributes --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/my-secure-queue --attributes '{
    "KmsMasterKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcdef12-3456-7890-abcd-ef1234567890",
    "KmsDataKeyReusePeriodSeconds": "300"
}'
```
Why it works: Explicitly setting these attributes ensures that SQS is configured to use KMS for encryption at rest.
Problem: Cross-account access to KMS keys is failing. Diagnosis: If your SQS queue is in one account and the KMS key is in another, ensure the KMS key policy in the key’s account grants sqs.amazonaws.com permission to use the key, and the SQS queue’s IAM role (if applicable for consumers) has permissions to call kms:Decrypt on the specific KMS key ARN in the key’s account. Fix: In the KMS key’s account, update the key policy to allow the SQS service principal from the queue’s account. In the queue’s account, ensure the IAM role used by consumers has a policy like:
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "kms:Decrypt",
            "Resource": "arn:aws:kms:us-east-1:ACCOUNT_ID_OF_KMS_KEY:key/abcdef12-3456-7890-abcd-ef1234567890"
        }
    ]
}
```
Why it works: This establishes a trust relationship and grants explicit permissions for cross-account KMS operations.
Problem: When using a custom KMS alias, encryption stops working. Diagnosis: Ensure the KMS alias ARN (e.g., alias/my-key-alias) is correctly specified in the KmsMasterKeyId attribute, not just the alias name. Fix: Use the full ARN of the alias, which looks like arn:aws:kms:us-east-1:123456789012:alias/my-key-alias. Why it works: SQS needs the full resource identifier for the KMS key, including the alias ARN, to correctly locate and use the key.

The next error you’ll likely encounter after fixing these is a ValidationError if you try to enable SSE-KMS on a FIFO queue without also specifying ContentBasedDeduplication or providing a MessageDeduplicationId, as SQS requires a deduplication mechanism when encryption is enabled for FIFO queues.

More Deep Dives in Sqs