Amazon SQS server-side encryption protects message bodies with either SQS-managed keys (SSE-SQS) or keys in AWS KMS (SSE-KMS). Choose SSE-KMS when you need control over key policy and an audit trail of key use, and SSE-SQS when plain encryption at rest is enough. Neither encrypts queue or message metadata.
What is and is not encrypted
The AWS documentation is specific. SSE encrypts the body of a message. It does not encrypt queue metadata such as the queue name and attributes, message metadata such as the message ID, timestamp and attributes, or per-queue metrics.
The practical rule: never put sensitive values in message attributes or queue names and assume encryption covers them.
Timing matters
A message is encrypted only if it is sent after encryption is enabled on the queue. Backlogged messages are not encrypted retroactively. In the other direction, an encrypted message stays encrypted even if you later disable encryption on the queue.
If you are turning encryption on for a busy queue, plan for the existing backlog to drain, or move it.
How the KMS option works
With KMS, SQS uses envelope encryption. A KMS key encrypts a data key, and the encrypted data key is stored with the message. The data key reuse period sets how long SQS can reuse a data key before calling KMS again, between 60 seconds and 24 hours, with a default of 300 seconds. The documentation says that if KMS cannot be reached, SQS keeps using the cached data key until the connection returns.
You can use the AWS managed key for SQS or a customer managed key. The documentation notes that KMS use carries additional charges, so estimate the call volume for high traffic queues.
Decision guide
- Need to prove who used the key, or to revoke access by changing key policy: SSE-KMS with a customer managed key.
- Need encryption at rest as a baseline with little operational work: SSE-SQS.
- Cross-account consumers: check the documentation first. It states that an encrypted queue using the default AWS managed key cannot invoke a Lambda function in a different account, which is a reason to use a customer managed key in those designs.
Side effects to know
All requests to an encrypted queue must use HTTPS and Signature Version 4. Anonymous send and receive requests to an encrypted queue are rejected, which is a feature, since AWS recommends against anonymous requests anyway.
Dead-letter queues do not change a message's encryption. A message moved from an encrypted queue to an unencrypted dead-letter queue stays encrypted, but one moved from an unencrypted queue to an encrypted dead-letter queue stays unencrypted. Match the settings on both. The dead-letter queue post covers more.
Safeguard can help here in a small way. Its SBOM and dependency scanning covers the broker client libraries and service frameworks your code pulls in, and reachability analysis shows which advisories your services actually call. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does SQS encryption hide the queue name?
No. Queue names, attributes and message metadata are not encrypted, so keep sensitive data out of them.
I enabled encryption today. Is my old backlog protected?
No. Only messages sent after encryption is enabled are encrypted.
Sources
Last reviewed: 19 October 2026.
