What Breaks Ordering, Service by Service on AWS - SQS FIFO, SNS FIFO, Kinesis, Amazon MSK, DynamoDB Streams, and the EventBridge Custom Event Bus

First Published:
Last Updated:

When designing event-driven processing, it's easy to assume that using FIFO queues or defining partition keys guarantees order. AWS documentation does contain sentences that promise order. However, in the services this article covers, these promises are always limited to a specific unit, and that unit varies from service to service. For Amazon SQS FIFO queues and Amazon SNS FIFO topics, the unit is a message group. For Amazon Kinesis Data Streams, it's a partition key within a shard (when using USER_PARTITION_KEY). For Amazon DynamoDB Streams, it's an item. For the Amazon EventBridge Custom Event Bus, it's an event group, specific to the publishing account, within the same FIFO subscriber. For Amazon MSK, no explicit statement guaranteeing order within a partition is found in the developer guide.

Even within these units, the promise breaks. The way the sender writes, the service's distribution method, account boundaries, the type of target along the way, and the receiver's parallelization and retry limits each break the promise. Two features introduced in September 2026 changed the scope of these promises in different directions. Kinesis's service-managed record distribution, launched on September 23, 2026, ignores partition keys and does not guarantee order. The EventBridge Custom Event Bus, introduced on September 24, 2026, added an ordering guarantee that earlier buses did not have, but only FIFO subscribers make that promise. Furthermore, even when publishing with the same EventGroupId, events are treated as separate groups if they originate from different accounts.

This article places in the same row, for each service, the sentence in which the documentation promises order, the unit within which that promise holds, and the conditions under which the documentation says the promise breaks. It then shows where along the path from the sender through the service and the delivery in between to the receiver the promise ends. The article is based solely on AWS documentation and does not reflect any actual testing performed by sending messages. Pricing is not discussed.

Related articles on this site:

Table of Contents

  1. 1. The Scope of This Article and the Date It Was Verified
  2. 2. How to Read the Contract Table
  3. 3. Where the Order Is Set — Senders and Services
  4. 4. Where the Promise Ends on the Way — Delivery Paths
  5. 5. Where the Receiver Breaks the Promise
  6. 6. Order and Duplicates Are Separate Promises
  7. 7. Where the Sources Disagree, and Where No Explicit Statement Is Found
  8. 8. Frequently Asked Questions about Ordering Promises
  9. 9. Summary
  10. 10. References

1. The Scope of This Article and the Date It Was Verified

This section first sets out the three questions this article asks about order. It then outlines the services covered and not covered, the verification date and the sources read, and the names used in this article.

1.1 Verifying Ordering: Three Questions

This article will examine the following three aspects for any service:

  1. Which sentence in the documentation promises order? This article quotes those sentences in English.
  2. Within which unit does that promise hold? This could be a message group, a partition key within a shard, an item, an event group, or similar units.
  3. What does the documentation say makes that promise stop holding?

These three questions apply to a single service. For the entire path of a message, one additional question is necessary: at some point along the path, from sender to receiver, does the ordering promise end? A single service may promise ordering, but that promise does not extend to the entire path. For example, even if an SNS FIFO topic delivers messages in order within a message group, if a subscriber is an SQS standard queue, consumers of that queue may receive messages out of order. Section 4 covers this type of case.

1.2 Services Covered and Not Covered

This article focuses on the following service ordering guarantees:

  • Amazon SQS FIFO queues. For comparison, it also covers standard queues that use MessageGroupId (fair queues).
  • Amazon SNS FIFO topics and their subscriptions.
  • Amazon Kinesis Data Streams, including the service-managed record distribution introduced on September 23, 2026.
  • Partitions within Amazon MSK topics.
  • Amazon DynamoDB Streams and Kinesis Data Streams for DynamoDB.
  • Subscribers on the Amazon EventBridge Custom Event Bus (introduced on September 24, 2026). For comparison, it also covers the Custom Event Bus - Classic.
  • AWS Lambda event source mappings (hereafter referred to as ESM) and the Kinesis Client Library (KCL).

The following topics are not covered in this article and are left to existing articles on this site.

1.3 The Verification Date and the Sources Read

This article's information was verified by reviewing AWS documentation on October 4, 2026. Since the docs.aws.amazon.com pages do not display update dates, this date is considered the verification date. The documentation reviewed included developer guides and user guides for each service, API references, AWS CloudFormation references, console help panels, What's New, the AWS News Blog, the AWS Compute Blog, the AWS Architecture Blog, and the Amazon MSK FAQ.

For the places where this article says that no guarantee is written, it did not stop at reading a single page. This article searched the full text of all 451 pages in the table of contents of the Amazon MSK Developer Guide for words that express order. It also searched, in the same way, all 52 pages of the service-managed record distribution chapter of the Kinesis Data Streams Developer Guide and all 35 pages of the Custom Event Bus chapter of the EventBridge User Guide. Nevertheless, the results presented here reflect only the scope of the information found. This article differentiates between instances where the documentation explicitly states that there is no guarantee and cases where no explicit statement of a guarantee is found.

1.4 Distinguishing Terms with the Same Spelling and Terminology Used in This Article

When discussing ordering, the same spelling may refer to different concepts depending on the service. This article uses the following terminology to differentiate them:

  • Message Group: Refers to groups defined by the MessageGroupId in SQS FIFO queues and SNS FIFO topics. While MessageGroupId can also be assigned to SQS standard queues, in that case, it serves as a tenant identifier for fair queues and does not determine order.
  • Event Group: Refers to groups defined by the SystemMetadata.EventGroupId when publishing to the EventBridge Custom Event Bus. This article keeps the name event group to distinguish it from a message group.
  • Partition Key: In Kinesis Data Streams, this is the key used to assign records to shards. In DynamoDB, it is a part of the key for a table's items. When this article simply refers to "partition key," it refers to the partition key in Kinesis. When referring to DynamoDB keys, it says "DynamoDB partition key."
  • Partition: In Amazon MSK (Apache Kafka), this refers to a unit within a topic. This article calls it a Kafka partition. In DynamoDB, a table's partition is a location for data and is not a unit of ordering.
  • FIFO: This refers to three elements: SQS FIFO queues, SNS FIFO topics, and the Type value for EventBridge subscribers. EventBridge subscribers with a Type of FIFO are called FIFO subscribers, and those with a Type of UNORDERED are called UNORDERED subscribers.

2. How to Read the Contract Table

This article lines up each service's ordering promise in the Contract Table. This section defines the table's columns, the labels that open the breaking conditions, and the rules for the cells.

2.1 Columns

The columns in the table represent the following five elements:

  • Service or Endpoint: This indicates the service or pathway between two services that the row addresses.
  • What the Source Promises: This is the sentence in which the source promises order. The sentence is quoted in English, as written, in double quotation marks. For long sentences, the full sentence is quoted in the text after the table. If the source explicitly states that it does not guarantee order, that sentence is quoted.
  • Within What: This specifies the unit within which the promise holds true. The unit is given as the source states it.
  • What Breaks It: This describes the conditions, as stated in the source material, under which the promise no longer holds true. Each condition begins with one of the labels defined in Section 2.2.
  • Where the Source Says So: This indicates the page in the source material from which the information was taken. The formal title and URL of the page should be included in the References section.

2.2 The Labels That Open What Breaks It

In the What Breaks It column, each condition begins with one of the following labels. This lets readers compare, across rows, where the promise breaks. Requirements that the source states for keeping the promise also begin with one of these labels.

  • Sender: The promise breaks due to issues with the sender, such as multiple senders, APIs that write records in batches, or writes without a parameter for ordering.
  • Distribution: The promise breaks due to issues with the service's method of distributing records or messages, including switching between different methods.
  • Account boundary: The promise breaks at account boundaries.
  • Delivery target: The promise breaks due to issues with intermediate delivery targets or the units used at the target.
  • Hand-off: The promise breaks at an asynchronous hand-off.
  • Parallelism: The promise breaks due to the receiver's parallel processing.
  • Retry limit: The promise breaks due to discarding or dropping when the retry limit is reached.
  • Dead-letter queue: The promise breaks when messages are moved to a dead-letter queue (DLQ).
  • Reprocessing: The promise breaks when the same record or message is processed again.
  • Resharding: The promise breaks due to shard splits, merges, or parent-child lineage.
  • Configuration change: The promise breaks when a configuration change leads to resource replacement.
  • Failover: The promise breaks when switching to a cluster in another Region.

2.3 Cell Rules

  • For cells where the source material does not provide information, write The source does not say. Before writing this, search the entire document referenced, the link it points to, and other pages within the same service (API reference, troubleshooting, console help panels) using the words order, ordering, sequence, guarantee, not, and only, together with the words for the subject of the row.
  • Do not write The source does not say. if the source material only describes general rules and does not name the subject of the row. Instead, write the general rule and state that the source does not name the subject of the row.
  • For rows with no promise, write in the What Breaks It column any additional information the source material provides about that row. If there is no such information, write Not applicable.
  • Do not leave the Within What column blank. For rows without a specified unit, write "None."
  • In the What Breaks It column, only include conditions explicitly stated in the source material. Anything that can be inferred from the source's sentences goes in the text outside the table, kept apart from the source's sentences.
  • Do not include both order and duplication within the same cell. Promises about duplicates are listed separately in Table Part 4 (Section 6).

