Encryption at rest - Amazon Simple Queue Service
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China.

Encryption at rest

Server-side encryption (SSE) lets you transmit sensitive data in encrypted queues. SSE protects the contents of messages in queues using SQS-managed encryption keys (SSE-SQS) or keys managed in the Amazon Key Management Service (SSE-KMS). For information about managing SSE using the Amazon Web Services Management Console, see the following:

For information about managing SSE using the Amazon SDK for Java (and the CreateQueue, SetQueueAttributes, and GetQueueAttributes actions), see the following examples:

SSE encrypts messages as soon as Amazon SQS receives them. The messages are stored in encrypted form and Amazon SQS decrypts messages only when they are sent to an authorized consumer.

Important

All requests to queues with SSE enabled must use HTTPS and Signature Version 4.

Some features of Amazon services that can send notifications to Amazon SQS using the Amazon Security Token Service AssumeRole action are compatible with SSE but work only with standard queues:

For information about compatibility of other services with encrypted queues, see Configure KMS permissions for Amazon services and your service documentation.

Amazon KMS combines secure, highly available hardware and software to provide a key management system scaled for the cloud. When you use Amazon SQS with Amazon KMS, the data keys that encrypt your message data are also encrypted and stored with the data they protect.

The following are benefits of using Amazon KMS:

  • You can create and manage Amazon KMS keys yourself.

  • You can also use the Amazon managed KMS key for Amazon SQS, which is unique for each account and region.

  • The Amazon KMS security standards can help you meet encryption-related compliance requirements.

For more information, see What is Amazon Key Management Service? in the Amazon Key Management Service Developer Guide.

Encryption scope

SSE encrypts the body of a message in an Amazon SQS queue.

SSE doesn't encrypt the following:

  • Queue metadata (queue name and attributes)

  • Message metadata (message ID, timestamp, and attributes)

  • Per-queue metrics

Encrypting a message makes its contents unavailable to unauthorized or anonymous users. This doesn't affect the normal functioning of Amazon SQS:

  • A message is encrypted only if it is sent after the encryption of a queue is enabled. Amazon SQS doesn't encrypt backlogged messages.

  • Any encrypted message remains encrypted even if the encryption of its queue is disabled.

Moving a message to a dead-letter queue doesn't affect its encryption:

  • When Amazon SQS moves a message from an encrypted source queue to an unencrypted dead-letter queue, the message remains encrypted.

  • When Amazon SQS moves a message from an unencrypted source queue to an encrypted dead-letter queue, the message remains unencrypted.

Key terms

The following key terms can help you better understand the functionality of SSE. For detailed descriptions, see the Amazon Simple Queue Service API Reference.

Data key

The key (DEK) responsible for encrypting the contents of Amazon SQS messages.

For more information, see Data Keys in the Amazon Key Management Service Developer Guide in the Amazon Encryption SDK Developer Guide.

Data key reuse period

The length of time, in seconds, for which Amazon SQS can reuse a data key to encrypt or decrypt messages before calling Amazon KMS again. An integer representing seconds, between 60 seconds (1 minute) and 86,400 seconds (24 hours). The default is 300 (5 minutes). For more information, see Understanding the data key reuse period.

Note

In the unlikely event of being unable to reach Amazon KMS, Amazon SQS continues to use the cached data key until a connection is reestablished.

KMS key ID

The alias, alias ARN, key ID, or key ARN of an Amazon managed KMS key or a custom KMS key—in your account or in another account. While the alias of the Amazon managed KMS key for Amazon SQS is always alias/aws/sqs, the alias of a custom KMS key can, for example, be alias/MyAlias. You can use these KMS keys to protect the messages in Amazon SQS queues.

Note

Keep the following in mind:

  • If you don't specify a custom KMS key, Amazon SQS uses the Amazon managed KMS key for Amazon SQS.

  • The first time you use the Amazon Web Services Management Console to specify the Amazon managed KMS key for Amazon SQS for a queue, Amazon KMS creates the Amazon managed KMS key for Amazon SQS.

  • Alternatively, the first time you use the SendMessage or SendMessageBatch action on a queue with SSE enabled, Amazon KMS creates the Amazon managed KMS key for Amazon SQS.

You can create KMS keys, define the policies that control how KMS keys can be used, and audit KMS key usage using the Customer managed keys section of the Amazon KMS console or the CreateKey Amazon KMS action. For more information, see KMS keys and Creating Keys in the Amazon Key Management Service Developer Guide. For more examples of KMS key identifiers, see KeyId in the Amazon Key Management Service API Reference. For information about finding KMS key identifiers, see Find the Key ID and ARN in the Amazon Key Management Service Developer Guide.

Important

There are additional charges for using Amazon KMS. For more information, see Estimating Amazon KMS costs and Amazon Key Management Service Pricing.

Envelope Encryption

The security of your encrypted data depends in part on protecting the data key that can decrypt it. Amazon SQS uses the KMS key to encrypt the data key and then the encrypted data key is stored with the encrypted message. This practice of using a KMS key to encrypt data keys is known as envelope encryption.

For more information, see Envelope Encryption in the Amazon Encryption SDK Developer Guide.