Amazon SQS Pricing: Complete Guide + Calculator (2026)

Amazon SQS pricing looks straightforward: pay per request, no upfront commitments. But between the 64 KB chunking rule that silently multiplies your request count, empty receives from Lambda polling idle queues, and the new Fair Queue surcharges launched in July 2025, the actual bill can look very different from what you'd expect.

This guide breaks down every SQS cost dimension with current 2026 numbers, including Standard, FIFO, and Fair Queue pricing, hidden costs that catch teams off guard, real-world cost scenarios, optimization strategies, and a comparison with SNS and EventBridge pricing. I've also included cost-optimized CDK and Terraform examples. If you want a quick estimate, the SQS pricing calculator lets you model your specific workload in minutes.

All prices are for US East (N. Virginia) as of March 2026. Prices vary by region.

How Amazon SQS Pricing Works

Amazon SQS uses a pure pay-per-request model. No minimum fees, no upfront commitments, no charges for creating or maintaining queues. You pay only for the API requests you make, and the rate depends on which queue type you're using.

Here's the quick-reference pricing across all three queue types:

The volume discounts on Standard queues kick in at enormous scale (100 billion requests/month), so most teams will pay the $0.40/M rate. FIFO queues carry a 25% premium at $0.50/M for send, receive, delete, and change-visibility operations, while all other API actions (like CreateQueue or ListQueues) are charged at standard rates regardless of queue type.

Fair Queues are the newest addition. Launched in July 2025, they add a $0.10/M surcharge on top of Standard rates when you include a MessageGroupId on messages sent to standard queues. I'll cover the details in the queue comparison section below.

Regional pricing is mostly uniform across AWS regions. The notable exception is eu-central-2 (Zurich), which charges $0.44/M for standard requests compared to the typical $0.40/M. Check the official Amazon SQS pricing page for your specific region.

SQS Free Tier

Every AWS account gets 1 million SQS requests per month for free, permanently. This isn't limited to the first 12 months after account creation. It applies across all queue types, is calculated monthly across all regions (except GovCloud), doesn't roll over, and is applied automatically to your bill.

For low-volume workloads, 1 million requests/month is generous. A small app sending 500 messages/day with corresponding receives and deletes would use roughly 45,000 requests/month.

Request Pricing by Queue Type

The key detail is which operations are charged at which rate. Standard rates apply to all API actions on standard queues and to non-messaging actions (CreateQueue, ListQueues, etc.) on any queue type. FIFO rates apply to SendMessage, ReceiveMessage, DeleteMessage, and ChangeMessageVisibility on FIFO queues. Fair Queue rates apply when at least one message in the API action includes a MessageGroupId on a standard queue, and those requests are charged both the standard rate and the surcharge.

That last point matters: Fair Queue pricing is per-request, not per-queue. You can send some messages with a MessageGroupId (charged at $0.50/M effective) and others without it (charged at $0.40/M) on the same queue.

Data Transfer Costs

Data transfer with SQS is straightforward and often free:

For most SQS workloads, data transfer costs are zero because producers and consumers run in the same region. Cross-region transfers apply standard AWS data transfer rates.

These per-million prices look straightforward, but the way SQS counts requests is where costs get tricky.

How SQS Requests Are Counted

Understanding how SQS meters requests is the difference between an accurate cost estimate and a surprise bill. Every SQS API action counts as one request, but two rules can multiply your actual request count well beyond the number of messages you send.

The 64 KB Chunking Rule

This is the single most impactful cost multiplier in SQS pricing. Every 64 KB chunk of payload is billed as a separate request. A message under 64 KB costs one request, but go even 1 byte over and you're paying for two.

Here's the thing: message attributes (up to 10 per message) count toward the total message size. If your message body is 60 KB and you add 5 KB of attributes, you've crossed the 64 KB threshold and you're now paying for two requests instead of one.

Batch Operations and Request Counting

Batch operations (SendMessageBatch, DeleteMessageBatch, ChangeMessageVisibilityBatch) let you process up to 10 messages in a single API call, and the entire batch counts as one request for billing. The 64 KB chunking rule applies to the total batch payload (max 1 MiB), not individual messages. So a batch of 10 messages at 6 KB each (60 KB total) costs one request, while a batch at 10 KB each (100 KB total) costs two.

