The FIFO figures are from the SQS quotas page. High throughput mode raises the limits by Region (the page lists, for example, up to 70,000 transactions per second in US East (N. Virginia), US West (Oregon) and Europe (Ireland), and lower numbers elsewhere). Look up your Region before sizing a FIFO design.

When a consumer receives a message, SQS starts the visibility timeout (30 seconds unless you change it). Other consumers cannot see the message until it ends. If the consumer calls DeleteMessage first, the message is gone. If not (crash, exception, slow processing), the message becomes visible and is delivered again.

ChangeMessageVisibility sets a new timeout for one received message, measured from the moment of the call, so a long job can send a heartbeat that keeps extending it. Setting it to 0 releases the message immediately (a polite way to give up). The ceiling is 12 hours from the first receive. For work that needs longer, split it or use AWS Step Functions.

Use long polling everywhere. Set the queue attribute ReceiveMessageWaitTimeSeconds to 20 so that even a careless consumer long-polls, and watch the NumberOfEmptyReceives metric to find consumers that poll wastefully.

• SendMessageBatch, DeleteMessageBatch and ChangeMessageVisibilityBatch handle up to 10 entries per call. They cut the number of requests (and the request-based bill) by up to ten.
• A batch call can succeed overall while some entries fail. Always check the Failed list in the response and retry only those entries.
• You cannot grant permissions to the batch actions separately: permission for SendMessage, DeleteMessage or ChangeMessageVisibility covers the batch version.
• A message timer (DelaySeconds on one message) or a delay queue (queue-level default) hides new messages for up to 15 minutes. It is not a scheduler for later than that: use EventBridge Scheduler (chapter 06).
• Messages over 1 MiB: the SQS Extended Client Library for Java (and for Python) writes the payload to Amazon S3 and sends a small message holding the S3 reference, up to 2 GB. It works only with synchronous clients, and the consumer must also use the library.

• maxReceiveCount is how many times a consumer may receive the message before SQS moves it. A value of 1 sends a message to the DLQ after one failed attempt, so one transient error is fatal. The Lambda guide recommends at least 5 for queues read by Lambda.
• The DLQ must be in the same account and Region as the source queue, and the queue type must match (FIFO source needs a FIFO DLQ, standard needs standard). Create the DLQ first.
• A redrive allow policy on the DLQ controls which source queues may use it: allow all (the default), byQueue with up to 10 source queue ARNs, or denyAll.
• Retention: on a standard queue the message keeps its original enqueue timestamp, so a message that spent 3 days in a queue with 4-day retention has 1 day left in the DLQ. Set the DLQ retention longer than the source (up to 14 days) or poisoned messages vanish before you look.
• Messages moved to a DLQ keep their encryption state; an unencrypted source stays unencrypted in an encrypted DLQ.

The policy is a JSON document stored as a string inside the attribute map, which is why the quotes are escaped twice. Terraform and CloudFormation hide this, the CLI does not.

After you fix the bug, move the dead letters back. SQS has a managed task for it, which replaced the old copy-and-delete scripts. The three API actions are StartMessageMoveTask, ListMessageMoveTasks and CancelMessageMoveTask.

• By default messages go back to the queue they came from. You may name another destination of the same type, and set a maximum velocity (messages per second) so the redrive does not swamp the consumer.
• A redrive task runs at most 36 hours; an account can have up to 100 active tasks.
• Redriven messages are new messages: new message ID, new enqueue time, fresh retention. Redriven messages interleave with live traffic in the destination.
• IAM: the caller needs sqs:StartMessageMoveTask, sqs:ReceiveMessage, sqs:DeleteMessage and sqs:GetQueueAttributes on the DLQ, and sqs:SendMessage on the destination. If a queue policy restricts access to a VPC endpoint, add an aws:CalledViaLast exception so the redrive service can act.
• Moving between FIFO queues replaces the original deduplication ID with the original message ID, so the DLQ does not drop two independent messages that happened to share a deduplication ID.

