Verified AWS Facts — Single Source of Truth

Verified on: 2026-09-21 against official AWS documentation.

Every number in this course comes from this file. Chapters must link here rather than restate values inline, so that one re-verification pass updates the whole course.

Why this file exists. Most SQS tutorials on the internet are 5+ years stale. Several of the values below changed recently and are commonly taught wrong. Those are flagged ⚠️.

1. Message quotas

Source: SQS message quotas

2. Time-based configuration

Sources: message quotas, standard queue quotas, exactly-once processing

⚠️ Teaching note. WaitTimeSeconds defaults to 0 (short polling) on a freshly created queue via the API. The console defaults differ. Never assume long polling is on.

3. Queue quotas

Sources: standard queue quotas, FIFO queue quotas

4. Throughput

Standard queues

Nearly unlimited API calls per second, per action (SendMessage, ReceiveMessage, DeleteMessage). Scales automatically with demand. There is no published per-queue TPS ceiling.

FIFO queues — default (non-high-throughput) mode

FIFO queues — high throughput mode enabled

Limits are on API requests, not messages, and are region-dependent:

Higher limits can be requested via Service Quotas.

Source: SQS message quotas — Message throughput

5. FIFO specifics

• MessageGroupId is required on every send to a FIFO queue; omitting it fails the call. Length ≤ 128 chars; alphanumerics plus punctuation.
• Deduplication requires one of:
  • ContentBasedDeduplication enabled on the queue → SQS takes a SHA-256 of the message body only (⚠️ not the message attributes — two messages differing only in attributes are treated as duplicates), or
  • an explicit MessageDeduplicationId per message.
• Deduplication interval is 5 minutes, fixed. A SendMessage retry within that window does not create a duplicate.
• AWS's phrase "exactly-once processing" means SQS does not introduce duplicates into the queue. ⚠️ It does not mean your consumer runs exactly once — a consumer crash before DeleteMessage still causes redelivery. See Module 09.

Source: Exactly-once processing in Amazon SQS

6. Fair queues (newer feature)

MessageGroupId is now also accepted on standard queues, where it enables fair queues — mitigating noisy-neighbour starvation when one tenant floods a shared queue. AWS recommends including a MessageGroupId on all messages when using fair queues. Fair-queue requests are billed at both fair-queue and standard rates.

Sources: message quotas — Message group ID, SQS pricing

7. Dead-letter queues

• DLQ must be in the same AWS account and Region as the source queue, and the same queue type (a FIFO source needs a FIFO DLQ).
• maxReceiveCount in the redrive policy = how many times a message may be received before it is moved to the DLQ. maxReceiveCount = 1 means one failed receive sends it to the DLQ.
• Redrive allow policy on the DLQ controls which source queues may use it: allowAll (default), byQueue (up to 10 source queue ARNs), or denyAll.
• ⚠️ Standard queues only: if maxReceiveCount > 3 and a message has been received 3 or more times without deletion, SQS moves it to the back of the queue. ApproximateAgeOfOldestMessage then reflects the next message under that threshold — a subtle metric distortion worth knowing during incidents.
• Retention on move:
  • Standard: the original enqueue timestamp is preserved. A message that spent 1 day in the source queue and moves to a DLQ with 4-day retention is deleted after 3 more days.
  • FIFO: the enqueue timestamp resets on the move.
  • → Best practice: DLQ retention longer than source queue retention.
• AWS explicitly warns against DLQs on FIFO queues where strict ordering must never break.

Source: Using dead-letter queues in Amazon SQS

8. Lambda event source mapping (ESM)

Who polls? ⚠️ The Lambda service polls SQS. Your function does not. Lambda calls ReceiveMessage, invokes your function synchronously with a batch, and calls DeleteMessage for the batch only on success.

Default (on-demand) scaling — standard queues

Batching

FIFO queues

Order is preserved; a batch may span multiple message groups. Concurrency is capped by min(number of active message group IDs, MaximumConcurrency). On error, all retries for the affected messages complete before Lambda takes more from that group.

Provisioned mode (newer)

Poller sizing formula AWS publishes:

EPS per event poller = min(
    ceil(1024 / avg event size in KB),
    ceil(10 / avg function duration in seconds) * batchSize,
    min(100, 10 * batchSize)
)
Required event pollers = peak events/sec ÷ EPS per event poller

Failure handling: by default a function error makes the whole batch visible again → duplicate processing of already-succeeded messages. Fix with ReportBatchItemFailures (partial batch response) or by calling DeleteMessage yourself as each message succeeds.

Sources: Using Lambda with Amazon SQS, Configuring scaling behavior for SQS event source mappings

9. Pricing

Verified 2026-09-21. Re-verify before quoting — pricing changes.

The cost lever that matters: a request is an API call, not a message. Batching 10 messages per call cuts request count ~10×. Long polling eliminates billed empty receives.

Sources: Amazon SQS Pricing, tiered pricing announcement

10. Facts commonly taught wrong

Use this list when writing chapters — each deserves an explicit correction.

Re-verification checklist

Re-run before any publish. Values most likely to drift:

• Pricing (§9) — tiers and per-million rates
• FIFO high-throughput regional TPS table (§4)
• Lambda ESM scaling numbers (§8) — AWS has changed these more than once
• Provisioned mode limits (§8)
• In-flight quotas (§3)
• Fair queues — feature status and billing (§6)