The table is divided into four parts: Table Part 1 covers the stages where the sender and service determine the order (Section 3), Table Part 2 covers the intermediate delivery stage (Section 4), Table Part 3 covers the receiver's stage (Section 5), and Table Part 4 lists the promises about duplicates (Section 6).

3. Where the Order Is Set — Senders and Services

This section covers the stages at which the order is set, where the sender writes and the service arranges messages or records. Table Part 1 lists 10 rows first, and then the full text of the sources is quoted for each service.

3.1 Contract Table, Part 1 — Senders and Services

Service or EndpointWhat the Source PromisesWithin WhatWhat Breaks ItWhere the Source Says So
SQS FIFO queue"Within a message group ID, all messages are sent and received in strict order."Within the same message group ID (MessageGroupId). Messages with different message group IDs may have their order altered.Sender: If multiple senders use the same message group ID, SQS stores and processes messages in the order they are received. The documentation recommends using a different message group ID for each sender to maintain sender-specific order. Dead-letter queue: The documentation advises against using dead-letter queues with FIFO queues if you need to ensure the precise order of messages and operations.FIFO queue delivery logic in Amazon SQS, Using dead-letter queues in Amazon SQS
SQS FIFO queue (high throughput mode)The sources disagree. The queue types page states "with relaxed ordering within message groups", while the high throughput page states "while maintaining strict message order" (Section 7.1).The queue types page says within message groups. The high throughput page does not name a unit.The source does not say.Amazon SQS queue types, High throughput for FIFO queues in Amazon SQS
SQS standard queue with MessageGroupId (fair queues)No ordering guarantees are provided. The documentation states that the MessageGroupId for standard queues is used only as a tenant identifier for fair queues and "does not enforce message ordering."None.Distribution: Fair queues reorder messages to prioritize messages from other tenants if one tenant builds a backlog in the queue.Amazon SQS fair queues, What's New (July 21, 2025)
Kinesis data stream (USER_PARTITION_KEY, default)"To guarantee strictly increasing ordering, write serially to a shard and use the SequenceNumberForOrdering parameter."The same partition key within the same shard. The guarantee provided by SequenceNumberForOrdering applies only to writes from the same client to the same partition key.Sender: If SequenceNumberForOrdering is not specified, records are roughly ordered based on their arrival time. PutRecords does not guarantee record order. Resharding: The documentation states that per-partition-key order is maintained when the KCL is used, which first processes the data in the shards from before the resharding. When the KCL is not used, the Complete the resharding action page says to read the data in the parent shards until it is exhausted before reading the child shards.PutRecord, PutRecords, Amazon Kinesis Data Streams Terminology and concepts, Use resharding, scaling, and parallel processing to change the number of shards, Complete the resharding action
Kinesis data stream (AUTO, service-managed record distribution)No ordering guarantees are provided. The documentation states "No ordering guarantees" and advises against using this mode for workloads that depend on order.None. The partition key is ignored.Distribution: Switching from USER_PARTITION_KEY to AUTO removes the guarantee that records with the same partition key will be processed in order within the same shard. Switching back from AUTO routes new records with the same partition key to the same shard again. However, records written while using AUTO will not be moved, so records for a single partition key may be split between shards before and after the switch. Sender: PutRecord requests with SequenceNumberForOrdering specified will be rejected with an InvalidArgumentException.How service-managed record distribution works, Transition behavior, Producer API behavior with service-managed distribution
DynamoDB Streams"For each item that is modified in a DynamoDB table, the stream records appear in the same sequence as the actual modifications to the item."Individual items. This refers to the complete sequence of changes for a given primary key (the DynamoDB partition key, or the DynamoDB partition key and sort key), and not the entire partition.Resharding: Shards have a parent-child relationship. The documentation states that applications must process the parent shard before processing child shards. The DynamoDB Streams Kinesis Adapter and Lambda ESM handle this.Change data capture for DynamoDB Streams
Kinesis Data Streams for DynamoDBNo ordering guarantee is provided. The documentation states, "The Kinesis data stream records might appear in a different order than when the item changes occurred."None. The order of item changes can be verified using the ApproximateCreationDateTime attribute.Distribution: When the destination stream is a service-managed record distribution stream, the change records for a single item are distributed across multiple shards. The documentation states, "DynamoDB makes no ordering guarantee based on shard placement."Using Kinesis Data Streams to capture changes to DynamoDB, Amazon DynamoDB with Kinesis data streams
Amazon MSK topic partitionsNo explicit statement guaranteeing order within a partition was found in the developer guide. While the page on tiered storage for Standard brokers states that older data can be reprocessed "in its exact production order", it does not name the unit. The console help panel defines a partition as "a segment of a topic that stores an ordered sequence of messages", but this is a definition of the partition itself, and does not promise an order in which messages are delivered to consumers.The documentation does not name a unit for an ordering promise. The help panel's definition is about Kafka partitions.Failover: The failover and failback procedures for MSK Replicator say that applications that require order should first start consumers only for the replicated topics, wait for the lag to reach zero, and then switch to the local topics.Topic partitions (MSK console help panel), Tiered storage for Standard brokers, Unplanned failover, Failback
EventBridge Custom Event Bus (FIFO subscribers)"A FIFO subscriber delivers events in the order that they were published within an event group."Within the same FIFO subscriber, and within the same event group (identified by SystemMetadata.EventGroupId). An event group belongs to the account that published it.Account boundary: If two accounts publish to the same bus with the same EventGroupId, they will form two separate event groups, and there will be no ordering between events from either account. Sender: The AWS Compute Blog states that a FIFO subscriber has nothing to sequence by for events published without an EventGroupId. The Custom Event Bus chapter of the user guide does not name the order in this case. Configuration change: A subscriber's Type cannot be changed after it is created. Changing it in CloudFormation replaces the subscriber, and events published in the gap are not delivered unless you plan for the gap.Ordering and deduplicating events on a Custom Event Bus, Building event-driven applications at scale with Amazon EventBridge, Ordering type (EventBridge console help panel), Creating Custom Event Bus resources with CloudFormation
EventBridge UNORDERED subscribers and Custom Event Bus - ClassicNo ordering guarantee is provided. The CloudFormation reference states, "UNORDERED delivers without an ordering guarantee." The Custom Event Bus - Classic has "Not available." in the Ordering row of the comparison table.None.Distribution: The documentation states that UNORDERED subscribers deliver events in parallel to achieve the highest throughput.AWS::EventsV2::Subscriber, Ordering and deduplicating events on a Custom Event Bus, What is the EventBridge Custom Event Bus?

This table has one The source does not say. cell. In the What Breaks It column of row 2, the documentation does not say how the relaxed ordering breaks. Row 8 records that no explicit ordering promise is found in the developer guide, and gives as written the tiered storage passage that names no unit and the help panel's defining sentence. For row 9, the order in the case where no EventGroupId is attached is recorded as something that the Custom Event Bus chapter of the user guide does not name, kept apart from what the Compute Blog says.

3.2 SQS FIFO Queues — Within a Message Group ID, in the Order of Arrival

The ordering guarantees for SQS FIFO queues are described on the FIFO queue delivery logic in Amazon SQS page.

Within a message group ID, all messages are sent and received in strict order.
Messages with different message group IDs may arrive or be processed out of order relative to one another.

The unit of this guarantee is the message group ID, not the entire queue. If you want to process all messages in a queue in a single order, the same page recommends using the same message group ID for all messages.

When multiple senders use the same message group ID, the order in which messages are delivered is determined by when SQS receives them, not necessarily by the order in which the senders sent them. The same page states:

If multiple producers or threads send messages with the same message group ID, Amazon SQS ensures they are
stored and processed in the order they arrive.
Best practice: To guarantee strict message order across multiple producers, assign a unique message group ID
for all messages from each producer.

Senders can retry SendMessage requests with the same message deduplication ID. The documentation indicates that if the sender receives at least one acknowledgment before the deduplication interval expires, the retry will not introduce duplicates and will not disrupt the order.

On the consumer side, the next message with the same message group ID is not returned until the received message is deleted or its visibility timeout expires. If a message continues to fail processing, that group will stall. The Troubleshoot Amazon SQS dead-letter queue and DLQ redrive issues page states:

Therefore, although the consumer can continue to retrieve ordered messages from another message group, the first
message group remains unavailable until the message blocking the queue is processed successfully or moved to a
dead-letter queue.

Moving a message to a dead-letter queue to unblock a stalled group breaks the order. The Using dead-letter queues in Amazon SQS page includes the following note:

Don't use a dead-letter queue with a FIFO queue if you don't want to break the exact order of messages or
operations.

In contrast, assigning a MessageGroupId to an SQS standard queue enables fair queues. This MessageGroupId does not determine order. The Amazon SQS fair queues page states:

On standard queues, MessageGroupId is used only as a tenant identifier for fair queues and does not enforce
message ordering.