• Receiving: one ReceiveMessage can return up to 10 messages from the same group, in order. You cannot ask for a particular group. You cannot get the next message of a group until the received ones are deleted or become visible again.
• A failing message blocks its group. The group waits until the message is deleted or expires (or is moved to a DLQ, see chapter 03). Other groups keep flowing.
• Producers: if several producers share a group ID, SQS orders their messages by arrival. For strict per-producer order, give each producer its own group ID.
• Deduplication: a message with the same MessageDeduplicationId as one already accepted within a 5-minute window is acknowledged but not delivered again, even if the first one was already received and deleted. Provide the ID yourself, or enable content-based deduplication and let SQS hash the body.
• Producer retries are safe. If SendMessage times out, resend with the same deduplication ID. For ReceiveMessage, a retry can reuse the same receive request attempt ID.

FIFO limits are counted in API requests per partition, not messages. Without high throughput mode each partition handles 300 transactions per second per action, or 3,000 messages per second if every call is a batch of 10. High throughput mode raises that (by Region), and SQS spreads message groups over partitions, so many distinct group IDs let it scale. The in-flight limit for FIFO is 120,000 messages. The CloudWatch metric ApproximateNumberOfGroupsWithInflightMessages shows how many lanes are actually busy: a big backlog with a low value means too few groups or too few consumers.

A different problem: many tenants share one standard queue and one tenant floods it, so everyone else's messages wait behind the flood (the noisy neighbour problem, measured as dwell time). Amazon SQS fair queues address this without any queue setting: on a standard queue, producers set MessageGroupId to a tenant identifier. SQS watches how many in-flight messages each tenant has, labels a tenant with a disproportionate share as noisy, and prefers messages from the other tenants when it hands messages out.

• It does not rate-limit the noisy tenant: if consumers have spare capacity and nothing else is waiting, the noisy tenant is served at full speed.
• Throughput stays as high as a standard queue and there is no limit on the number of tenants. Ordering is not guaranteed (this is a standard queue).
• The MessageGroupId here means "tenant", not "ordered lane". AWS recommends setting it on every message of a fair queue.
• Metrics include ApproximateNumberOfNoisyGroups and the ...InQuietGroups variants (for example ApproximateAgeOfOldestMessageInQuietGroups), which exclude the noisy tenants so you can alarm on what other tenants experience.

A filter policy on a subscription lists attribute names and the values it accepts; SNS delivers only matching messages. By default the policy scope is MessageAttributes; set the subscription attribute FilterPolicyScope to MessageBody to match on fields inside a JSON body. Operators include exact match, prefix, suffix, anything-but, numeric comparisons and ranges, exists, IP address match and case-insensitive equality. A property you do not list in the policy is ignored.

• Filtering is evaluated by SNS before delivery, so unmatched messages cost the subscriber nothing. Different attribute names are AND-ed, several values for one name are OR-ed.
• Changes to a filter policy can take up to 15 minutes to take full effect (eventual consistency). Do not assume a deploy is instant.
• On FIFO topics, filtering makes delivery at-most-once for the filtered-out copies, by definition.

Subscribing a queue needs two things: a subscription (protocol sqs, endpoint the queue ARN) and a queue policy that lets the SNS service principal send to that queue. Scope the policy with aws:SourceArn (and optionally aws:SourceAccount) so only your topic can write to the queue.

By default SNS wraps the message in a JSON envelope (fields such as Type, MessageId, TopicArn, Message, Timestamp, Signature, UnsubscribeURL) and your consumer must unwrap Message. Setting the subscription attribute **RawMessageDelivery to true** strips the SNS metadata and delivers the original body as the SQS message body. With raw delivery on SQS, message attributes are carried across as SQS message attributes; for HTTP/S and Firehose endpoints, attributes are not sent.

The same wiring in Terraform or CloudFormation is the same three resources: a queue, a queue policy, a subscription. Keep them in one stack so the policy always names the right topic ARN.

• Only the HTTP/S policy can be customised (the total retry time cannot exceed 3,600 seconds). Retries use jitter.
• Retries cover server-side errors only. A client-side error (the Lambda function was deleted, the queue policy no longer allows SNS) is not retried.
• When the policy is exhausted, or on a client error, the message is discarded unless the subscription has a dead-letter queue: an SQS queue in the same account and Region (FIFO queue for a FIFO topic subscription). An encrypted DLQ needs a customer managed key whose key policy lets the SNS service principal use it.
• Failed deliveries do not change the subscription's state.