For FIFO queues, the batch is charged at FIFO rates. For Fair Queue batches, if any message includes a MessageGroupId, the entire batch incurs both rates.

Now that you know how requests are counted, let's compare the pricing across all three queue types.

Standard vs FIFO vs Fair Queue Pricing

SQS offers three queue types, each with different pricing and capabilities. The wrong choice can mean paying 25% more than necessary.

Standard Queues ($0.40/M)

Standard queues are the default and the cheapest option. Nearly unlimited throughput, at-least-once delivery, best-effort ordering. "At-least-once" means your consumer might occasionally receive a duplicate, so processing logic needs to be idempotent. For most high-volume workloads, Standard is the right choice.

FIFO Queues ($0.50/M)

FIFO (First In, First Out) queues guarantee exactly-once processing and strict message ordering within a message group. The 25% price premium covers the deduplication and ordering overhead. Use FIFO when duplicate processing would cause real problems: financial transactions, order workflows, inventory updates. Throughput is lower (up to 70,000 TPS with high-throughput mode in us-east-1), but that's enough for most use cases.

Fair Queues (Standard + $0.10/M)

Fair Queues are the newest addition, launched in July 2025. They solve the noisy-neighbor problem in multi-tenant systems by automatically reordering message processing to maintain consistent dwell time across tenants.

Activate Fair Queue behavior by including a MessageGroupId when sending messages to a standard queue. No consumer code changes required. The $0.10/M surcharge applies only to requests involving a MessageGroupId, so you can selectively opt in. Amazon SNS and EventBridge now support forwarding MessageGroupId to SQS as well.

When to Use Each Queue Type

• Standard: Default choice. High-volume workloads, background processing, event streaming. Use this unless you have a specific reason not to
• FIFO: When exactly-once processing and strict ordering actually matter. Financial transactions, order sequencing, inventory updates
• Fair Queues: Multi-tenant SaaS platforms where one tenant's burst shouldn't starve others. Worth the $0.10/M surcharge when tenant SLA consistency matters

At 100 million messages/month, the cost difference looks like this: Standard = $40, FIFO = $50, Fair Queues = $50. The 25% premium from FIFO or the surcharge from Fair Queues is meaningful at scale, so don't opt in unless you genuinely need the guarantees.

The per-request pricing is only part of the story. Let's look at the costs that don't show up on the pricing page.

Hidden Costs That Inflate Your SQS Bill

I keep seeing the same pattern: teams estimate their SQS costs based on message volume, deploy, and then find their actual bill is 2-5x higher. The culprit is almost always one of these four hidden cost sources.

Empty Receives and the Lambda Polling Trap

This is the most common SQS cost surprise. By default, SQS uses short polling, which returns immediately even when no messages are available. Every empty response is a billable request.

The real cost trap happens with Lambda event source mappings. When you connect Lambda to an SQS queue, Lambda's internal poller continuously calls ReceiveMessage to check for new messages, using long polling with a 20-second wait. Even when the queue is completely empty, Lambda keeps polling. The math works out to roughly 129,600 requests per month per idle queue (1 poll every 20 seconds, 24/7).

That might sound manageable under the 1 million request free tier, but it adds up fast. If you have 8 idle queues with Lambda triggers, you're generating over 1 million empty receives per month, blowing through your free tier without sending a single message. AWS documentation notes that a single Lambda-triggered SQS queue can generate up to ~1.7 million requests/month from Lambda's internal polling alone, depending on scaling behavior.

The fix: monitor the NumberOfEmptyReceives CloudWatch metric. If a queue consistently shows high empty receives with zero messages sent, either remove the Lambda trigger or delete the queue.

KMS Encryption Costs (SSE-KMS vs SSE-SQS)

SQS offers two encryption options, and the cost difference matters more than most teams realize:

• SSE-SQS (SQS-managed keys): Free. AWS manages the encryption keys entirely. This is the default and is sufficient for most workloads
• SSE-KMS (AWS KMS keys): Incurs KMS API charges. Every time SQS needs to encrypt or decrypt messages, it calls KMS GenerateDataKey and Decrypt APIs at $0.03 per 10,000 requests