The What's New update from July 21, 2025, explains that fair queues reorder messages when a single tenant builds a backlog in the queue, prioritizing messages from other tenants. Even with the same MessageGroupId name, it functions as a unit of order for FIFO queues and as a tenant identifier for reordering in standard queues.

The sources disagree on the ordering of FIFO queues in high throughput mode. Section 7.1 covers this.

3.3 Kinesis Data Streams — The Same Partition Key Within a Shard

Kinesis Data Streams sequence numbers are unique for each partition key within a shard. The Amazon Kinesis Data Streams Terminology and concepts page states:

Each data record has a sequence number that is unique per partition-key within its shard.
...
Sequence numbers for the same partition key generally increase over time.

The conditions for strictly increasing order are in the PutRecord API reference.

Sequence numbers increase over time and are specific to a shard within a stream, not across all shards within a
stream. To guarantee strictly increasing ordering, write serially to a shard and use the SequenceNumberForOrdering
parameter.

The same reference explains the scope within which SequenceNumberForOrdering guarantees order, as well as the behavior when it is not specified.

Guarantees strictly increasing sequence numbers, for puts from the same client and to the same partition key.
...
If this parameter is not set, records are coarsely ordered based on arrival time.

Strict ordering is achieved when records are written sequentially using the PutRecord API, from the same client, to the same partition key, and each record includes the sequence number of the previous record. The PutRecords API, which allows for batch writes, does not guarantee order, as stated in the API reference.

As a result, PutRecords doesn't guarantee the ordering of records. If you need to read records in the same
order they are written to the stream, use PutRecord instead of PutRecords, and write to the same shard.

Regarding shard splitting and merging (resharding), the page Use resharding, scaling, and parallel processing to change the number of shards describes the behavior of the KCL as follows:

The KCL ensures that any data that existed in shards prior to the resharding is processed first. After that data
has been processed, data from the new shards is sent to record processors. In this way, the KCL preserves the
order in which data records were added to the stream for a particular partition key.

This page states that order is preserved when the KCL is used. It does not name what consumers should do when the KCL is not used.

The Complete the resharding action page describes how to read after resharding, including without the KCL, as follows:

If you read data from the child shards before having read all data from the parent shards, you could read data
for a particular hash key out of the order given by the data records' sequence numbers. Therefore, assuming
that the order of the data is important, you should, after a reshard, always continue to read data from the
parent shards until it is exhausted. Only then should you begin reading data from the child shards.

3.4 Kinesis Service-Managed Record Distribution — The Side Without a Guarantee

On September 23, 2026, Kinesis Data Streams introduced a new method for the service to assign records to shards. This feature is announced under the name Service-Managed Partition Keys, documented in the developer guide as service-managed record distribution, and uses the value AUTO in the API. This functionality is only available for on-demand streams (On-Demand Standard and On-Demand Advantage) and is not supported for provisioned streams. The default method is USER_PARTITION_KEY.

The page detailing how service-managed record distribution works describes the feature as follows:

No ordering guarantees – Because the service distributes records across shards using internal algorithms,
records with the same business entity do not necessarily arrive at the same shard. Do not use this mode for
workloads that depend on ordering.
Partition keys are ignored – When service-managed mode is enabled, any partition key values provided in PutRecord
or PutRecords API calls are ignored. The service handles distribution internally.

This method does not support the use of parameters for ordering. The page Producer API behavior with service-managed distribution explains the behavior regarding SequenceNumberForOrdering as follows:

Must not be provided. PutRecord requests that include this field are rejected with an InvalidArgumentException.
Ordering is not applicable for service-managed distribution.

The method can be switched at any time. Records written before the switch will remain in their original shards. The Transition behavior page describes the records already in the stream and the two directions as follows:

Records already in the stream retain their original shard assignments based on the previous strategy.
...
User-managed to service-managed (USER_PARTITION_KEY → AUTO) – Records that previously shared a partition key were
routed to the same shard and ordered relative to one another. After the switch, new records are distributed
evenly across shards regardless of partition key, so records sharing a partition key are no longer guaranteed to
land on the same shard or be processed in order.
Service-managed to user-managed (AUTO → USER_PARTITION_KEY) – After the switch, new records are again routed by
partition key hash, so records with the same partition key resume landing on the same shard. Producers must
supply a partition key after the switch; PutRecord and PutRecords calls that omit it fail. Records written while
the stream was in AUTO mode keep their original shard placement and are not redistributed, so a single partition
key's records can be split across the pre-switch (AUTO) and post-switch shards.

Switching back from AUTO to USER_PARTITION_KEY restores the unit of order for new records. However, records written while using AUTO and records written after switching back to USER_PARTITION_KEY may reside on different shards, even if they share the same partition key.

3.5 DynamoDB Streams — Item-Level Ordering

The ordering guarantees for DynamoDB Streams are described on the page for Change data capture for DynamoDB Streams.

For each item that is modified in a DynamoDB table, the stream records appear in the same sequence as the actual
modifications to the item.

That same page also specifies the unit of ordering.

DynamoDB Streams guarantees ordering at the level of an individual item—that is, across all modifications to the
same primary key (the partition key, or the partition key and sort key)—not across an entire partition.

The unit is an item. It is not the entirety of a collection of items that share the same DynamoDB partition key. The page explains that item collections can span multiple partitions.

DynamoDB Streams shards are created and split automatically. The same page describes the parent-child relationship between shards as follows.

Because shards have a lineage (parent and children), an application must always process a parent shard before it
processes a child shard.

When using the DynamoDB Streams Kinesis Adapter, the adapter handles this ordering. The page also states that Lambda's ESM processes parent shards before child shards.

For Kinesis Data Streams for DynamoDB, which streams changes from the same table to Kinesis Data Streams, the guarantees differ. The page Using Kinesis Data Streams to capture changes to DynamoDB states:

The Kinesis data stream records might appear in a different order than when the item changes occurred. The same
item notifications might also appear more than once in the stream. You can check the ApproximateCreationDateTime
attribute to identify the order that the item modifications occurred in, and to identify duplicate records.

Furthermore, the shard placement changes if the output stream uses service-managed record distribution. The Amazon DynamoDB with Kinesis data streams page in the Kinesis developer guide states:

On a service-managed stream, the partition key is ignored for routing, so change records for a single item are
distributed across shards. DynamoDB makes no ordering guarantee based on shard placement. Consumers order records
by using the ApproximateCreationDateTime field, so this behavior does not affect correctness for consumers that
order records by timestamp.

A comprehensive comparison of these two approaches is detailed in Section 7.2 of Change Data Capture on AWS Beyond Zero-ETL.

3.6 Amazon MSK — No Explicit Statement Found in the Developer Guide

No explicit statement guaranteeing the order of messages within a Kafka partition is found in the Amazon MSK developer guide. This article searched every page (451 in total) of the document's table of contents, using terms such as order, ordering, ordered, out of order, sequence, and sequential. Sentences that mention the order of messages or data were on four MSK Replicator pages (the three pages on switching to a cluster in a different Region and the active-passive configuration page), the tiered storage page for Standard brokers, and the best practices page (an example of topics written without keys, where order does not matter to consumers). None of these passages explicitly guarantee message order within a partition.

Among the sources read, five passages come closest to discussing order. The first is the definition of a partition in the console's help panel.

A partition is a segment of a topic that stores an ordered sequence of messages.

This passage defines what a partition is, but does not name whether consumers receive messages in that order, or under what conditions that order breaks.

The second is a passage on the Tiered storage for Standard brokers page, which lists it among the features of tiered storage.

You can reprocess old data in its exact production order with your existing stream processing code and Kafka APIs.

This passage also does not name the unit of order (the partition).

The third is the procedure for switching to a cluster in a different Region with MSK Replicator. The Unplanned failover and Failback pages state:

If your application requires message ordering, start consumers only for the replicated topics first, wait for
lag to reach 0, then switch to local topics.

The fourth is on the Lambda side. It is covered in Section 5.4.

The fifth is the Amazon MSK FAQ, which answers the question "What are Apache Kafka's primary capabilities?" as follows:

It stores events as a continuous series of records and preserves the order in which the records were produced.
...
Data consumers can process data from Apache Kafka topics on a first-in-first-out basis, preserving the order
data was produced.

Both sentences describe Apache Kafka in general and do not name the partition. The second sentence names topics.

On October 15, 2025, Amazon MSK added support for Apache Kafka 4.1 and introduced Queues as a preview feature. The What's New post describes how multiple consumers can process messages from the same partition of a topic. However, no description of how this feature affects message order within a partition is found in the MSK developer guide or the What's New post. Express brokers do not yet support this feature (KIP-932: Queues for Kafka is not yet supported on Express brokers.). How the share groups that Queues introduces fit is left to Section 5.4 of Amazon MSK Broker Types and Storage Tiers.

3.7 EventBridge Custom Event Bus — Ordering Is a Property of the Subscriber

On September 24, 2026, EventBridge introduced the Custom Event Bus. The previous buses are now displayed as "Custom Event Bus - Classic" in the console. The What's New post states that existing APIs remain unchanged.

The Ordering and deduplicating events on a Custom Event Bus page explicitly states in its first three sentences that ordering and deduplication are separate concepts.

Ordering is a property of a subscriber. Deduplication happens when you publish. The two are configured in
different places and solve different problems.