A FIFO topic keeps order per message group and deduplicates by deduplication ID within five minutes, like a FIFO queue. It carries the group ID to subscribed SQS FIFO queues (the group ID is not passed to standard queues). The per-topic default is 3,000 messages per second or 20 MB per second when FifoThroughputScope is Topic, with at most 300 messages per second inside one message group. A FIFO topic allows far fewer subscriptions than a standard one (100 per topic). Use it with SQS FIFO queues for ordered fan-out, such as every consumer seeing price updates for one product in order.

An event has the envelope fields version, id, detail-type, source, account, time, region, resources and a free-form detail. An event pattern has the same shape as the event and matches if every field you list matches. Each value in a pattern is an array (OR), different fields are AND-ed.

• A rule belongs to one bus. One event can match several rules; each rule has up to 5 targets.
• A pattern is limited to 2,048 characters. Rules using wildcards are limited to 30 per bus. The default is up to 300 rules per bus in most Regions.
• Test patterns in the EventBridge Sandbox before attaching them to a rule.

• Targets include Lambda, SQS, SNS, Kinesis, Step Functions, another event bus, and API destinations (HTTPS endpoints with managed authentication and rate limiting).
• An input transformer reshapes the event before the target sees it: you define up to 100 variables with JSON path ($.detail.orderId), then write an input template that uses <orderId>. Reserved variables include aws.events.rule-name and aws.events.event.ingestion-time. Use it to send a target only what it needs.
• Retries: by default EventBridge retries a failed delivery for 24 hours, up to 185 times, with exponential backoff and jitter. Errors that cannot succeed (missing permission, target deleted) are not retried. Both limits are configurable per target.
• DLQ: attach an SQS queue as a dead-letter queue to a target, otherwise an event whose retries are exhausted is dropped.
• The classic bus has no ordering guarantee and at-least-once delivery, so targets must be idempotent (chapter 10).

• An archive stores events from one source bus, optionally filtered by a pattern, for a number of days you choose (indefinitely by default). Replay re-sends archived events to the bus that received them, which is how you recover from a bug or test a new rule against real traffic. Allow about 10 minutes after the events arrived before replaying, and note that EventBridge adds a managed rule so replayed events are not archived again.
• The schema registry stores schemas (AWS event schemas, schemas discovered from live traffic, and custom ones) so developers can generate code bindings instead of hand-writing event classes.

• EventBridge Scheduler is a separate serverless scheduler: cron and rate expressions, or one-time schedules, with flexible time windows, retries and a maximum retention for failed triggers. Delivery is at-least-once. Templated targets exist for SQS, SNS, Lambda and EventBridge, and universal targets reach more than 270 services and over 6,000 API operations. Use it for "run this once at 09:00 next Tuesday", something SQS delay (15 minutes at most) cannot do.
• EventBridge Pipes is for point-to-point integration: one source, optional filter, optional enrichment, one target. Sources are DynamoDB streams, Kinesis streams, Amazon MQ brokers, Amazon MSK, SQS queues and Apache Kafka. Source order is preserved, and you are charged only for events that pass the filter. A pipe replaces the small "read, filter, call, forward" Lambda you would otherwise write.

• A stream is a set of shards. Each record has a partition key, a data blob and a sequence number assigned by Kinesis. The partition key is hashed to choose the shard, so all records with the same key go to the same shard and keep their order there.
• Each shard supports up to 1 MB/s or 1,000 records/s for writes and 2 MB/s (and 5 read transactions per second) for reads. Stream capacity is the sum of its shards.
• A record's data payload can be up to 10 MiB (before base64); the quotas page notes that the design target is intermittent large records of 1 to 10 MiB using burst capacity, not a steady stream of them.
• Hot shards: a skewed partition key (one customer sending most traffic) overloads one shard while others idle. Symptom: WriteProvisionedThroughputExceeded on the stream even though total throughput looks low. Fix with a higher-cardinality key or a key salt.

On-demand has two flavours in the current docs, Standard and Advantage; Advantage allows up to 50 registered enhanced fan-out consumers per stream instead of 20. Details and pricing are on the Kinesis pages.