The KMS cost depends on how many producers and consumers you have and how long SQS caches data keys. AWS provides this formula for estimating KMS costs:

R = B / D * (2 * P + C)

Where:
B = billing period (seconds)
D = data key reuse period (seconds, default 300 = 5 min)
P = number of producing principals
C = number of consuming principals

For a simple queue with 1 producer, 1 consumer, and the default 5-minute reuse period: 2,592,000 / 300 * (2 * 1 + 1) = 25,920 KMS calls/month, roughly $0.08/month. That's negligible for a single queue. But multiply it across 50 queues in a microservices architecture and you're looking at $4/month in KMS costs alone, on top of your SQS bill.

If compliance doesn't require KMS audit trails, switch to SSE-SQS. If you must use KMS, increase the data key reuse period from the default 5 minutes up to 24 hours to cut KMS API calls dramatically.

Extended Client Library and S3 Costs

SQS messages max out at 256 KB (with the 64 KB chunking penalty), and the hard API limit is 1 MiB. For larger payloads, the SQS Extended Client Library (available for Java and Python) stores the message body in S3 and sends only a reference in the SQS message. This is the claim-check pattern.

The hidden cost here is the S3 bill. You're now paying for S3 PUT/GET requests and storage on top of your SQS costs. For high-volume workloads sending messages over 256 KB, this triple cost (SQS requests + S3 storage + S3 requests) can significantly exceed what you'd expect from SQS pricing alone. The better optimization is usually to compress payloads or restructure messages to stay under 64 KB.

Dead-Letter Queue Request Costs

Dead-letter queues (DLQs) are standard SQS queues, and every message that lands in a DLQ incurs normal SQS charges. What catches people off guard:

• When SQS moves a failed message to the DLQ, that's a billable SendMessage request on the DLQ
• When you redrive messages back to the source queue, that generates ReceiveMessage + DeleteMessage + SendMessage requests
• A maxReceiveCount set too low causes messages to fail to the DLQ prematurely, generating unnecessary DLQ traffic

The cost impact is usually small compared to the other hidden costs, but in high-failure-rate scenarios (bad consumer code, upstream data issues), DLQ costs can spiral. Set your maxReceiveCount to at least 3-5 to avoid premature failures, and set the DLQ retention period longer than the source queue to avoid losing messages before investigation.

Now let's put real numbers on these costs with scenarios that match common workload sizes.

Real-World SQS Cost Examples

The best way to understand SQS pricing is to see it applied to workloads at different scales. Here are four scenarios from free tier to enterprise, each with a line-by-line cost breakdown. For custom estimates, use the SQS pricing calculator.

Free Tier Project (~500K Messages/Month)

Scenario: A hobby project or early-stage startup sending 500,000 small messages per month (each under 64 KB). Standard queue, long polling enabled, SSE-SQS encryption.

Total: $0.20/month. With some batching, you could get this to zero.

Small SaaS with Batching (10M Messages/Month)

Scenario: A growing SaaS application processing 10 million messages per month (average 32 KB each). Using batch operations (10 messages per batch) for sends and deletes, long polling, SSE-SQS.

Total: $0.80/month

Without batching, the same workload would cost: 30M requests - 1M free = 29M x $0.40/M = $11.60/month. Batching saves $10.80/month, a 93% reduction. That's the single most impactful optimization you can make.

High-Volume FIFO with Encryption (100M Messages/Month)

Scenario: A financial services application processing 100 million messages per month, average 128 KB each. FIFO queue for exactly-once delivery, SSE-KMS required for compliance, batch send/receive, 2 producers, 4 consumers.

The 128 KB message size means each message counts as 2 requests (64 KB chunking). Even with batching, the chunking multiplier adds 20M extra billed requests. If these messages could be compressed to under 64 KB, the FIFO request cost would drop from $25 to $12.50.

Multi-Tenant Fair Queue Workload

Scenario: A multi-tenant SaaS platform processing 50 million messages per month across 200 tenants. Standard queue with Fair Queue behavior enabled (all messages include MessageGroupId), average 32 KB each, batch operations, long polling, SSE-SQS.

The Fair Queue surcharge adds $1.50/month in this scenario. Compare that to the alternative: building your own tenant-fair scheduling logic in application code, which would cost significantly more in engineering time. For multi-tenant workloads with noisy-neighbor concerns, the surcharge is worth it.