Ordering is a property of the subscriber, not of the bus. Subscribers have a Type of either UNORDERED or FIFO, and only FIFO subscribers guarantee ordering.

A FIFO subscriber delivers events in the order that they were published within an event group. You assign the
group when you publish, with SystemMetadata.EventGroupId in each entry of either publish API.

Even if two accounts use the same EventGroupId, they are considered separate groups. The same page further states:

An event group belongs to the account that published it. Two accounts that publish to a shared bus with the same
EventGroupId create two separate groups: their events are not ordered relative to each other, and they do not
share a group's throughput.

If a bus is shared across multiple accounts via AWS RAM, and each account publishes events using the same order ID as the EventGroupId, the events for that order will not be delivered in a single, unified sequence. Instead, there is a separate order for each account.

Within FIFO subscribers, if an event cannot be delivered, subsequent events within the same group will be blocked. Other groups will continue to proceed.

Within a FIFO subscriber, an event that cannot be delivered holds up the later events in its own group while
other groups continue.

The Custom Event Bus chapter of the user guide does not name how FIFO subscribers order events that are published without an EventGroupId. The AWS Compute Blog post, Building event-driven applications at scale with Amazon EventBridge, published on September 28, 2026, states:

A FIFO Subscriber reading events published without a group ID has nothing to sequence by, so the two sides work
together.

The Type of a subscriber cannot be changed after it is created. The console's help panel indicates that to change the type, you must create a new subscriber and delete the old one. Changing the Type in a CloudFormation template will replace the subscriber. The Creating Custom Event Bus resources with CloudFormation page states:

A subscriber replacement deletes the old subscriber before it creates the new one. No subscriber exists between
the two steps. The new subscriber then starts from its own StartingPosition, and LATEST starts from the newest
events, so it never delivers the events published during that window. Changing a target ARN, an ordering type,
or a starting position therefore drops events unless you plan for the gap.

UNORDERED subscribers do not guarantee ordering. The CloudFormation reference describes the Type as follows:

The delivery ordering mode of the subscriber. FIFO delivers events in order within an event group; UNORDERED
delivers without an ordering guarantee.

The Custom Event Bus - Classic has Not available. in the Ordering row of the comparison table in the user guide. An AWS Architecture Blog post from March 10, 2020, discussing EventBridge (rules and targets) before it was named "Classic," states that it does not guarantee event ordering. Section 4 of Event-Driven Architecture Anti-Patterns on AWS covers the failures that come from assuming order on this side.

Ingestion per event group has a limit. The Amazon EventBridge quotas page counts ingestion per event group as the number of events plus their total size in KB in any one-second window, with a default value of 1,500 and No in the Adjustable column, meaning the limit is not adjustable. This limit of 1,500 does not refer solely to the number of events.

4. Where the Promise Ends on the Way — Delivery Paths

This section discusses how the order established by the service is handled during intermediate delivery. These are the delivery from SNS FIFO topics to their subscribers and the delivery from EventBridge FIFO subscribers to their targets.

4.1 Contract Table, Part 2 — Delivery Paths

Service or EndpointWhat the Source PromisesWithin WhatWhat Breaks ItWhere the Source Says So
SNS FIFO topic to SQS FIFO queue"An Amazon SNS FIFO topic always delivers messages to subscribed Amazon SQS queues in the exact order in which the messages are published to the topic".Within a message group. Applies to each subscription, but there is no order between different subscriptions.Sender: The documentation states that when multiple applications publish in parallel, "you effectively delegate message sequencing to the Amazon SNS service". Delivery target: If delivery to a subscription fails (e.g., due to an incorrect queue policy), that subscription fails to receive messages, and the subscriptions fall out of sync. If the subscription does not have a dead-letter queue (DLQ), messages intended for that queue will be lost.Amazon SNS message ordering details for FIFO topics, Amazon SNS message grouping for FIFO topics
SNS FIFO topic to SQS standard queueThere is no promise of order on the consumer side. The documentation states that standard queue consumers "may receive messages out of order".None. Even if the topic delivers messages to the queue in order, this does not apply to standard queue consumers.Delivery target: The subscription is to an SQS standard queue. The documentation indicates that this combination is intended for workloads that tolerate "best-effort ordering".Amazon SNS message ordering details for FIFO topics, Amazon SNS message delivery for FIFO topics
SNS FIFO topic to customer-managed endpointsNot supported. "SNS FIFO topics can't deliver messages to customer managed endpoints".None. The documentation provides examples such as email, mobile apps, SMS, and HTTP(S) endpoints, stating that these cannot be subscribed to.Delivery target: The documentation states that these endpoint types "aren't guaranteed to preserve strict message ordering" and that attempting to subscribe will result in an error.Amazon SNS message delivery for FIFO topics
EventBridge FIFO subscriber to SQS FIFO queue, SNS FIFO topic, Kinesis stream targetThe parameters passed to the target determine the unit of order. The Kinesis stream target page states, "To keep an event group on one shard, use {% $events.SystemMetadata.EventGroupId %}."The unit of the target. For SQS FIFO queues and SNS FIFO topics, it's the MessageGroupId. For Kinesis streams, it's the partition key.Delivery target: The documentation gives the value that copies the event group into the target's unit ({% $events.SystemMetadata.EventGroupId %}) as the usual value for SQS and SNS targets, and as the value that keeps an event group on one shard for Kinesis targets. It does not name the order for other values. Distribution: The Kinesis developer guide states that if the destination stream is a service-managed record distribution stream, the partition key EventBridge passes is ignored for routing.Amazon SQS queue target, Amazon SNS topic target, Kinesis stream target, Amazon EventBridge event bus with service-managed streams
EventBridge FIFO subscriber to Lambda (via EVENT)"order then holds only up to the hand-off into Lambda's asynchronous queue."Within the same event group, up to the hand-off of events into Lambda's asynchronous queue.Hand-off: After a successful EVENT invocation, Lambda's asynchronous queue is responsible for delivering messages to the function's code. The documentation recommends using REQUEST_RESPONSE for ordered processing.Ordering and deduplicating events on a Custom Event Bus, Lambda function target
EventBridge FIFO subscriber to batch-receiving target (including Lambda via REQUEST_RESPONSE)"Within a batch, events keep their publish order."Within the same batch, for each event group. A single batch can contain events from multiple event groups.Parallelism: Targets that process batches in parallel (e.g., functions that process arrays concurrently) lose that order.Batching deliveries to a target, Lambda function target
EventBridge FIFO subscriber retry and DLQ"EventBridge sets each record's MessageGroupId from the events' EventGroupId, so records for one group stay in order."Within the DLQ FIFO queue, for each event group (the MessageGroupId will contain the EventGroupId).Retry limit: While it is retried, a failing event blocks the later events in its group. If the retry limit (by default 5 attempts or 300 seconds, whichever comes first) is reached and there is no DLQ, the event is dropped. Dead-letter queue: The documentation recommends using a FIFO queue for the DLQ of FIFO subscribers.Retry policies and dead-letter queues

This table does not contain any cells labeled The source does not say. The What Breaks It column of row 4 records, as written, only the values that the EventBridge documentation gives for copying the event group into the target's unit, and notes that the documentation does not name the order for other values.

4.2 SNS FIFO Topics — The Promise Changes with the Subscriber Type

SNS FIFO topics deliver messages to the subscribed SQS queue in the order they are published. The Amazon SNS message ordering details for FIFO topics page describes what happens next by the type of the subscribed queue.

An Amazon SNS FIFO topic always delivers messages to subscribed Amazon SQS queues in the exact order in which the
messages are published to the topic, and only once. With an Amazon SQS FIFO queue subscribed, the consumer of the
queue receives the messages in the exact order in which the messages are delivered to the queue, and no
duplicates. With an Amazon SQS standard queue subscribed, however, the consumer of the queue may receive messages
out of order, and more than once.

While the topic delivers messages to the queue in order within a message group, there is no promise about the order in which consumers of a standard queue receive messages. The promise ends not at the topic but at the subscribed queue. Since September 14, 2023, SNS FIFO topics can also deliver messages to SQS standard queues. The Amazon SNS documentation on message delivery for FIFO topics clarifies this combination as follows.

For workloads that tolerate best-effort ordering and at-least-once delivery, subscribing Amazon SQS standard
queues to Amazon SNS FIFO topics ...

The same documentation states that messages cannot be delivered to endpoints managed by customers. It adds that strict ordering is not guaranteed for these endpoint types.

SNS FIFO topics can't deliver messages to customer managed endpoints, such as email addresses, mobile apps, phone
numbers for text messaging (SMS), or HTTP(S) endpoints. These endpoint types aren't guaranteed to preserve strict
message ordering. Attempts to subscribe customer managed endpoints to SNS FIFO topics result in errors.

To deliver messages to a Lambda function, subscribe either a FIFO or standard SQS queue to the topic and trigger the function from that queue. The choice of queue determines which of the two promises above applies.

Order is maintained within message groups. The Amazon SNS documentation on message grouping for FIFO topics provides further details.

Messages that belong to the same group are processed one by one, in a strict order relative to the group.