• Retention is 24 hours by default and can be raised to 365 days (8,760 hours) with IncreaseStreamRetentionPeriod (and lowered, to a minimum of 24 hours, with DecreaseStreamRetentionPeriod).
• Shared-throughput readers call GetRecords; all of them divide a shard's 2 MB/s and its 5 read transactions per second. Add a third and fourth application and each gets less, and latency rises.
• Enhanced fan-out gives each registered consumer a dedicated 2 MB/s per shard, pushed over HTTP/2 with SubscribeToShard, so readers do not compete. Up to 20 registered consumers per stream (50 with On-demand Advantage). It is billed separately.
• The Kinesis Client Library (KCL) is a Java library (other languages through the MultiLangDaemon) that handles worker coordination, load balancing, checkpointing in a DynamoDB lease table, failover, and shard splits and merges. Delivery is at-least-once, so process idempotently. KCL 2.0 and later use enhanced fan-out. AWS recommends the latest version; the docs call out upgrading from KCL 2.6.0 or earlier to 2.6.1 or later.

In provisioned mode you change capacity by splitting a hot shard into two or merging two cold ones (or with UpdateShardCount). The parent shard stops accepting writes and its data stays readable until retention ends; new records go to the child shards. The KCL processes all parent data before the children, which preserves per-partition-key order across a reshard. A hand-written consumer must do the same.

Watch GetRecords.IteratorAgeMilliseconds (how far behind the reader is), ReadProvisionedThroughputExceeded, WriteProvisionedThroughputExceeded and IncomingBytes.

MSK runs open-source Apache Kafka, so producers and consumers from pages 03 and 04 work unchanged. Related managed pieces are MSK Connect (Kafka Connect) and MSK Replicator (cross-cluster replication for provisioned clusters). The set of supported Kafka versions changes, so check the "supported Apache Kafka versions" page before choosing.

MSK is the right answer when you already use Kafka (clients, Kafka Streams, Connect, a team that knows it) or you need Kafka's ecosystem and semantics, including consumer groups and transactions. KDS is simpler when you live in AWS and want nothing to operate.

• Default to SQS for asynchronous work: it is the least to operate, scales without thinking, and its visibility timeout, DLQ and redrive handle failure well.
• SNS plus one SQS queue per consumer when several teams need the same event and each needs its own retries, backlog and failure isolation.
• EventBridge when the routing depends on event content, when the events come from AWS services or SaaS, or when you need schedules and cross-account delivery.
• Kinesis when you need an ordered, replayable stream with several readers and prefer AWS-native, serverless operation.
• MSK when you need Kafka itself: its ecosystem, its consumer-group and transaction semantics, or portability with a Kafka estate elsewhere (pages 02 to 04).
• They compose: a common shape is producers to Kinesis or MSK for the raw stream, a Lambda or Flink job turning it into business events on EventBridge, and SNS to SQS delivering those events to services.

• Batch size: up to 10,000 for a standard queue, 10 for FIFO. Over 10 requires a batch window (MaximumBatchingWindowInSeconds) of at least 1 second; the window applies to standard queues only. A batch is also bounded by the 6 MB synchronous payload limit, so you may get fewer records than the batch size.
• Visibility timeout: the function timeout must not exceed the queue's visibility timeout (Lambda checks), and AWS recommends six times the function timeout (plus the batch window) so retries after throttling do not outrun it.
• DLQ: put the redrive policy on the source queue (an SQS DLQ), not on the Lambda function. Set maxReceiveCount to at least 5.
• Encrypted queue: add kms:Decrypt to the function's execution role. The managed policy AWSLambdaSQSQueueExecutionRole covers the queue permissions.

Concurrency scaling (standard queues): Lambda starts with five concurrent batches and adds up to 300 more concurrent invocations per minute, to a maximum of 1,250 for one mapping. When traffic is low it scales back toward five (and as few as two). Maximum concurrency on the mapping caps how many instances the queue may use, protecting a shared account pool or a downstream database. Provisioned mode (a minimum and maximum number of dedicated event pollers) scales faster and higher at extra cost, and cannot be combined with maximum concurrency. If you set reserved concurrency on the function, leave at least five, or the mapping is throttled.

FIFO: Lambda delivers messages in order per message group, and a failure holds the group until retries are done. Different groups run in parallel.