These examples show how optimization choices make a 10x difference. Here's the full playbook.

8 Ways to Reduce Your SQS Costs

SQS costs are almost entirely driven by request volume, which means every optimization boils down to one thing: making fewer requests. Here's what I recommend, ranked roughly by impact.

1. Use Batch Operations (Up to 90% Savings)

This is the single highest-impact optimization. SendMessageBatch, DeleteMessageBatch, and ChangeMessageVisibilityBatch let you process up to 10 messages per API call. A batch of 10 messages costs the same as sending a single message.

The math is simple: 10 million messages without batching = 30M requests ($11.60/month after free tier). With batching = 3M requests ($0.80/month). That's a 93% cost reduction with no queue configuration changes, only application-level changes to accumulate and batch messages.

For Java applications, the Amazon SQS Buffered Asynchronous Client handles batching automatically on the client side without any code changes. Note that it doesn't support FIFO queues.

2. Enable Long Polling

Short polling (the default) returns immediately even when no messages are available, generating billable empty responses. Long polling waits up to 20 seconds for messages to arrive before returning.

Set ReceiveMessageWaitTimeSeconds to 20 on your queue (applies to all consumers) or set WaitTimeSeconds on individual ReceiveMessage requests. Long polling has zero additional cost, reduces your bill, and also reduces false empty responses by querying all SQS servers rather than a subset. There's no reason not to enable it.

3. Minimize Message Size

Since each 64 KB chunk costs an additional request, keeping messages under 64 KB is a direct cost optimization:

• Compress message bodies before sending (gzip can often cut size by 50-80%)
• Use the claim-check pattern: store large payloads in S3, send only a reference in SQS
• Remove unnecessary fields from message payloads
• Watch message attributes: they count toward the 64 KB threshold

A 256 KB message costs 4x as much as a 64 KB message. If you can compress it to under 64 KB, you've cut costs by 75% per message.

4. Choose SSE-SQS Over SSE-KMS

SSE-SQS provides encryption at rest with zero additional cost. SSE-KMS gives you more control over keys but adds KMS API charges. For most workloads, SSE-SQS is sufficient. If compliance requires KMS, increase the data key reuse period from the default 5 minutes to 24 hours. That single change reduces KMS API calls by 288x.

5. Right-Size Your Polling Architecture

When using SQS with Lambda, tune these event source mapping parameters for cost efficiency:

• BatchSize: Set to 10 for standard queues (max 10 for FIFO). This maximizes messages processed per Lambda invocation
• MaximumBatchingWindowInSeconds: Set to 5-30 seconds. Lambda waits this long to accumulate a full batch before invoking
• ReportBatchItemFailures: Enable this. Without it, a single failed message causes the entire batch to be retried, generating duplicate processing costs

For EC2/ECS consumers, scale consumer count based on queue depth. Monitor ApproximateNumberOfMessagesVisible and NumberOfEmptyReceives in CloudWatch. Reduce consumers during low-traffic periods to avoid unnecessary polling costs.

6. Pick the Right Queue Type

Use Standard queues ($0.40/M) unless you genuinely need exactly-once processing or strict ordering. The 25% FIFO premium adds up at scale: at 100M requests/month, that's $10/month extra.

For Fair Queues, only include MessageGroupId on messages that need fairness guarantees. Messages without it on the same queue are charged standard rates only, so you can selectively opt in.

7. Monitor and Eliminate Idle Queues

Idle queues with Lambda triggers or other polling consumers silently burn through your free tier. A single Lambda-triggered SQS queue with no messages can generate up to ~1.7 million requests/month. Monitor NumberOfEmptyReceives in CloudWatch to identify idle queues and either remove the trigger or delete the queue.

For a broader framework on cost reduction across your AWS environment, check out the AWS cost estimation guide and the AWS cost optimization checklist.

8. Use Cost Allocation Tags

Tag your SQS queues with cost allocation tags (team, project, environment) so you can track and attribute costs in AWS Cost Explorer. SQS supports up to 50 tags per queue. This won't reduce costs directly, but it's the foundation for understanding where your SQS spend is going and who's responsible for it.