There is no guaranteed order between different subscribers. The Amazon SNS documentation on message ordering details for FIFO topics states that the order in which each message reaches the subscribers may vary from message to message, noting, Each subscriber is perceived in isolation from any other subscribers. Furthermore, the documentation addresses scenarios where message delivery to a subscriber fails, outlining the process as follows.

Any messages published to the topic that target the incorrectly configured queue are dropped, unless the
corresponding subscription has a dead-letter queue configured.

The same documentation also explains that the topic assigns sequence numbers, which are included in the message body and passed to the subscriber's queue. However, enabling raw message delivery will cause these sequence numbers to be omitted. If your application is designed to verify message order using sequence numbers, enabling raw message delivery will remove this reference.

4.3 EventBridge FIFO Subscribers — Copy the Unit to the Target and Choose the Invocation Type

Even though FIFO subscribers deliver events within an event group in a sequential order, the subsequent target handles order within its own unit. The target pages of the EventBridge user guide give the values that copy the event group into the target's unit. The Amazon SQS queue target page states:

For a FIFO queue, set MessageGroupId; the usual value is the event's group,
{% $events.SystemMetadata.EventGroupId %}.

Similarly, the Amazon SNS topic target page says that the same value is usually used for a FIFO topic's MessageGroupId. The Kinesis stream target page states:

To deliver to a Kinesis data stream, set TargetArn to the stream ARN and add KinesisParameters with a
PartitionKey. To keep an event group on one shard, use {% $events.SystemMetadata.EventGroupId %}.

When the target is a Lambda function, the invocation type (InvocationType) changes the promise. The Ordering and deduplicating events on a Custom Event Bus page states:

A FIFO subscriber accepts InvocationType EVENT for a Lambda target, but order then holds only up to the hand-off
into Lambda's asynchronous queue. Use REQUEST_RESPONSE for ordered processing.

The Lambda function target page describes delivery after EVENT as follows:

After a successful EVENT invoke, delivery to the function's code is governed by Lambda's asynchronous queue,
which is at-least-once. For ordered processing on a FIFO subscriber, use REQUEST_RESPONSE.

Even with REQUEST_RESPONSE, the order can break depending on how the target processes a batch. The Batching deliveries to a target page states:

Within a batch, events keep their publish order. A batch from a FIFO subscriber can hold events from several
event groups; each group's events are in order relative to one another. A target that processes a batch in
parallel, such as a function iterating over the array with concurrency, loses that order.

The promise does not end at the stage of invoking the function. If the function's code processes the array in a batch concurrently, it ends there. The Lambda function target page mentions setting BatchConfiguration.MaxBatchSize to 1 as a configuration that allows the function to receive only one event per invocation. However, this page does not explicitly link this setting to order preservation.

Events that fail to deliver are retried. The Retry policies and dead-letter queues page describes FIFO subscribers as follows:

For a FIFO subscriber, a failing event blocks the later events in its group for as long as it is retried, so a
long retry window trades order for latency.

The retry limit is, by default, either 5 attempts or 300 seconds, whichever comes first. For events that reach the retry limit, a record is written to the DLQ. If no DLQ is configured, the events are dropped. The same page describes the DLQ for FIFO subscribers as follows:

For a FIFO subscriber, use a FIFO queue as the dead-letter queue; EventBridge sets each record's MessageGroupId
from the events' EventGroupId, so records for one group stay in order.

The differences in the default retries and the DLQ between the Custom Event Bus and the Custom Event Bus - Classic are covered in Sections 4.1 and 4.2 of Amazon EventBridge Custom Event Bus and the Classic Bus.

4.4 Tracing Three Paths

A single service's promise doesn't extend across the entire path. The following three paths trace where the promise holds and where it ends.

The first path runs from the sender, through an SNS FIFO topic, an SQS standard queue, to the consumer. The topic delivers messages to the queue in the order they are published within a message group. The promise holds only up to the queue. The consumer of the standard queue may receive messages out of order.

The second path runs from two accounts that publish to an EventBridge Custom Event Bus with the same EventGroupId, through a FIFO subscriber, to a Lambda function. Because event groups are separate for each account, there is no order between events from the two accounts. Within each account's event group, the FIFO subscriber delivers events in the order they were published. If invoked with EVENT, the promise holds only up to the hand-off into Lambda's asynchronous queue. Even if invoked with REQUEST_RESPONSE, the promise ends if the function processes a batch in parallel.

The third path runs from the sender, through a Kinesis data stream, to a Lambda ESM. If the stream uses USER_PARTITION_KEY, the promise covers only records with the same partition key within the same shard. If the sender uses PutRecords, there is no guarantee. If the stream is set to AUTO, there is no guarantee. For streams using USER_PARTITION_KEY, the ESM keeps partition-key-level order even with a higher ParallelizationFactor (aggregated records have conditions). However, it discards records that reach the retry limit and moves on. The ESM stage is discussed in Section 5.

The following diagram illustrates these three paths, organized into four stages: sender, service, delivery, and receiver. Green boxes indicate stages where the promise holds within its unit. Red boxes indicate stages where the promise ends or where there is no promise.

Where an Ordering Promise Holds and Where It Ends
Where an Ordering Promise Holds and Where It Ends

5. Where the Receiver Breaks the Promise

This section covers the receiver's stage, centered on the Lambda ESM. An ESM reads records or messages from sources such as SQS queues, Kinesis streams, DynamoDB Streams, and Kafka topics, and then invokes functions. This article covers these four sources. Parallelization, retry limits, and reprocessing break the promise at the receiver's stage.

5.1 Contract Table, Part 3 — Receivers

Service or EndpointWhat the Source PromisesWithin WhatWhat Breaks ItWhere the Source Says So
Lambda ESM (SQS FIFO queue)"When Lambda reads your messages into batches, each batch might contain messages from more than one message group, but the order of the messages is maintained."Within a message group ID.Reprocessing: When using partial batch responses, the documentation states that the function should stop processing after the initial failure and return all failed messages and unprocessed messages in the batchItemFailures response. This is stated to help maintain order within the queue.Configuring scaling behavior for SQS event source mappings, Handling errors for an SQS event source in Lambda
Lambda ESM (Kinesis and DynamoDB Streams, default configuration)Kinesis: "Lambda processes records in each shard in order." DynamoDB Streams: The documentation states that Lambda "reads that shard's records in sequence-number order."Within a shard.Retry limit: If the function returns an error, processing for that shard stops. After exhausting error handling, Lambda discards the records and moves to the next batch in the stream. The default for MaximumRetryAttempts is infinite (-1), meaning records will be retried until they expire (the sources disagree on how long it stops; see Section 7.1).Using Lambda to process records from Amazon Kinesis Data Streams, Change data capture for DynamoDB Streams, Retain discarded batch records for a Kinesis Data Streams event source in Lambda, Retain discarded records for a DynamoDB event source in Lambda, CreateEventSourceMapping
Lambda ESM (Kinesis and DynamoDB Streams with increased ParallelizationFactor)Kinesis: "Lambda still ensures in-order processing at the partition-key level." DynamoDB Streams: "DynamoDB Streams guarantees ordering per item (partition key and sort key)."Kinesis: Within a partition key. DynamoDB Streams: Within an item; records with the same DynamoDB partition key go to the same concurrent batch.Parallelism: Order within a shard is not guaranteed. An AWS Compute Blog post from July 12, 2021, states "ordering per shard is no longer guaranteed" (Section 7.1).Using Lambda to process records from Amazon Kinesis Data Streams, Using AWS Lambda with Amazon DynamoDB, Understanding data streaming concepts for serverless applications
Lambda ESM (Kinesis aggregated records with ParallelizationFactor)Regarding scenarios without enhanced fan-out, the documentation states, "All of the events inside an aggregated event must have the same partition key. The partition key must also match that of the aggregated event."Partition key.Sender: If the partition key within an aggregated event differs, Lambda cannot guarantee in-order processing per partition key. When using enhanced fan-out, events that "don't correspond to the partition key" are dropped and lost, and are not sent to a configured on-failure destination.Using Lambda to process records from Amazon Kinesis Data Streams
Lambda ESM (Tumbling window)"Records are always processed in order the first time."The documentation does not name the unit for this statement. The tumbling window state is held on a per-shard basis.Reprocessing: In rare cases, such as error handling, the same record may be processed more than once. The documentation states, "If records are processed more than once, they might be processed out of order."Implementing stateful Kinesis Data Streams processing in Lambda
Lambda ESM (for Amazon MSK and self-managed Apache Kafka)"Lambda reads messages sequentially for each Kafka topic partition."Kafka topic partitions. In provisioned mode, Lambda caps MaximumPollers to the number of partitions in the topic to maintain order within each partition.Retry limit: If the function returns an error, Lambda retries the entire batch until the processing is successful or the messages expire. If MaximumRetryAttempts or MaximumRecordAgeInSeconds is configured, records exceeding these limits are discarded, and if an on-failure destination is configured, they are sent there. The Apache Kafka event poller scaling modes in Lambda page lists these error handling controls as features available in provisioned mode. When both infinite retries and an on-failure destination are configured, the retry attempts are limited to a maximum of 10.Configuring Amazon MSK event sources for Lambda, Apache Kafka event poller scaling modes in Lambda, Configuring error handling controls for Kafka event sources, CreateEventSourceMapping
Lambda ESM (for service-managed record distribution streams)No ordering guarantees are provided. The documentation states "No ordering guarantees" for the stream, and states that Lambda's ESM works without modification on service-managed streams.None.Distribution: At the stream level, partition keys are ignored. The Kinesis developer guide tells readers not to assume any ordering relationship between records in a service-managed stream. The Kinesis and Lambda pages this article read do not name the order when the ParallelizationFactor is increased on such a stream.AWS Lambda triggers with service-managed streams, How service-managed record distribution works, Consumer considerations

