AWSAmazon SQSApplication Integration

`aws_sqs_queue_policy` cost estimation

A resource policy that controls who can send to or receive from an SQS queue. The policy is free. The queue bills per request, and a policy that opens the queue too wide can enable a flood of billable requests.

The aws_sqs_queue_policy resource attaches a JSON resource policy to an SQS queue, defining which principals and services can perform actions like sqs:SendMessage and sqs:ReceiveMessage. It is the standard way to let another AWS service (an SNS topic, an S3 bucket event, an EventBridge rule) or a cross-account principal write to the queue. Attaching the policy is free; there is no charge for the policy itself.

SQS cost is per request. Standard queues bill about 0.40 dollars per million requests after the free tier of 1 million requests per month; FIFO queues bill about 0.50 dollars per million. Critically, every API action counts as a request: each SendMessage, each ReceiveMessage (even one that returns no messages), each DeleteMessage. Long polling and batching are what keep the request count, and therefore the bill, down.

The queue policy is cost-adjacent because it governs who can generate those billable requests. A policy scoped tightly to a specific SNS topic or a known account keeps request volume predictable. An overly permissive policy (for example allowing sqs:SendMessage from Principal asterisk) means any actor who learns the queue URL can flood it with messages, each of which is a billable send plus the downstream receive and delete. So while the policy costs nothing, a loose policy is a path to both a security incident and a request-driven bill.

There are related charges to keep in mind. Messages larger than 256 KB require the extended client library backed by S3, adding S3 storage and request charges. A dead-letter queue attached via redrive adds its own request charges for messages that fail processing repeatedly. And a consumer that short-polls in a tight loop can rack up millions of empty ReceiveMessage requests, which is the classic SQS cost surprise; enabling long polling (a ReceiveMessageWaitTimeSeconds greater than zero) collapses those into far fewer billable calls.

c3x reports aws_sqs_queue_policy as free and attributes request spend to the aws_sqs_queue it protects.

Terraform example

A minimal but realistic configuration that C3X can estimate.

resource "aws_sqs_queue" "events" {
  name                       = "order-events"
  receive_wait_time_seconds  = 20 # long polling cuts empty-receive request cost
}

# Free policy that lets only a specific SNS topic send. Scoping keeps
# billable request volume predictable and blocks unknown senders.
resource "aws_sqs_queue_policy" "events" {
  queue_url = aws_sqs_queue.events.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "sns.amazonaws.com" }
      Action    = "sqs:SendMessage"
      Resource  = aws_sqs_queue.events.arn
      Condition = {
        ArnEquals = { "aws:SourceArn" = aws_sns_topic.orders.arn }
      }
    }]
  })
}

Pricing dimensions

What you actually pay for when you provision aws_sqs_queue_policy.

Dimension	Unit	What's being charged
SQS queue policy	free	Attaching a resource policy to a queue is free. $0 (free)
SQS Standard requests	per million requests	Every send, receive, and delete on a standard queue is a billable request after the free tier. $0.40 per million (first 1 million/month free)
SQS FIFO requests	per million requests	Requests on FIFO queues, which guarantee ordering and exactly-once processing. $0.50 per million requests
Extended payloads via S3 (if used)	per GB-month + per request	Messages over 256 KB stored in S3 add S3 storage and request charges. $0.023 per GB-month + S3 request rates

Optimization tips

Common ways to reduce aws_sqs_queue_policy cost without changing the workload.

Scope the policy to specific senders

Limit sqs:SendMessage to the exact SNS topic, account, or service that should write to the queue, using aws:SourceArn conditions. A tight policy blocks unknown actors from flooding the queue with billable messages.

Enable long polling to eliminate empty-receive charges

Can cut receive-request volume by 90%+ on idle queues

Set ReceiveMessageWaitTimeSeconds to 20 so consumers wait for messages instead of returning empty immediately. This collapses millions of empty short-poll ReceiveMessage requests into far fewer billable calls.

Batch sends, receives, and deletes

Up to 10x fewer billable requests

SendMessageBatch, ReceiveMessage with a MaxNumberOfMessages up to 10, and DeleteMessageBatch move up to 10 messages per request. Batching divides the billable request count by up to 10.

Use a dead-letter queue to stop infinite reprocessing

Without a redrive policy, a poison message can be received and returned endlessly, each cycle billing requests. A dead-letter queue caps retries and stops the request loop.

FAQ

Does an SQS queue policy cost anything?

No. Attaching a resource policy is free. SQS charges per request against the queue itself, and the policy simply controls who is allowed to generate those requests.

How can a queue policy affect my bill?

A loose policy that allows sends from unknown principals lets anyone with the queue URL flood it with messages, each a billable send plus downstream receive and delete. Scoping the policy to known senders keeps request volume, and cost, predictable.

What is the most common SQS cost surprise?

Consumers that short-poll in a tight loop generate millions of empty ReceiveMessage requests, each billable. Enabling long polling by setting ReceiveMessageWaitTimeSeconds greater than zero collapses those into far fewer calls.

Do I pay per subscriber or per queue?

SQS bills per request, not per policy or per subscriber. Whether one or many principals are allowed by the policy, you pay only for the actual send, receive, and delete requests made against the queue.