These optimizations work even better when you bake them into your infrastructure code from day one.

Cost-Optimized SQS with Infrastructure as Code

Configuring SQS cost optimization manually across dozens of queues is error-prone. Here are copy-pasteable CDK and Terraform examples with every cost-relevant setting annotated. If you're using CDK, you can estimate AWS CDK costs before deploying to catch expensive configurations in code review.

AWS CDK (TypeScript)

import * as sqs from 'aws-cdk-lib/aws-sqs';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as eventsources from 'aws-cdk-lib/aws-lambda-event-sources';
import { Duration } from 'aws-cdk-lib';

// Dead-letter queue with 14-day retention for investigation
const dlq = new sqs.Queue(this, 'DeadLetterQueue', {
  retentionPeriod: Duration.days(14),
  encryption: sqs.QueueEncryption.SQS_MANAGED, // Free SSE-SQS
});

// Cost-optimized standard queue
const queue = new sqs.Queue(this, 'MyQueue', {
  receiveMessageWaitTime: Duration.seconds(20), // Long polling: eliminates empty receives
  encryption: sqs.QueueEncryption.SQS_MANAGED,  // Free encryption (not KMS)
  enforceSSL: true,
  deadLetterQueue: {
    queue: dlq,
    maxReceiveCount: 5, // Avoid premature DLQ failures
  },
  retentionPeriod: Duration.days(4),
  visibilityTimeout: Duration.seconds(180), // 6x your Lambda timeout
});

// FIFO queue (only when exactly-once delivery is required)
const fifoQueue = new sqs.Queue(this, 'MyFifoQueue', {
  fifo: true,
  contentBasedDeduplication: true,  // Saves you from managing deduplication IDs
  receiveMessageWaitTime: Duration.seconds(20),
  encryption: sqs.QueueEncryption.SQS_MANAGED,
  enforceSSL: true,
});

// If KMS is required for compliance, maximize data key reuse
const kmsQueue = new sqs.Queue(this, 'KmsEncryptedQueue', {
  encryption: sqs.QueueEncryption.KMS_MANAGED,
  dataKeyReuse: Duration.hours(24), // Reduces KMS API calls by 288x vs default
  receiveMessageWaitTime: Duration.seconds(20),
  enforceSSL: true,
});

// Cost-optimized Lambda event source mapping
const fn = new lambda.Function(this, 'Processor', {
  runtime: lambda.Runtime.NODEJS_22_X,
  handler: 'index.handler',
  code: lambda.Code.fromAsset('lambda'),
  timeout: Duration.seconds(30),
});

fn.addEventSource(new eventsources.SqsEventSource(queue, {
  batchSize: 10,                          // Max messages per invocation
  maxBatchingWindow: Duration.seconds(5), // Wait for batch to fill
  reportBatchItemFailures: true,          // Don't reprocess successful messages
}));

For more on structuring CDK projects like this, see the AWS CDK best practices guide and the overview of CDK construct levels.

Terraform

# Dead-letter queue with 14-day retention
resource "aws_sqs_queue" "dead_letter_queue" {
  name                      = "my-dlq"
  message_retention_seconds = 1209600          # 14 days
  sqs_managed_sse_enabled   = true             # Free SSE-SQS encryption
}

# Cost-optimized standard queue
resource "aws_sqs_queue" "main_queue" {
  name = "my-queue"

  receive_wait_time_seconds  = 20              # Long polling: eliminates empty receives
  sqs_managed_sse_enabled    = true            # Free encryption (not KMS)
  message_retention_seconds  = 345600          # 4 days
  visibility_timeout_seconds = 180             # 6x your Lambda timeout

  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.dead_letter_queue.arn
    maxReceiveCount     = 5                    # Avoid premature DLQ failures
  })

  tags = {
    Environment = "production"
    Team        = "backend"
    CostCenter  = "messaging"
  }
}

# FIFO queue (25% more expensive - only when needed)
resource "aws_sqs_queue" "fifo_queue" {
  name                        = "my-queue.fifo"
  fifo_queue                  = true
  content_based_deduplication = true
  receive_wait_time_seconds   = 20
  sqs_managed_sse_enabled     = true
}