This table does not contain any cells labeled The source does not say. The What Breaks It column of row 7 records, as written, the general rule in the Kinesis developer guide, and notes that the pages this article read do not name the combination of ParallelizationFactor and service-managed streams.

5.2 The ESM for SQS FIFO Queues

The page on configuring scaling behavior for SQS event source mappings describes the ESM for FIFO queues as follows:

For FIFO queues, Lambda sends messages to your function in the order that it receives them. When you send a
message to a FIFO queue, you specify a message group ID. Amazon SQS ensures that messages in the same group are
delivered to Lambda in order. When Lambda reads your messages into batches, each batch might contain messages from
more than one message group, but the order of the messages is maintained. If your function returns an error, the
function attempts all retries on the affected messages before Lambda receives additional messages from the same
group.

When using partial batch responses (ReportBatchItemFailures), there are conditions regarding how failures are reported. The page on handling errors for an SQS event source in Lambda states:

If you're using this feature with a FIFO queue, your function should stop processing messages after the first
failure and return all failed and unprocessed messages in batchItemFailures. This helps preserve the ordering of
messages in your queue.

If only failed messages are returned, and subsequent messages are processed, this condition is not met. Furthermore, if the queue's redrive policy moves a message to the dead-letter queue (DLQ), as described in Section 3.2, the order breaks. The concurrency limits for FIFO queue event source mappings, based on the number of message group IDs, are detailed in Section 6.2 of the AWS Lambda Concurrency and Scaling Guide.

5.3 The ESM for Kinesis and DynamoDB Streams

By default, a single function instance processes a single shard. The page Using Lambda to process records from Amazon Kinesis Data Streams states:

Lambda processes records in each shard in order. It stops processing additional records in a shard if your
function returns an error.

For DynamoDB Streams, the page Change data capture for DynamoDB Streams states:

When you use AWS Lambda to consume a stream through an event source mapping, Lambda processes each open shard with a
single function instance and reads that shard's records in sequence-number order. Lambda also follows shard lineage
for you, processing a parent shard before its child shards.

A shard that stops on a function error moves on once error handling is exhausted. The page Retain discarded batch records for a Kinesis Data Streams event source in Lambda states:

If the error handling measures fail, Lambda discards the records and continues processing batches from the
stream. With the default settings, this means that a bad record can block processing on the affected shard for
up to one week.

Records that are discarded remain unprocessed, while subsequent records are processed. If an on-failure destination is configured, metadata from failed invocations can be sent. When using an Amazon S3 destination, the entire invocation record is also sent. The corresponding page for DynamoDB Streams states that a bad record can block a shard for up to one day. The default values for MaximumRetryAttempts and MaximumRecordAgeInSeconds are both infinite (-1). The sources disagree on how long a shard stops; this is covered in Section 7.1.

The ParallelizationFactor lets multiple concurrent batches process a single shard, with values ranging from 1 (default) to 10. Regarding the order when increasing this value, the Lambda developer guide states:

When you increase the number of concurrent batches per shard, Lambda still ensures in-order processing at the
partition-key level.

Regarding the ESM for DynamoDB Streams, the page Using AWS Lambda with Amazon DynamoDB states:

With ParallelizationFactor, Lambda runs multiple concurrent batches per shard and groups the records in each
shard by partition key. Within a shard, records that share a partition key go to the same concurrent batch and
are processed in order. Records with different partition keys can be processed concurrently. DynamoDB Streams
guarantees ordering per item (partition key and sort key).

The AWS Compute Blog post New AWS Lambda scaling controls for Kinesis and DynamoDB event sources, which announced the feature on November 25, 2019, describes the same level.

Each parallelized shard contains messages with the same partition key. This means record processing order will
still be maintained and each parallelized shard must complete before processing the next.

On the other hand, the AWS Compute Blog post Understanding data streaming concepts for serverless applications, from July 12, 2021, describes the same configuration as follows:

However, one side effect is that ordering per shard is no longer guaranteed, since the shard's messages are split
into multiple subgroups based upon an internal hash.

These two descriptions do not contradict each other; they simply use different units. Order at the partition-key level (the item level in DynamoDB Streams) is kept, and order at the shard level is not guaranteed. If your processing relies on the order of records with different partition keys within a shard, increasing the ParallelizationFactor will remove that guarantee.

The following figure illustrates a single shard, configured with a ParallelizationFactor of 2. The left side shows the records within the shard in sequence-number order, the center shows the concurrent batches for each partition key, and the right side shows what is kept and what is given up.

What ParallelizationFactor Keeps and What It Gives Up
What ParallelizationFactor Keeps and What It Gives Up
If a producer aggregates Kinesis records with the KPL or a similar tool before writing them, additional conditions apply. The Using Lambda to process records from Amazon Kinesis Data Streams page describes scenarios where you combine ParallelizationFactor with aggregation, differentiating between cases with and without enhanced fan-out.

Without enhanced fan-out: All of the events inside an aggregated event must have the same partition key. The
partition key must also match that of the aggregated event. If the events inside the aggregated event have
different partition keys, Lambda cannot guarantee in-order processing of the events by partition key.
With enhanced fan-out: First, Lambda decodes the aggregated event into its individual events. The aggregated
event can have a different partition key than events it contains. However, events that don't correspond to the
partition key are dropped and lost. Lambda doesn't process these events, and doesn't send them to a configured
failure destination.

When using tumbling windows for aggregation, the initial processing occurs in sequential order. The Implementing stateful Kinesis Data Streams processing in Lambda page describes reprocessing as follows.

Lambda processes each record at least once, but doesn't guarantee that each record is processed only once. In
rare cases, such as error handling, some records might be processed more than once. Records are always processed
in order the first time. If records are processed more than once, they might be processed out of order.

When the stream uses service-managed record distribution, there is no promise at the stream level. The AWS Lambda triggers with service-managed streams page states that the ESM works without modification, and that for records written without a partition key, the event's partitionKey may be null. The ParallelizationFactor ordering statement is a statement at the partition-key level. The Kinesis and Lambda pages this article read do not name how this applies to streams where the partition key is ignored.

5.4 The ESM for Kafka (Amazon MSK)

An ESM that reads a Kafka topic reads each partition in order. The Configuring Amazon MSK event sources for Lambda page states:

Lambda reads messages sequentially for each Kafka topic partition. A single Lambda payload can contain messages
from multiple partitions.

In provisioned mode, you can configure the number of event pollers. The Apache Kafka event poller scaling modes in Lambda page states the maximum limit as follows:

In addition, to maintain ordered processing within partitions, Lambda caps the MaximumPollers to the number of
partitions in the topic.

The Lambda console's help panel describes the "Parallelization Factor" for the Kafka ESM as follows:

Use this configuration to increase concurrent Lambda invocations for each partition, which by default is 1.
Increasing the parallelization factor allows for faster stream processing without the need to over-scale the
number of partitions, while still guaranteeing the order of records processed.

Conversely, the CreateEventSourceMapping API reference states that ParallelizationFactor is (Kinesis and DynamoDB Streams only). Section 7.1 covers this discrepancy.

When a function returns an error, the entire batch is retried. The Configuring Amazon MSK event sources for Lambda page states:

If your function returns an error for any of the messages in a batch, Lambda retries the whole batch of messages
until processing succeeds or the messages expire.

The What's New update from November 24, 2025, announced improvements to error handling for the Kafka ESM. The Configuring error handling controls for Kafka event sources page states that, for both Amazon MSK and self-managed Kafka, you can configure the maximum number of retries, the maximum record age, batch splitting on error, and partial batch responses. The same page also states that if you configure both infinite retries and an on-failure destination, Lambda will automatically retry up to a maximum of 10 times. Records exceeding this limit are discarded and, if an on-failure destination is configured, sent there. The Apache Kafka event poller scaling modes in Lambda page lists these error handling controls as features available in provisioned mode.

6. Order and Duplicates Are Separate Promises

The promise about order and the promise that there are no duplicates are separate promises. The first three sentences of the Ordering and deduplicating events on a Custom Event Bus page state this as follows (Section 3.7).

Ordering is a property of a subscriber. Deduplication happens when you publish. The two are configured in
different places and solve different problems.

This section lines up the promises about duplicates in the same columns as the ordering tables. What the Source Promises gives the promise that there are no duplicates, while Within What specifies the window and scope for eliminating duplicates. The design for idempotency is delegated to Section 9.1 of the AWS Messaging and Event Routing Decision Guide.

6.1 Contract Table, Part 4 — Promises About Duplicates

