Amazon SQS queues should be encrypted at rest to protect message data from unauthorized access and meet compliance requirements. This FinOps policy ensures that encryption is enabled on all SQS queues, aligning with AWS Security Hub control SQS.1 and frameworks such as AWS Foundational Security Best Practices and NIST SP 800-53.
This policy applies to any team managing SQS queues through Infrastructure-as-Code and is especially relevant for workloads handling sensitive or regulated data.
Why This Policy Matters
Unencrypted SQS queues expose message data to potential unauthorized access at the storage layer. This creates both a security risk and a compliance gap that can result in audit findings, remediation costs, and operational disruption.
How It Helps Reduce Cloud Costs
Failing to enable encryption at the outset creates downstream costs. Retrofitting encryption across production queues requires planned maintenance windows, engineering time, and in some cases infrastructure redeployment.
Enabling encryption during initial provisioning through IaC eliminates rework costs. It also avoids the indirect costs of compliance failures, including audit remediation and potential regulatory penalties.
AWS Key Management Service (KMS) adds a minor cost per API call, but the cost of remediation and audit non-compliance is typically far greater. Using the AWS-managed key (aws/sqs) eliminates additional KMS key charges while still satisfying most compliance requirements.
Potential Savings
- Remediation avoidance: Engineering teams can spend 4-8 hours per queue environment retroactively enabling and validating encryption. At scale, this adds up quickly.
- Audit cost reduction: A single compliance finding related to unencrypted storage can trigger audit cycles costing thousands of dollars in staff time.
- Using the AWS-managed key: Choosing alias/aws/sqs over a customer-managed key avoids the $1/month per key cost for teams managing hundreds of queues.
Implementation Guide
Infrastructure-as-Code Example (Terraform)
The following examples show a non-compliant SQS queue configuration and the corrected version.
Non-compliant configuration (no encryption at rest):
resource "aws_sqs_queue" "example" {
name = "example-queue"
}This configuration creates an SQS queue without encryption. It violates AWS Security Hub SQS.1 and does not meet NIST SP 800-53 SC-28 requirements.
Compliant configuration using the AWS-managed KMS key:
resource "aws_sqs_queue" "example" {
name = "example-queue"
kms_master_key_id = "alias/aws/sqs"
}This enables server-side encryption using the AWS-managed key for SQS. No additional KMS key cost is incurred.
Compliant configuration using a customer-managed KMS key:
resource "aws_kms_key" "sqs_key" {
description = "KMS key for SQS queue encryption"
deletion_window_in_days = 10
enable_key_rotation = true
}
resource "aws_kms_alias" "sqs_key_alias" {
name = "alias/sqs-example-queue"
target_key_id = aws_kms_key.sqs_key.key_id
}
resource "aws_sqs_queue" "example" {
name = "example-queue"
kms_master_key_id = aws_kms_key.sqs_key.arn
}Use a customer-managed key when your organization requires independent key rotation control, cross-account access, or fine-grained audit logging via AWS CloudTrail.
Manual Step-by-Step Instructions
- Audit existing queues: Use the AWS CLI to list all SQS queues and check for the KmsMasterKeyId attribute.
aws sqs list-queues --query 'QueueUrls[]' --output text- Check encryption status per queue:
aws sqs get-queue-attributes \
--queue-url https://sqs.<region>.amazonaws.com/<account-id>/<queue-name> \
--attribute-names KmsMasterKeyIdIf KmsMasterKeyId is absent or empty, the queue is not encrypted at rest.
- Enable encryption on existing queues (AWS-managed key):
aws sqs set-queue-attributes \
--queue-url https://sqs.<region>.amazonaws.com/<account-id>/<queue-name> \
--attributes KmsMasterKeyId=alias/aws/sqs- Update your Terraform code to include kms_master_key_id on all aws_sqs_queue resources.
- Run terraform plan to confirm the change will be applied without recreating the queue.
- Apply the change via your standard deployment pipeline.
- Validate compliance using AWS Security Hub or a terraform plan diff showing the attribute is set.
Best Practices
- Default to the AWS-managed key (alias/aws/sqs) unless compliance or architecture requirements demand a customer-managed key.
- Use a Terraform variable or local for the KMS key ID to avoid hardcoding across multiple queue definitions.
- Enable key rotation on all customer-managed KMS keys to reduce exposure from key compromise.
- Apply encryption at resource creation, not as a retrofit. Retrofitting requires careful coordination with consuming services.
- Tag KMS keys with the owning team, environment, and data classification to improve cost attribution and governance.
- Enforce this policy in CI/CD using policy-as-code tools so non-compliant configurations never reach production.
Tools and Scripts to Help Implement
Infracost detects this policy violation automatically during terraform plan. When an aws_sqs_queue resource is missing the kms_master_key_id attribute, Infracost flags it as a policy violation in the cost and compliance output.
This policy is available in Infracost, including in the free trial. Teams can use Infracost to:
- Detect unencrypted queues across all Terraform configurations before deployment.
- Block or warn on pull requests that introduce non-compliant SQS resources.
- Track remediation progress over time, burning down existing violations queue by queue.
- Measure compliance posture across environments in a single dashboard view.
Infracost integrates directly into CI/CD pipelines (GitHub Actions, GitLab CI, Azure DevOps, Atlantis), enabling FinOps and platform teams to enforce this policy without manual reviews.
AWS Config can also enforce this rule using the managed rule sqs-queue-encrypted. Use this alongside Infracost for defense-in-depth coverage across both IaC and deployed infrastructure.
Examples of Impact
Example 1: Startup with 30 SQS queues
A startup running 30 SQS queues was flagged during a SOC 2 audit for missing encryption at rest. Remediation required an engineer to identify all non-compliant queues, coordinate with application teams, and apply changes across three environments. Total effort: approximately 20 engineering hours. Adding kms_master_key_id = “alias/aws/sqs” to their Terraform module default would have resolved this in under 30 minutes at provisioning time.
Example 2: Enterprise migration to customer-managed keys
An enterprise team managing 200+ SQS queues across multiple AWS accounts needed to migrate from unencrypted queues to customer-managed KMS keys for NIST compliance. Using Infracost, they identified all non-compliant resources in IaC within minutes. They created a shared KMS key Terraform module and burned down violations over a two-week sprint, tracking progress through the Infracost dashboard.
Considerations and Caveats
- Existing queues can be encrypted in-place. AWS allows enabling KmsMasterKeyId on an existing queue without recreating it. Terraform applies this as an in-place update.
- KMS API call costs apply. Each SQS message send/receive triggers KMS API calls. For very high-throughput queues, this adds a small but measurable cost. AWS SQS uses data key caching by default to minimize this.
- Cross-account access requires additional KMS policy configuration. If queues are consumed by Lambda or services in other AWS accounts, the KMS key policy must explicitly grant those accounts decrypt permissions.
- AWS-managed keys cannot be deleted or rotated manually. If your compliance policy requires independent key lifecycle control, use a customer-managed key instead.
- FIFO queues support the same encryption options. The kms_master_key_id attribute applies equally to standard and FIFO SQS queues.
- Dead-letter queues (DLQs) must be encrypted separately. If a DLQ is associated with an encrypted source queue, the DLQ itself must also have encryption enabled to remain compliant.