# DLQ redrive allow policy
resource "aws_sqs_queue_redrive_allow_policy" "dlq_policy" {
  queue_url = aws_sqs_queue.dead_letter_queue.id

  redrive_allow_policy = jsonencode({
    redrivePermission = "byQueue"
    sourceQueueArns   = [aws_sqs_queue.main_queue.arn]
  })
}

# If KMS required for compliance, maximize data key reuse
resource "aws_sqs_queue" "kms_encrypted_queue" {
  name                              = "kms-encrypted-queue"
  kms_master_key_id                 = "alias/aws/sqs"
  kms_data_key_reuse_period_seconds = 86400    # 24 hours - reduces KMS costs by 288x
  receive_wait_time_seconds         = 20
}

# Cost-optimized Lambda event source mapping
resource "aws_lambda_event_source_mapping" "sqs_trigger" {
  event_source_arn                   = aws_sqs_queue.main_queue.arn
  function_name                      = aws_lambda_function.processor.arn
  batch_size                         = 10      # Max messages per invocation
  maximum_batching_window_in_seconds = 5       # Wait for batch to fill
  function_response_types            = ["ReportBatchItemFailures"]
}

Embedding cost optimization into your IaC templates is the foundation of a shift-left approach to FinOps, catching expensive defaults at code review instead of on your monthly bill.

Before committing to SQS, it's worth comparing its costs to the other AWS messaging services.

SQS vs SNS vs EventBridge: Pricing Comparison

"Should I use SQS, SNS, or EventBridge?" is one of the most common architecture questions, and cost is a major factor. Here's how the three services compare on pricing. For detailed estimates on each, use the SNS pricing calculator and EventBridge pricing calculator.

Base Pricing Comparison

*SNS delivery to SQS and Lambda is free, but data transfer charges apply at internet data transfer rates.

Cost at Scale (1M, 10M, 100M Messages)

For a simple point-to-point messaging pattern (one producer, one consumer):

These are simplified comparisons. The real cost depends on your architecture: SQS requires consumers to poll (which costs requests), SNS pushes to subscribers (but you still need a consumer endpoint like SQS or Lambda), and EventBridge matches events against rules before routing them. The total system cost includes all the components, not just the messaging service.

When Each Service Is Most Cost-Effective

• SQS is cheapest for point-to-point queuing with batch operations. If you're processing messages one-at-a-time between a producer and consumer, batched SQS at $0.40/M (effectively $0.04/M per message with full batching) is hard to beat
• SNS wins for fan-out patterns. One publish, multiple deliveries. If you need to send the same message to 5 SQS queues, SNS publishes once ($0.50) and delivers to all 5 at the data transfer rate, cheaper than publishing to 5 queues separately
• EventBridge is ideal for content-based routing at moderate volumes. The $1.00/M rate is the highest base price, but rule-based routing means you don't need custom filtering logic, and AWS management events are free. The 14 million free Scheduler invocations/month are also generous

The bottom line: for high-volume, point-to-point messaging, SQS with batching is the most cost-effective option. For fan-out or event routing, look at SNS or EventBridge. Most production architectures use a combination of all three.

Key Takeaways

Amazon SQS pricing is pay-per-request across three queue types: Standard ($0.40/M), FIFO ($0.50/M), and Fair Queues (Standard + $0.10/M surcharge). The pricing model is simple, but the actual bill depends on how well you optimize.

The two biggest cost levers are batch operations (up to 93% savings) and long polling (eliminates empty receive charges). These two alone can reduce most SQS bills by an order of magnitude. Beyond that, keeping messages under 64 KB, using SSE-SQS instead of SSE-KMS, and monitoring idle queues round out the optimization playbook.

Fair Queues, launched in July 2025, are worth the $0.10/M surcharge for multi-tenant workloads with noisy-neighbor concerns. Just be aware that including a MessageGroupId on any message activates the surcharge for that request.

For custom cost estimates, model your workload with the SQS pricing calculator. And if you're comparing messaging services, SQS with batching is the cheapest option for point-to-point queuing, while SNS and EventBridge have cost advantages for fan-out and event routing respectively.

What's driving your SQS costs? Found hidden charges I didn't cover, or have optimization strategies that worked for your team? Drop your experience in the comments.

Frequently Asked Questions