Service or EndpointWhat the Source PromisesWithin WhatWhat Breaks ItWhere the Source Says So
SQS FIFO queue"Unlike standard queues, FIFO queues don't introduce duplicate messages."Within a 5-minute deduplication interval. DeduplicationScope sets the scope to either the queue or a message group. High throughput mode requires a message group.Sender: The promise applies to retrying SendMessage within the 5-minute interval. Reprocessing: The visibility timeout documentation states that "there's no absolute guarantee that a message won't be delivered more than once during the visibility timeout period" for both standard and FIFO queues.Exactly-once processing in Amazon SQS, Enabling high throughput for FIFO queues in Amazon SQS, Amazon SQS visibility timeout, CreateQueue
SNS FIFO topic"SNS FIFO topics don't deliver duplicate messages to subscribed endpoints."Within a 5-minute deduplication interval. The scope is either the entire topic (if FifoThroughputScope is Topic) or a message group (if FifoThroughputScope is MessageGroup). Once set to MessageGroup, it cannot be reverted to Topic.Delivery target: If the subscriber is an SQS standard queue, the consumer might receive the same message more than once. Reprocessing: The documentation mentions that, as one condition for exactly-once delivery and processing, SQS FIFO queue consumers must process and delete messages before the visibility timeout expires.Amazon SNS message filtering for FIFO topics, Amazon SNS message deduplication for FIFO topics, High throughput FIFO topics in Amazon SNS, Amazon SNS message ordering details for FIFO topics
EventBridge Custom Event Bus (publishing)"EventBridge suppresses a duplicate that arrives within 5 minutes (300 seconds) of the entry it repeats."Within a 5-minute window, and within the same AWS account. If the entry has an EventGroupId, it's within that event group. Otherwise, it covers all of the account's entries without an event group on that bus.Account boundary: Entries with the same key from a different account, or entries from a different event group, are treated as separate events.Ordering and deduplicating events on a Custom Event Bus
EventBridge FIFO subscriber to target"a FIFO subscriber then hands each accepted event to its target once"From the point the bus accepts an event, to the point the FIFO subscriber passes it to its target.Hand-off: Lambda's asynchronous queue after an EVENT invocation is at-least-once. Delivery target: If an SQS FIFO queue target uses a constant deduplication ID, the queue will discard all messages after the first one. Configuration change: When replacing a subscriber with two CloudFormation deployments, the target receives each matching event twice during the overlap.Ordering and deduplicating events on a Custom Event Bus, Lambda function target, Amazon SQS queue target, Creating Custom Event Bus resources with CloudFormation
DynamoDB Streams"Each stream record appears exactly once in the stream."Within the records saved to the stream. This does not refer to the number of times a consumer processes the records.Reprocessing: The documentation states that DynamoDB Streams Lambda consumers might receive the same record more than once due to at-least-once delivery, and retries of function invocations. It clarifies that the exactly-once guarantee applies to records saved in the stream, not to the number of times a consumer processes them.Change data capture for DynamoDB Streams, Best practices using DynamoDB Streams with Lambda
Kinesis Data Streams for DynamoDBThere is no guarantee against duplicates. The documentation states, "The same item notifications might also appear more than once in the stream."None. The ApproximateCreationDateTime attribute identifies duplicates.Not applicable.Using Kinesis Data Streams to capture changes to DynamoDB
Lambda ESMThere is no guarantee against duplicates. The documentation states, "Lambda event source mappings process each event at least once, and duplicate processing of records can occur."None.Reprocessing: With Kinesis partial batch responses, if batchItemFailures contains multiple items, Lambda will checkpoint to the lowest sequence number, and retry all records from that point onward. The documentation states that partial batch responses do not completely prevent the possibility of retrying successful records.How Lambda processes records from stream and queue-based event sources, Configuring partial batch response with Kinesis Data Streams and Lambda

This table does not contain any cells labeled The source does not say. The fifth row records, as written, that the DynamoDB documentation distinguishes between guarantees within the stream and the number of times a consumer processes records.

6.2 The Deduplication Window and Scope Do Not Necessarily Match the Unit of Order

The unit of order and the deduplication scope do not necessarily match, even within the same service.

In SQS FIFO queues, the unit of order is the message group ID. The deduplication scope can be selected as either the queue or the message group via the DeduplicationScope setting. The Amazon SQS exactly-once processing page states:

Unlike standard queues, FIFO queues don't introduce duplicate messages. FIFO queues help you avoid sending
duplicates to a queue. If you retry the SendMessage action within the 5-minute deduplication interval, Amazon SQS
doesn't introduce any duplicates into the queue.

When high throughput mode is enabled, the deduplication scope is limited to the message group. The Enabling high throughput for FIFO queues in Amazon SQS page specifies that setting the deduplication scope to the message group is a requirement for high throughput mode. Even if using the same message deduplication ID, messages sent to a different message group will fall outside the scope of deduplication.

The same applies to SNS FIFO topics. A What's New update from January 21, 2025, describes high throughput mode as follows:

When you enable high-throughput mode, SNS FIFO topics will maintain order within message group, while reducing
the de-duplication scope to the message-group level.

The unit of order remains unchanged, but the deduplication scope is narrowed. The Amazon SNS message deduplication for FIFO topics page lists conditions for exactly-once delivery and processing, including the existence of a subscribing queue with delivery permissions, the consumer deleting messages before the visibility timeout expires, and the absence of network interruptions. Furthermore, it states:

When you configure message filtering, Amazon SNS FIFO topics support at-most-once delivery, as messages can be
filtered out based on your subscription filter policies.

On the Amazon EventBridge Custom Event Bus, deduplication is performed at the time of publishing. The account and the event group define the scope.

EventBridge suppresses a duplicate that arrives within 5 minutes (300 seconds) of the entry it repeats. The check
is scoped to your account, and to the event group when the entry carries an EventGroupId: an entry with the same
key from another account, or in another group, is a different event. An entry without an EventGroupId is still
deduplicated, across all of your account's ungrouped entries on that bus.

When a duplicate is detected, a SuccessCode: DEDUPLICATED is returned. The documentation suggests treating this as a successful event, and notes that code that counts every success as a new event overstates delivery. The documentation also states:

Together, this gives exactly-once ingestion: a duplicate publish within the window is suppressed at the bus, and a
FIFO subscriber then hands each accepted event to its target once, in order, within its group.

The stages after that are a different matter. When invoking a Lambda function asynchronously via EVENT, the queue operates on an at-least-once basis. The Amazon SQS queue target page says that if a constant deduplication ID is passed to an SQS FIFO queue target, the queue discards every message after the first.

The Lambda ESM makes no promise that there are no duplicates. The page detailing how Lambda processes records from stream and queue-based event sources states that ESM processes every event at least once, and that records may be processed redundantly, strongly recommending that functions be made idempotent. Regarding partial batch responses and tumbling windows, each respective page notes that the same record may be processed multiple times. While DynamoDB Streams promises that each stream record appears in the stream only once, the Best practices using DynamoDB Streams with Lambda page distinguishes between this promise and the number of times a consumer processes records.

This is distinct from the DynamoDB Streams guarantee that each stream record appears exactly once in the
stream — that guarantee describes the records that are stored in the stream, not the number of times a consumer
processes them.

Even with deduplication features, idempotency on the consumer side is still necessary. The design for this is outlined in Section 9.1 of the AWS Messaging and Event Routing Decision Guide.

7. Where the Sources Disagree, and Where No Explicit Statement Is Found

This section lists instances where documents for the same service, or a single page, contain conflicting information, and places where no explicit statement is found despite a search. This article does not merge the conflicting sources into one version. This section shows both sides.

7.1 Five Places Where the Sources Disagree

1. Ordering of FIFO Queues in Amazon SQS High Throughput Mode. The Amazon SQS queue types page states:

By enabling high throughput mode, you can scale up to 30,000 transactions per second (TPS) with relaxed ordering
within message groups.

The High throughput for FIFO queues in Amazon SQS page states:

High throughput FIFO queues in Amazon SQS efficiently manage high message throughput while maintaining strict
message order, ensuring reliability and scalability for applications processing numerous messages.

One page says ordering is relaxed, and the other says strict order is maintained. Neither page says how the relaxed ordering breaks. In Table Part 1, row 2, both statements are included, with What Breaks It noted as The source does not say.

2. What EventBridge FIFO Subscribers Use as an Ordering Criterion. The user guide says events are delivered in the order they were published within an event group (Section 3.7). The What's New post of September 24, 2026, states:

Now with native support for strictly ordered use cases, customers can ensure events are processed in the exact
order they were received and new event evaluations allow automatic content based deduplication.

The AWS News Blog, also dated September 24, states:

EventBridge delivers events that share the same EventGroupId in sequence to Subscribers that chose ordered delivery.

The user guide refers to the order in which events are published, while What's New refers to the order in which they are received. What's New does not name the unit (event group). The News Blog names EventGroupId as the unit, but does not name the account that published the events. The Ordering type help panel describes FIFO as "Delivers events one at a time, in sequence." and does not name the event group. Row 9 of Table Part 1 quotes the statement from the user guide that specifies the unit.