Without it, one bad record fails the whole batch: every message, including the good ones, returns to the queue and is processed again. Enable ReportBatchItemFailures in the mapping's FunctionResponseTypes, catch exceptions per record, and return the IDs of the ones that failed. Everything not listed is treated as successful and deleted.

• Return an empty list for full success. If the handler throws, the whole batch counts as failed.
• For a FIFO queue, stop at the first failure and report all remaining messages in the batch too, or you break the order.
• With the feature on, Lambda does not scale polling down when invocations fail, which keeps throughput up while a few messages are bad.
• The Powertools for AWS Lambda Batch Processor (Python, Java, TypeScript, .NET) implements this protocol for you.

• Starting position: with LATEST, events can be missed while the mapping is created or updated; use TRIM_HORIZON if you must not miss any.
• Bisect on error halves a failing batch to isolate the bad record; combined with ReportBatchItemFailures it bisects at the returned sequence number.
• A stream consumer must configure retry limits and an on-failure destination, otherwise a single poison record can block a shard until it expires from the stream. This is the biggest operational difference from SQS, where the DLQ is the default escape hatch.

SQS access is the union of two policy systems: identity-based IAM policies attached to the caller, and the queue policy attached to the queue (a resource-based policy). A cross-account caller or an AWS service needs the queue policy to allow it. ListQueues can only be allowed in an IAM policy; every other SQS action supports resource-level permissions, so name the queue ARN.

Policies have size limits (8,192 bytes, 20 statements, 50 principals, 10 conditions per the quotas page), so a queue shared by dozens of topics needs a wildcard condition on aws:SourceArn or a different design.

• SQS has server-side encryption enabled by default on newly created queues. It encrypts the message body only: queue name and attributes, message ID, timestamp and message attributes are not encrypted.
• Only messages sent after encryption is enabled are encrypted; the existing backlog is not re-encrypted.
• All requests to an encrypted queue must use HTTPS and Signature Version 4, and anonymous send or receive is rejected.
• A queue encrypted with the default AWS managed key cannot invoke a Lambda function in a different account. Use a customer managed key for cross-account Lambda.
• Kinesis, SNS and EventBridge (custom bus) support encryption at rest with KMS too; check each service's page for the key-policy details.

SQS standard, SNS, EventBridge, Kinesis (KCL) and Lambda retries are all at-least-once, and visibility timeouts, redrive, replay and ESM retries create duplicates on purpose. FIFO deduplication helps only within its 5-minute window and only on the send side. Correctness therefore comes from the consumer:

• Derive an idempotency key from the message (an order ID plus event type, or the message ID) and record it in the same transaction as the side effect (a unique constraint, or a DynamoDB conditional write that fails if the key exists).
• Prefer naturally idempotent operations: set a field to a value, upsert by key, rather than increment or append.
• For Lambda, the Lambda docs point to Powertools for AWS Lambda, which provides an idempotency utility, and a Batch Processor for partial failures. It is a convenience, not a requirement; the pattern above works without it.
• Use the same idea for external calls: pass an idempotency key to the payment or email provider so a retried message does not charge or mail twice.

SQS metrics are approximate (a distributed system) and some are emitted only while the queue is active, so alarm on several consecutive data points, not a single one. For MSK, use the cluster metrics in the MSK monitoring documentation (consumer lag is the one you will want), not the Kinesis ones.

• SQS and SNS are request-priced. Cost scales with the number of API calls and messages, so batching (up to 10 per call) and long polling (fewer empty receives) cut the bill, and so does not polling from many idle workers.
• EventBridge is event-priced: every event placed on a bus and delivered counts; archives, Pipes and Scheduler have their own meters. A chatty producer on a bus costs more than the same traffic on SNS.
• Kinesis provisioned is capacity-priced: you pay for shard-hours whether or not data flows, plus data put and enhanced fan-out reads. On-demand trades that for per-throughput pricing.
• MSK is infrastructure-priced (brokers and storage), or throughput-priced on Serverless.
• Big hidden costs are elsewhere: data transfer across AZs and Regions, KMS requests on encrypted high-volume queues, Lambda duration and retries, CloudWatch Logs. Model your real volume in the pricing calculator rather than quoting a per-million figure.