3. Which Sources ParallelizationFactor Applies To, and at What Level It Keeps Order. On the sources it applies to, the CreateEventSourceMapping API reference states:

(Kinesis and DynamoDB Streams only) The number of batches to process from each shard concurrently.

The Lambda console help panel has a Parallelization Factor item for the Kafka ESM and says that increasing concurrent invocations per partition still keeps order (Section 5.4). On the level, the Lambda developer guide says order is kept at the partition-key level, while the AWS Compute Blog of July 12, 2021, says order at the shard level is no longer guaranteed (Section 5.3). On the level, the two differ only in unit, and both hold. On the sources it applies to, the API reference and the help panel say different things.

4. How Long an ESM for a Stream Stops Due to Failed Records. The CreateEventSourceMapping API reference describes MaximumRetryAttempts as follows:

(Kinesis, DynamoDB Streams, Amazon MSK, and self-managed Apache Kafka) Discard records after the specified number
of retries. The default value is infinite (-1). When set to infinite (-1), failed records are retried until the
record expires.

The Kinesis discard page states, with the default settings, that a bad record can block processing on the shard for "up to one week." In contrast, the default retention period for Kinesis Data Streams is 24 hours, extendable to a maximum of 8,760 hours. The corresponding page for DynamoDB states "up to one day", which aligns with the 24-hour retention period for DynamoDB Streams. The API reference describes the halting period as lasting until the records expire, while the Kinesis page specifies a different number of days than the default retention period. In Table Part 3, row 2 lists the default value from the API reference but does not include the numerical value for the duration.

5. The Name of Kinesis Service-Managed Record Distribution, and the API's Description. The name is Service-Managed Partition Keys in the What's New announcement, service-managed record distribution in the developer guide, and AUTO in the API value. Furthermore, the API reference for UpdateStreamRecordDistributionStrategy states the following in its body text:

This operation is only supported for data streams that use the on-demand capacity mode. Provisioned capacity
mode streams do not support the record distribution strategy setting.

The description for ValidationException on the same page reads:

Specifies that you tried to invoke this API for a data stream with the on-demand capacity mode. This API is only
supported for data streams with the provisioned capacity mode.

This article follows the body text of the API reference and the developer guide (applicable only to On-Demand Standard and On-Demand Advantage streams, and not available for provisioned streams).

7.2 Where No Explicit Statement Is Found

For the following four, the documentation does not name the case directly. They are places where no explicit statement was found in a search for an ordering promise.

  • The order of messages within partitions in Amazon MSK. No explicit statement of a guarantee is found in the 451 pages of the developer guide (Section 3.6). There are the help panel's definition, the tiered storage passage that names no unit, the MSK Replicator procedure, the descriptions on the Lambda ESM side, and the FAQ's description of Apache Kafka that names no partition.
  • How an EventBridge FIFO subscriber orders events published without an EventGroupId. No statement that names this is found in the 35 pages of the Custom Event Bus chapter of the user guide. Only a description from the AWS Compute Blog is available (Section 3.7).
  • The impact of Apache Kafka 4.1 Queues (preview) on the order of messages within partitions. The What's New post only states that multiple consumers can process messages from the same partition (Section 3.6).
  • The order of records in a service-managed record distribution stream when the ParallelizationFactor is increased. No statement that names this is found in the 52 pages of the service-managed record distribution chapter of the Kinesis developer guide or in the ESM pages of the Lambda developer guide (Section 5.3). As a general rule, the Kinesis developer guide tells readers not to assume any ordering relationship between records in a service-managed stream.

This article does not state whether these areas are guaranteed or not guaranteed; it only describes what the documentation states.

8. Frequently Asked Questions about Ordering Promises

Q1. Does using SQS FIFO queues or SNS FIFO topics guarantee message order?

Using SQS FIFO queues or SNS FIFO topics guarantees order only within a message group ID. For SQS FIFO queues in high throughput mode, the sources disagree on ordering (Section 7.1). Messages with different message group IDs may be delivered out of order. When multiple senders use the same message group ID, SQS will deliver messages in the order they are received. To maintain order by sender, the SQS documentation recommends using a separate message group ID for each sender. The SNS documentation says that when multiple applications publish to an SNS FIFO topic in parallel, message sequencing is effectively delegated to SNS. If a stuck message in an SQS FIFO queue is moved to a dead-letter queue (DLQ), the order breaks. If an SNS FIFO topic's subscriber is an SQS standard queue, there is no promise about the order in which that queue's consumers receive messages.

Q2. If a partition key is set, is the order preserved in Kinesis?

If the stream uses USER_PARTITION_KEY (the default), the unit of order is the same partition key within the same shard. Strictly increasing order is guaranteed only when writing records one at a time using PutRecord from the same client, to the same partition key, and using SequenceNumberForOrdering. PutRecords does not guarantee the order of records. If the stream uses AUTO (service-managed record distribution), the partition key is ignored, and order is not guaranteed.

Q3. Does increasing the ParallelizationFactor break the order?

In Kinesis streams using USER_PARTITION_KEY, order at the partition-key level is maintained. In DynamoDB Streams, order at the item level is maintained. However, the order of records within a shard is not guaranteed. If your processing relies on the order of records with different partition keys within a shard, that order is no longer guaranteed. When combining ParallelizationFactor with Kinesis aggregation, if you don't use enhanced fan-out, all events within an aggregated event must have the same partition key, and that key must match the partition key of the aggregated event. If you use enhanced fan-out, events that the documentation says "don't correspond to the partition key" are dropped and lost.

Q4. What does it take to pass events from an EventBridge FIFO subscriber to a Lambda function in order?

The sources say the following. Use REQUEST_RESPONSE as the invocation type. With EVENT, the promise holds only up to the hand-off into Lambda's asynchronous queue. Targets that process a batch in parallel lose the order. Use a FIFO queue as the FIFO subscriber's DLQ. According to the AWS Compute Blog, events published without an EventGroupId give the FIFO subscriber nothing to sequence by. Furthermore, the documentation states that publishing events from a different account using the same EventGroupId creates a separate group. Therefore, for events to share a single order, they must be published from the same account and with the same EventGroupId.

Q5. If a Kinesis stream is switched to AUTO and then back to USER_PARTITION_KEY, is the order restored?

Only for records written after the switch back. For those, records with the same partition key land on the same shard again. Records written while the setting was AUTO will remain in their original shards and will not be moved. Therefore, records with a single partition key may end up distributed across different shards, both before and after the switch.

Q6. Does Amazon MSK guarantee order within a partition?

No statement that explicitly guarantees it is found in the developer guide. The Amazon MSK FAQ states that Apache Kafka preserves the order in which records were produced, but that answer does not name the partition. The console's help panel defines a partition as a segment of a topic that stores an ordered sequence of messages. The Lambda ESM reads messages sequentially for each Kafka topic partition, and in provisioned mode, it limits the number of event pollers to the number of partitions to maintain order within each partition. When switching to a cluster in another Region using MSK Replicator, if order is required, the procedure is to first start consumers only for the replicated topics and to switch to the local topics once the lag reaches zero.

Q7. If deduplication is in effect, is the order also preserved?

Not necessarily. Order and duplicates are separate promises. On the EventBridge Custom Event Bus, ordering is a property of the subscriber, while deduplication happens when you publish. In the high throughput mode of SNS FIFO topics, the unit of order remains a message group, but the scope of deduplication is narrowed down to the message group.

9. Summary

The ordering promises of the AWS services this article covers hold only within specific units. The unit is the message group ID for SQS FIFO queues and SNS FIFO topics, the same partition key within the same shard for Kinesis Data Streams (when using USER_PARTITION_KEY), the item for DynamoDB Streams, and, for the EventBridge Custom Event Bus, the event group of each publishing account within the same FIFO subscriber. For Amazon MSK, no explicit statement of a guarantee is found in the developer guide.

Even within these units, the promise breaks. On the sender's side, the conditions include multiple senders, PutRecords, writes without SequenceNumberForOrdering, and publishing without an EventGroupId (as described in the AWS Compute Blog). On the service's side, they include Kinesis's AUTO, switching to it or back, and resharding. In delivery along the way, they include delivery from an SNS FIFO topic to an SQS standard queue, the unit copied to EventBridge targets, the hand-off with Lambda's EVENT, and parallel processing of a batch. On the receiver's side, they include the loss of the order guarantee within a shard when the ParallelizationFactor is increased, discarding at the retry limit, tumbling window reprocessing, and moves to a dead-letter queue (DLQ).

Two features released in September 2026 changed the scope of the promise in different directions. Kinesis's service-managed record distribution ignores the partition key and does not guarantee order. EventBridge's Custom Event Bus adds an ordering guarantee that earlier buses lacked, but limits it to FIFO subscribers and divides event groups by the account that published them.

When verifying your own data paths, apply the three questions from Section 1.1 to each service involved: Which sentence makes the promise? Within what unit does it hold? And what breaks it? Then check that the promise does not end anywhere along the path from the sender to the receiver. The promise about order and the promise about duplicates are separate; even with deduplication, receiver-side idempotency is still required. This article is based on information available as of October 4, 2026.

10. References



References:
Tech Blog with curated related content

Written by Hidekazu Konishi