Where a Stream Consumer Can Start on AWS - Starting Positions in DynamoDB Streams, Kinesis Data Streams, KCL, and Lambda Event Source Mappings

First Published: 2026-10-23
Last Updated: 2026-10-23

On October 15, 2026, Amazon DynamoDB Streams added AT_TIMESTAMP to GetShardIterator. The AWS What’s New post describes the earlier state as

Previously, you could only start from the oldest retained record (up to 24 hours old) or from new records written after you start consuming the stream.

It also explained,

Timestamp-based stream processing can be used with the Amazon Kinesis Client Library (KCL) through the DynamoDB Streams Kinesis adapter.

This announcement specifically mentions the stream APIs, the KCL, and the DynamoDB Streams Kinesis Adapter. AWS Lambda event source mappings and Amazon EventBridge Pipes are not explicitly mentioned.

This article examines where stream consumers can begin reading, considering each combination of stream and consumer as a contract. For each combination, it outlines what users can write, the available values, what happens if they do not, when starting positions are used, the boundaries (times older than the retention period, future times), and what happens when checkpoints are available. It also identifies where each result becomes visible and what the sources do not state.

This article does not cover the overall design of streaming, order guarantees, consumer selection, or pricing. It also does not recommend specific consumers or starting positions. The sources were checked on October 23, 2026. The results in Section 8 were obtained on October 23, 2026 (UTC) from a small configuration built for this article in the US East (N. Virginia) Region.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. The Starting Position Contract Tables
4. The Stream APIs — Where an Iterator Can Point
5. KCL and the Adapter — When the Initial Position Is Used
6. Managed Consumers — Lambda Event Source Mappings, EventBridge Pipes, and Amazon Data Firehose
7. Value Sets That Shrink by Layer
8. What This Configuration Returned
9. Failure Modes
10. Frequently Asked Questions About Stream Starting Positions
11. Summary
12. References

1. Scope and Assumptions

This section first defines the intended audience, the scope of this article, the sources read, and the names it uses. The key conclusions are as follows:

The starting position has five values in the stream API. This number reduces to three in the client library (KCL), and stays the same or shrinks further for managed consumers. In the sources as of October 23, 2026, the DynamoDB Streams rows for Lambda's event source mappings and EventBridge Pipes have two values, TRIM_HORIZON and LATEST, and do not list AT_TIMESTAMP. Amazon Data Firehose reads from LATEST.
Specifying a timestamp older than the retention period with AT_TIMESTAMP will not result in an error. The DynamoDB Streams API, the Kinesis Data Streams API, and the adapter documentation all state that reading starts from the oldest record. However, specifying a sequence number older than the retention period within DynamoDB Streams might result in a TrimmedDataAccessException.
The handling of future timestamps varies depending on the layer. The DynamoDB Streams API returns a ValidationException, the adapter rejects the request before calling the API, and Lambda's event source mapping indicates cannot be in the future. No statement on a time in the future was found for the Kinesis Data Streams API.
The initial position within KCL is only used when creating a lease. Shards with existing checkpoints will resume from the checkpoint. Modifying the initial position within a running application may make different shards read from different positions. For Lambda's event source mapping, disabling and re-enabling the mapping will cause it to resume from the same position.

1.1 Who This Article Is For

This article is intended for the following readers.

Developers and operations personnel who read DynamoDB Streams or Kinesis Data Streams with Lambda, KCL, or EventBridge Pipes, and who design resuming after failures, reprocessing data from a specific point in time, and skipping over accumulated records
Those who think that the AT_TIMESTAMP feature is available to every consumer from October 15, 2026, that changing StartingPosition makes the next start read from that position, that specifying a time older than the retention period results in an error, or that recreating with LATEST misses no records

None of these matches the statements in the sources read for this article, or each holds only under a condition. What's New names the KCL and the adapter. The Lambda API reference writes AT_TIMESTAMP is supported only for Amazon Kinesis streams, Amazon DocumentDB, Amazon MSK, and self-managed Apache Kafka. in the description of StartingPosition. The KCL configuration table writes This is only used during initial lease creation. about the initial position. The handling of older timestamps is discussed in Section 4.3, and the records that LATEST can miss are covered in Section 6.3.

1.2 What This Article Covers and Does Not Cover

This article focuses on contracts related to the starting position from which consumers begin reading streams. Specifically, it addresses the values and boundaries of GetShardIterator for DynamoDB Streams and Kinesis Data Streams, iterator lifetimes, retention periods, Kinesis Data Streams' SubscribeToShard, KCL initial positions and checkpoints, DynamoDB Streams Kinesis Adapter's AT_TIMESTAMP, Lambda event source mappings, EventBridge Pipes, Amazon Data Firehose, and Kinesis Data Streams channels.

This article does not cover:

Pricing and billing mechanisms.
Ordering guarantees. The previously published What Breaks Ordering, Service by Service on AWS covers the ordering behavior for each service.
The overall design of streaming and the concepts behind reprocessing. The previously published AWS Real-Time Streaming Data Pipeline Architecture Guide covers this.
The implementation details of EventBridge Pipes. The previously published EventBridge Pipes Event-Driven Architecture Implementation Patterns covers this.
Comparisons of different methods for extracting change data. The previously published Change Data Capture on AWS Beyond Zero-ETL covers this.
Details of shard splitting and merging, the throughput of enhanced fan-out, how to write KCL applications, and migration procedures.
Apache Kafka (including Amazon MSK and self-managed Kafka), Amazon DocumentDB, Amazon MQ, Amazon Managed Service for Apache Flink, and Kinesis Data Streams for DynamoDB. Some of these appear in the Lambda API reference notes, but this article does not include them in its tables.

Records that disappear after the retention period are a case of expiration deletion. The previously published When Expired Data Is Actually Deleted on AWS covers when expired data is actually deleted. This article only describes what happens when the starting position falls near the end of a retention period.

1.3 Sources Read and the Date They Were Checked

This article read the following sources on October 23, 2026.

DynamoDB Streams API reference (GetShardIterator, GetRecords, DescribeStream, StreamRecord) and the Amazon DynamoDB developer guide (DynamoDB Streams section, reading from timestamps section, adapter section, Lambda section).
Kinesis Data Streams API reference (GetShardIterator, GetRecords, StartingPosition, SubscribeToShard, CreateChannel) and the Kinesis Data Streams developer guide (retention period, KCL concepts, KCL configuration, KCL lease table, KCL version lifecycle, data delivery).
AWS Lambda API reference (CreateEventSourceMapping, UpdateEventSourceMapping, GetEventSourceMapping) and the Lambda developer guide (DynamoDB, Kinesis, Kafka sections), Lambda console help panel.
EventBridge Pipes API reference (PipeSourceDynamoDBStreamParameters, PipeSourceKinesisStreamParameters, two update types, DescribePipe) and the Amazon EventBridge user guide (Pipes section).
Amazon Data Firehose developer guide, API reference (KinesisStreamSourceConfiguration), FAQ.
AWS CloudFormation template reference (AWS::Lambda::EventSourceMapping, source types for AWS::Pipes::Pipe)
The What's New post of October 15, 2026.
GitHub repository awslabs/amazon-kinesis-client (CHANGELOG, and sources for InitialPositionInStream, InitialPositionInStreamExtended, LeaseManagementConfig) and awslabs/dynamodb-streams-kinesis-adapter (CHANGELOG and sources for StreamsSchedulerFactory).
Sources used to check the scope: the Amazon MSK developer guide (the page on streaming tables to Apache Iceberg), the AWS SDK for Ruby reference (GetShardIteratorInput), the AWS CLI reference, and the AWS CLI v2 CHANGELOG.

As of the check date, the latest version of KCL was 3.5.3 (September 24, 2026), and the latest version of the adapter was 2.5.0.

1.4 Names

This article uses the following names:

Starting position: The position of the first record that a consumer reads. This term encompasses the following: ShardIteratorType in the API, InitialPositionInStream in the KCL, and StartingPosition in Lambda and EventBridge Pipes.
Layer: The location where the starting position is determined. This is divided into three categories: the stream API, the client library (the KCL and the adapter), and managed consumers (Lambda event source mappings, EventBridge Pipes, Amazon Data Firehose, and Kinesis Data Streams channels).
ESM: Lambda event source mapping.
Trim horizon: The position of the oldest record that has not yet been removed after the retention period. This article uses the term of the sources.

The term StartingPosition is also used in Amazon EventBridge for new Custom Event Bus subscribers. However, that setting is separate from the setting of stream consumers, and its values are LATEST and POINT_IN_TIME. The previously published Amazon EventBridge Custom Event Bus and the Classic Bus covers the starting position of subscribers.

2. How to Read the Tables

This section defines the columns in the table presented in Section 3, as well as how to indicate the source of default values.

2.1 Columns

The tables in Section 3 use the following eight column names. Six of them, You Set, Allowed Values, If You Set Nothing, At the Boundary, Where It Shows, and No Statement Found, are common to the articles on this site that deal with time-based AWS contracts. The Amazon EventBridge Scheduler article added the Source of the Default column, and this article adds the When It Applies column.

Column	What the cell holds
`You Set`	What the user can write, and where (request, configuration, or mapping)
`Allowed Values`	The values the API Reference or the developer guide allows, as of 2026-10-23
`If You Set Nothing`	What happens when the user writes nothing, with the source of that statement
`Source of the Default`	Which source states the value in `If You Set Nothing`
`When It Applies`	When the starting position is read: on every request, only when a lease is created, or only when a mapping or pipe is created
`At the Boundary`	What happens at an edge: a time older than the trim horizon, a time in the future, an existing checkpoint, a change while running
`Where It Shows`	Where the result becomes visible: an exception, the lease table, the mapping or pipe description
`No Statement Found`	What the sources do not state, after a search of the sources in Section 1.3

The first column is labeled Setting. This article puts the combination of stream and consumer in this column.

2.2 How the Source of a Default Is Written

The Source of the Default column holds one of the following five labels.

Label	What it means
`Developer Guide`	Body text or a parameter table in the developer guide or user guide of the service
`KCL configuration table`	The default value column of the KCL configurations page in the Kinesis Data Streams Developer Guide
`Adapter source code`	The Java source of the DynamoDB Streams Kinesis Adapter on GitHub
`Required (no default)`	The source marks the field as required, so there is no behavior for writing nothing
`No statement found`	No source in Section 1.3 states a value

2.3 The Check Date, and What the Documentation Does Not List

The value set of starting positions may change as documentation is updated. Following the changes on October 15, 2026, the DynamoDB Streams API and adapter documentation included AT_TIMESTAMP. As of October 23, 2026, the DynamoDB Streams rows for the Lambda ESM and EventBridge Pipes did not list it yet. This article describes this state as "the documentation does not list it (as of October 23, 2026)," not as "cannot be used." The absence of a value in the value set reflects the state of the documentation, and is not the result of verifying the service's behavior.

This article distinguishes between "the documentation does not list" and "no statement was found." The former refers to the absence of a value in the list. The latter refers to the situation where, despite searching the documentation as described in Section 1.3, the relevant statement could not be found. This article uses the No Statement Found column for the latter.

2.4 Values from the Sources and Values Returned in This Configuration

The tables in Sections 3 through 7 hold only values from the sources. The tables in Section 8 put the values returned in this article's configuration in a column separate from what the sources state. The values in Section 8 are a record of that configuration on that day, not values the sources guarantee.

3. The Starting Position Contract Tables

This section lists the starting position contract for each combination of stream and consumer. The tables are divided into those for DynamoDB Streams and Kinesis Data Streams, and each table is structured into two parts: "What You Write" (representing the user's input) and "What Happens" (representing the resulting actions). The order of rows is consistent between the two tables for the same stream.

3.1 DynamoDB Streams — What You Write

Setting	`You Set`	`Allowed Values`	`If You Set Nothing`	`Source of the Default`
`GetShardIterator` (DynamoDB Streams API)	`ShardIteratorType`, plus `SequenceNumber` or `Timestamp`	`TRIM_HORIZON`, `LATEST`, `AT_SEQUENCE_NUMBER`, `AFTER_SEQUENCE_NUMBER`, `AT_TIMESTAMP`	Required	`Required (no default)`
DynamoDB Streams Kinesis Adapter with KCL	`InitialPositionInStreamExtended` passed to the stream tracker	`LATEST`, `TRIM_HORIZON`, `AT_TIMESTAMP` (adapter 2.5.0 or later)	Required; the stream tracker takes it as a non-null argument	`Adapter source code`
Lambda ESM (DynamoDB Streams)	`StartingPosition` at creation	`TRIM_HORIZON`, `LATEST`; the documentation does not list `AT_TIMESTAMP` for DynamoDB Streams	Required for DynamoDB Streams	`Required (no default)`
EventBridge Pipes (DynamoDB Streams source)	`StartingPosition` in `DynamoDBStreamParameters`	`TRIM_HORIZON`, `LATEST`	Required	`Required (no default)`

3.2 DynamoDB Streams — What Happens

Setting	`When It Applies`	`At the Boundary`	`Where It Shows`	`No Statement Found`
`GetShardIterator` (DynamoDB Streams API)	Every call; the iterator expires 15 minutes after it is returned	A time older than the trim horizon points to `TRIM_HORIZON`; a time in the future returns `ValidationException`; a sequence number older than the trim point might return `TrimmedDataAccessException`	The exception from `GetShardIterator`; `ExpiredIteratorException` from `GetRecords`	How a millisecond `Timestamp` compares with a creation time rounded down to the second
DynamoDB Streams Kinesis Adapter with KCL	Only when a lease is first created; a shard with a checkpoint continues from it	An old time starts at the oldest record in each shard with no error; a future time is rejected before any API call; a change with an existing lease table can mix starting positions across shards	`checkpoint` in the lease table	—
Lambda ESM (DynamoDB Streams)	When the mapping is created; disabling and re-enabling resumes from the same location	`LATEST` could miss events during creation or updates	`StartingPosition` in the mapping description	The starting position after the mapping is deleted and created again
EventBridge Pipes (DynamoDB Streams source)	When the pipe is created; the update type has no `StartingPosition`	`LATEST` could miss events during creation or updates; disabling the source stream leaves the pipe unusable	`SourceParameters` in the pipe description	—

3.3 Kinesis Data Streams — What You Write

Setting	`You Set`	`Allowed Values`	`If You Set Nothing`	`Source of the Default`
`GetShardIterator` (Kinesis Data Streams API)	`ShardIteratorType`, plus `StartingSequenceNumber` or `Timestamp`	`AT_SEQUENCE_NUMBER`, `AFTER_SEQUENCE_NUMBER`, `TRIM_HORIZON`, `LATEST`, `AT_TIMESTAMP`	Required	`Required (no default)`
`SubscribeToShard` (enhanced fan-out)	`StartingPosition` with `Type`, plus `SequenceNumber` or `Timestamp`	`AT_SEQUENCE_NUMBER`, `AFTER_SEQUENCE_NUMBER`, `TRIM_HORIZON`, `LATEST`, `AT_TIMESTAMP`	Required	`Required (no default)`
KCL	`initialPositionInStreamExtended` in `LeaseManagementConfig`	`LATEST`, `TRIM_HORIZON`, `AT_TIMESTAMP`	`TRIM_HORIZON`	`KCL configuration table`
Lambda ESM (Kinesis)	`StartingPosition`, plus `StartingPositionTimestamp` in Unix time seconds	`AT_TIMESTAMP`, `TRIM_HORIZON`, `LATEST`	Required for Kinesis	`Required (no default)`
EventBridge Pipes (Kinesis source)	`StartingPosition`, plus `StartingPositionTimestamp`	`TRIM_HORIZON`, `LATEST`, `AT_TIMESTAMP`	Required	`Required (no default)`
Amazon Data Firehose (Kinesis source)	Nothing; the source configuration has no position field	None	Reads from `LATEST`	`Developer Guide`
Kinesis Data Streams channel (delivery to Amazon S3)	Nothing; `CreateChannel` has no position field	None	No statement found	`No statement found`

3.4 Kinesis Data Streams — What Happens

Setting	`When It Applies`	`At the Boundary`	`Where It Shows`	`No Statement Found`
`GetShardIterator` (Kinesis Data Streams API)	Every call; the iterator expires 5 minutes after it is returned	A time older than the trim horizon returns the oldest untrimmed record (`TRIM_HORIZON`)	`ExpiredIteratorException` from `GetRecords`	What happens with a time in the future
`SubscribeToShard` (enhanced fan-out)	Every call; a subscription lasts up to 5 minutes	A time older than the trim horizon streams from the oldest untrimmed record	The events on the HTTP/2 connection	What happens with a time in the future
KCL	Only when a lease is first created; a shard with a checkpoint continues from it	An existing checkpoint wins over the initial position	`checkpoint` in the lease table	—
Lambda ESM (Kinesis)	When the mapping is created; disabling and re-enabling resumes from the same location	`StartingPositionTimestamp` cannot be in the future; `LATEST` could miss events during creation or updates	`StartingPosition` and `StartingPositionTimestamp` in the mapping description	The starting position after the mapping is deleted and created again
EventBridge Pipes (Kinesis source)	When the pipe is created; the update type has no `StartingPosition`	`LATEST` could miss events during creation or updates	`SourceParameters` in the pipe description	What happens with a time in the future
Amazon Data Firehose (Kinesis source)	When the stream is configured as the source	—	None stated	Where reading continues after an interruption
Kinesis Data Streams channel (delivery to Amazon S3)	No statement found	—	None stated	Where a new channel starts reading

Notes on the tables:

Section 3.1: The Allowed Values of the Lambda ESM come from two parts of the Lambda API reference: the Valid Values line lists three values, and the description of the same field excludes DynamoDB Streams from AT_TIMESTAMP. The developer guide's parameter table lists TRIM_HORIZON or LATEST for DynamoDB Streams. Details are provided in Section 6.1.
For Sections 3.2 and 3.4, the When It Applies entry "when ... is created" for the Lambda ESM and EventBridge Pipes is not a single statement in the sources. It is inferred from the absence of a StartingPosition option in the update API, the CloudFormation classification, and text found in the console's help panel. The rationale is detailed in Sections 6.2 and 6.4.
Regarding Kinesis Data Streams in Section 3.4, searches for a time in the future in the API reference (GetShardIterator, StartingPosition, SubscribeToShard), the developer guide, and the AWS SDK for Ruby reference found no statement. The same holds for the EventBridge Pipes Kinesis source (API reference, user guide, and CloudFormation template reference).
For Kinesis Data Streams in Sections 3.3 and 3.4, searches for mentions of a starting position in the CreateChannel API reference, the AWS CLI reference, the CloudFormation template reference, and the developer guide's pages on data delivery also found no statement. Amazon MSK also has a feature called "Channel," and its documentation states, A Channel does not backfill previously produced data. However, this refers to a feature specific to Amazon MSK.

4. The Stream APIs — Where an Iterator Can Point

This section describes where in a shard the DynamoDB Streams and Kinesis Data Streams APIs can point.

4.1 Five Values

Both GetShardIterator operations accept the same five values for ShardIteratorType. The DynamoDB Streams API reference lists the valid values as follows:

Valid Values: TRIM_HORIZON | LATEST | AT_SEQUENCE_NUMBER | AFTER_SEQUENCE_NUMBER | AT_TIMESTAMP

The Kinesis Data Streams API reference lists the same five values, but in a different order.

Valid Values: AT_SEQUENCE_NUMBER | AFTER_SEQUENCE_NUMBER | TRIM_HORIZON | LATEST | AT_TIMESTAMP

The meaning of these five values is described in nearly identical wording in both references.

Value	What the API Reference says it points to
`TRIM_HORIZON`	The last untrimmed record in the shard, which is the oldest record in the shard
`LATEST`	Just after the most recent record in the shard
`AT_SEQUENCE_NUMBER`	The record with the specified sequence number
`AFTER_SEQUENCE_NUMBER`	Right after the record with the specified sequence number
`AT_TIMESTAMP`	The record at the specified time stamp, or the next (later) record if none has that exact time stamp

In both references, the description for TRIM_HORIZON uses the word last, as the sources do. The subsequent sentence rephrases this as the oldest record in the shard.

The DynamoDB Streams reference adds the following to the description for TRIM_HORIZON: In DynamoDB Streams, there is a 24 hour limit on data retention.

4.2 The Form of the Time

The time values in AT_TIMESTAMP are represented in seconds with millisecond precision across both APIs. The DynamoDB Streams API reference describes Timestamp as A timestamp is the Unix epoch date with precision in milliseconds. and gives the example 1791316726.480. The Kinesis Data Streams API reference, in a similar description, provides two examples: 2016-04-04T19:58:46.480-00:00 and 1459799926.480.

The DynamoDB Streams reference also clarifies the comparison process. The iterator points to the first stream record whose ApproximateCreationDateTime is at or after the specified timestamp. However, the StreamRecord page describes ApproximateCreationDateTime as in UNIX epoch time format and rounded down to the closest second. While the time can be specified with millisecond precision, the time of the compared record is truncated to seconds. No statement was found in the sources in Section 1.3 on whether a record from that second is included when a time in the same second is specified. Section 8 tests this boundary in this article's configuration.

The StartingPositionTimestamp in Lambda's ESM is represented differently. The Lambda API reference states in Unix time seconds. In the adapter's documentation, a Java example passes a Date object created using Instant.ofEpochMilli(1790467200000L). The representation of the time varies depending on the layer to which it is passed.

4.3 A Time Older Than the Retention Period, and an Old Sequence Number

Specifying a time older than the retention period with AT_TIMESTAMP will not result in an error. The DynamoDB Streams API reference states,

If the timestamp is older than the current trim horizon, the iterator points to the oldest untrimmed stream record (TRIM_HORIZON).

The Kinesis Data Streams API reference similarly states,

If the time stamp is older than the current trim horizon, the iterator returned is for the oldest untrimmed data record (TRIM_HORIZON).

The StartingPosition type of SubscribeToShard also states that, for an older time, records are streamed from the oldest record.

Sequence numbers are handled differently. The DynamoDB Streams GetShardIterator documentation, under the section describing TrimmedDataAccessException, lists the scenario You request a shard iterator with a sequence number older than the trim point (24 hours). Another scenario listed is when, after obtaining an iterator, a record is removed after 24 hours but before it is used with GetRecords.

Therefore, in DynamoDB Streams, for the same condition of being older than the retention period, a time moves the iterator to the oldest record, while a sequence number causes an exception. The KCL and the adapter store sequence numbers as checkpoints (see Section 5.2).

The retention period varies depending on the stream. DynamoDB Streams has a 24-hour retention period. The DynamoDB Streams documentation states that data that is older than 24 hours is susceptible to trimming (removal) at any moment. It does not state that records older than 24 hours are deleted exactly after 24 hours. For Kinesis Data Streams, the developer guide states A Kinesis data stream stores records from 24 hours by default, up to 8760 hours (365 days). According to the developer guide, when shortening the retention period,

Kinesis Data Streams almost immediately makes records older than the new retention period inaccessible upon decreasing the retention period.

4.4 A Time in the Future

Of the two stream APIs, only the DynamoDB Streams API reference has a statement on a time in the future: If the timestamp is in the future, the request returns a ValidationException.

No statement on a time in the future was found in the Kinesis Data Streams API references for GetShardIterator, StartingPosition, or SubscribeToShard. The developer guide and the description of GetShardIteratorInput in the AWS SDK for Ruby also lacked any such information. This article does not address whether the Kinesis Data Streams API returns a ValidationException when encountering a future timestamp. While it can be inferred from the DynamoDB Streams documentation, this is not explicitly stated in the Kinesis Data Streams documentation.

4.5 Iterator Lifetime and Retention Period

The starting position is determined when an iterator is obtained. Iterators have a lifetime.

Stream	Iterator lifetime	Retention	What the source says about an expired iterator
DynamoDB Streams	15 minutes after it is returned	24 hours	`ExpiredIteratorException`: `A shard iterator expires 15 minutes after it is retrieved using the GetShardIterator action.`
Kinesis Data Streams	5 minutes after it is returned	24 hours by default, up to 8760 hours (365 days)	`ExpiredIteratorException`: `The provided iterator exceeds the maximum age allowed.`

An expired iterator cannot be used to read again from the same starting position. Calling GetShardIterator again determines the position again, against the retention period at that time. To continue reading, use the NextShardIterator returned by GetRecords. The Kinesis Data Streams API reference states,

A new shard iterator is returned by every GetRecords request in NextShardIterator, which you use in the ShardIterator parameter of the next GetRecords request.

4.6 `SubscribeToShard`

Enhanced fan-out in Kinesis Data Streams passes the starting position in the StartingPosition parameter of SubscribeToShard. This parameter accepts one of five possible values, the same as those used with GetShardIterator.

Valid Values: AT_SEQUENCE_NUMBER | AFTER_SEQUENCE_NUMBER | TRIM_HORIZON | LATEST | AT_TIMESTAMP

Subscriptions are not persistent. The API documentation states that

your consumer starts receiving events of type SubscribeToShardEvent over the HTTP/2 connection for up to 5 minutes, after which time you need to call SubscribeToShard again to renew the subscription if you want to continue to receive records.

The starting position must be provided each time a new subscription is created.

5. KCL and the Adapter — When the Initial Position Is Used

This section explains when the KCL and DynamoDB Streams Kinesis Adapter utilize the initial position, and when they do not.

5.1 Three Values and the Default

The KCL initial position uses three of the five API values. The KCL's InitialPositionInStream has three values: LATEST, TRIM_HORIZON, and AT_TIMESTAMP. The Javadoc in the source describes AT_TIMESTAMP as Start from the record at or after the specified server-side timestamp. The two values that specify a sequence number are not available as options for the KCL's initial position. The KCL itself manages sequence numbers as checkpoints.

The Kinesis Data Streams developer guide lists InitialPositionInStream.TRIM_HORIZON as the default value for initialPositionInStreamExtended in the KCL configuration table. The KCL source code also sets the same value as the default in LeaseManagementConfig.

However, the situation is different when using an adapter. The initial position is passed as an argument to StreamsSchedulerFactory.createSingleStreamTracker. The adapter's source code indicates that this argument cannot be null (annotated with @NonNull). Therefore, when using an adapter, the initial position must always be explicitly specified, and the default value listed in the KCL configuration table does not apply.

5.2 The Initial Position Is Used Only When a Lease Is Created

The KCL configuration table states, This is only used during initial lease creation. The Javadoc for InitialPositionInStream states, This is used during initial application bootstrap (when a checkpoint doesn't exist for a shard or its parents). The Javadoc for InitialPositionInStreamExtended states, If there are checkpoints, we will process records from the checkpoint position.

Checkpoints are stored in the DynamoDB lease table. The KCL concepts page states, Checkpoints are stored in the DynamoDB lease table as part of the metadata of the lease. The lease table page describes the checkpoint field for each row as, The most recent checkpoint sequence number for the shard.

That is, once the KCL application is running, the checkpoint in the lease table, not the initial position in the configuration, determines the application's starting position. The initial position is only used when creating a lease for a shard that does not have a checkpoint.

5.3 `AT_TIMESTAMP` in Adapter 2.5.0

When reading DynamoDB Streams with a KCL, you use the DynamoDB Streams Kinesis Adapter. The DynamoDB developer guide's page on reading from timestamps lists this prerequisite: DynamoDB Streams Kinesis Adapter version 2.5.0 or later. The adapter's CHANGELOG for version 2.5.0 states: Adds support for AT_TIMESTAMP as an initial position.

The same page describes the adapter's behavior as follows: The adapter initializes each new lease with AT_TIMESTAMP as the initial position. For each lease, it calls GetShardIterator with the specified timestamp and then passes that iterator to GetRecords.

Regarding boundary timestamps, the same page describes different scenarios:

Scenario	What the DynamoDB Developer Guide says
The timestamp is older than the retained stream records	`The application starts at the oldest record still available in each shard. It does not return an error.`
The same scenario, about lost records	`You cannot recover records that have gone past the DynamoDB Streams 24-hour retention window.`
The timestamp is in the future	`If the timestamp is in the future, the adapter rejects it without making any API calls, and processing cannot start.`
A timestamp close to the current time	`Allow for clock differences between the application host and the service when choosing a timestamp close to the current time.`

The adapter's source code includes a process that rejects initial positions with future timestamps, throwing an IllegalArgumentException. The exception message ends with: A future timestamp is not allowed; supply a timestamp at or before the current time.

Regarding future timestamps, the DynamoDB Streams API returns a ValidationException, and the adapter rejects the time before calling the API. Even with the same future timestamp, when using the adapter, the application will stop before the API's exception is returned.

5.4 Changing the Initial Position in a Running Application

The same page says not to change the timestamp or the initial position in an application that has a lease table:

Do not change the timestamp or switch between AT_TIMESTAMP, TRIM_HORIZON, and LATEST in a running application which has the state stored in the lease table.

The reason is the following text.

Shards that store sequence numbers as checkpoints in the lease table continue from those checkpoints. Shards that have not started can use the new configuration, or fail if it is incompatible with their existing leases. The application can therefore process different shards from different starting positions.

Therefore, shards with checkpoints read from their previous positions, while shards that have not started yet use the new configuration. Within a single application, shards may begin processing from different starting positions.

To safely apply changes, the same page lists two ways, both of which stop the existing application first:

Delete the lease table and restart the application (recommended): Stop all workers, delete the existing lease table, apply the configuration changes, and then restart the application.
Use a new application name: The adapter creates a new lease table and applies the new timestamp or initial position when the application starts. The page states By default, KCL uses the application name as the name of the lease table unless explicitly overridden. The existing lease table remains available if you need to roll back.

(recommended) is the wording of the source.

5.5 Versions

As of October 23, 2026, the lifecycle table for KCL versions was as follows:

Major version	Current phase	Release date	Maintenance mode date	End-of-support date
KCL 1.x	Maintenance mode	2013-12-19	2025-04-17	2026-01-30
KCL 2.x	General availability	2018-08-02	—	—
KCL 3.x	General availability	2024-11-06	—	—

While the End-of-support date for KCL 1.x is January 30, 2026, the same table lists its current phase as Maintenance mode. This article does not use KCL 1.x as an example.

The adapter page in the DynamoDB developer guide presents information differently. It states,

Amazon Kinesis Client Library (KCL) versions 1.x and 2.x are outdated. KCL 1.x will reach end-of-support on January 30, 2026.

This page describes KCL 2.x as outdated, while the lifecycle table lists KCL 2.x as being in General availability. The sources disagree. The adapter page also states, DynamoDB recommends using KCL version 3.5.x+ with AWS SDK for Java v2.x.

6. Managed Consumers — Lambda Event Source Mappings, EventBridge Pipes, and Amazon Data Firehose

This section reads how far users can write the starting position for consumers whose reader AWS runs: Lambda's event source mappings, EventBridge Pipes, and Amazon Data Firehose.

6.1 The Value Set of the Lambda ESM — Three Sources

Lambda's ESM StartingPosition is described differently across three sources. All were reviewed on October 23, 2026.

The first is Lambda's API reference for CreateEventSourceMapping. The description states:

The position in a stream from which to start reading. Required for Amazon Kinesis and Amazon DynamoDB Stream event sources. AT_TIMESTAMP is supported only for Amazon Kinesis streams, Amazon DocumentDB, Amazon MSK, and self-managed Apache Kafka.

The corresponding "Valid Values" section lists:

Valid Values: TRIM_HORIZON | LATEST | AT_TIMESTAMP

This "Valid Values" section lists three values, and the description explicitly excludes DynamoDB Streams from being a valid option for AT_TIMESTAMP. For StartingPositionTimestamp, the reference states

With StartingPosition set to AT_TIMESTAMP, the time from which to start reading, in Unix time seconds. StartingPositionTimestamp cannot be in the future.

The second source is a table of parameters in Lambda's developer guide. The DynamoDB Streams row lists TRIM_HORIZON or LATEST for StartingPosition. The Kinesis row lists AT_TIMESTAMP, TRIM_HORIZON, or LATEST. The page in Lambda's developer guide dedicated to processing DynamoDB records with Lambda (Process DynamoDB records with Lambda) lists only two options in its configuration list: Latest – Process new records that are added to the stream. and Trim horizon – Process all records in the stream.

The third source is AWS::Lambda::EventSourceMapping in CloudFormation. The description for StartingPosition states, Required for Amazon Kinesis and Amazon DynamoDB., and lists three options: LATEST, TRIM_HORIZON, and AT_TIMESTAMP. There is no note excluding DynamoDB Streams.

The API reference note and the table in the developer guide do not list AT_TIMESTAMP for DynamoDB Streams. This article describes this as "the documentation does not list it (as of October 23, 2026)." This article does not state that AT_TIMESTAMP cannot be used with the DynamoDB Streams ESM. The "What's New" release from October 15, 2026, does not specifically mention Lambda's ESM. In the configuration in Section 8.2, creating an ESM with AT_TIMESTAMP was rejected.

6.2 The Starting Position Is Written at Creation

No explicit statement on how to change the starting position of a Lambda ESM after it is created was found in the sources in Section 1.3. Three sources give clues:

The UpdateEventSourceMapping API reference does not include StartingPosition or StartingPositionTimestamp in the request parameters. These parameters are only present in the response.
In CloudFormation, the AWS::Lambda::EventSourceMapping resource classifies updates to StartingPosition and StartingPositionTimestamp as Update requires: Replacement.
The help panel in the Lambda console states, The Starting position setting determines where Lambda begins processing events when it first connects to your event source.

Taken together, these points suggest that the starting position is set during the initial creation of the ESM, and changing it requires recreating the ESM. However, this is this article's inference. The API shape and the CloudFormation classification show only how an update is made; they do not state where a recreated ESM starts reading. No statement on the starting position after an ESM is recreated was found.

For disabling an ESM and enabling it again, there are explicit statements. The UpdateEventSourceMapping documentation begins with, You can change the function that AWS Lambda invokes, or pause invocation and resume later from the same location. The page dedicated to Lambda's DynamoDB ESM states, about the Enabled setting,

Set to false to stop processing records. Lambda keeps track of the last record processed and resumes processing from that point when the mapping is reenabled.

No statement was found, in the sources in this article's scope, on what happens to records that pass the retention period while the ESM is disabled.

6.3 Missed Events During Creation and Updates

The Lambda developer guide, on both the DynamoDB Streams and Kinesis pages, describes polling during event source mapping creation and updates as follows:

Be aware that stream polling during event source mapping creation and updates is eventually consistent. During event source mapping creation, it may take several minutes to start polling events from the stream. During event source mapping updates, it may take several minutes to stop and restart polling events from the stream.

The text that follows differs between the two pages.

Page	What the page recommends to ensure that no events are missed
Lambda with DynamoDB	`To ensure that no events are missed, specify the stream starting position as TRIM_HORIZON.`
Lambda with Kinesis	`To ensure that no events are missed, specify the stream starting position as TRIM_HORIZON or AT_TIMESTAMP.`

Both pages precede this with the statement

This behavior means that if you specify LATEST as the starting position for the stream, the event source mapping could miss events during creation or updates.

The recommendation on the DynamoDB Streams page has no AT_TIMESTAMP. It has the same shape as the value set in Section 6.1.

The page for Kafka sources states that stopping and restarting during updates can take up to 90 seconds. This refers to Kafka sources specifically, and is distinct from the several minutes mentioned in relation to the streams.

6.4 EventBridge Pipes

The starting position for EventBridge Pipes sources follows the same format as Lambda ESM. Both the API reference for PipeSourceDynamoDBStreamParameters and PipeSourceKinesisStreamParameters require a StartingPosition value (Required: Yes), formatted as follows:

PipeSourceDynamoDBStreamParameters  Valid Values: TRIM_HORIZON | LATEST
PipeSourceKinesisStreamParameters   Valid Values: TRIM_HORIZON | LATEST | AT_TIMESTAMP

Kinesis sources include StartingPositionTimestamp, described as With StartingPosition set to AT_TIMESTAMP, the time from which to start reading, in Unix time seconds. DynamoDB Streams sources do not have a time-related field.

The two update types (UpdatePipeSourceDynamoDBStreamParameters and UpdatePipeSourceKinesisStreamParameters) do not include a StartingPosition field. The source type within CloudFormation's AWS::Pipes::Pipe classifies updates to StartingPosition as Update requires: Replacement. Similar to Section 6.2, this suggests that the starting position is defined during the initial creation of the pipe. This is also this article's inference.

The EventBridge user guide's section on Pipes uses wording similar to Lambda's for polling during creation and updates. The recommendation for not missing events is TRIM_HORIZON or AT_TIMESTAMP for Kinesis sources and TRIM_HORIZON for DynamoDB Streams sources.

The DynamoDB Streams source page has another Important note:

Disabling a DynamoDB stream that is the source of a pipe results in that pipe becoming unusable, even if you then re-enable the stream.

The reason given is that You cannot update a pipe with a new source after creation., and that when you re-enable a stream, it receives a new ARN. The DynamoDB Streams page also states that if you disable and then re-enable a stream, a new stream is created with a different stream descriptor. When you recreate a stream, you need to recreate the consumer itself before you can set the starting position.

6.5 Amazon Data Firehose and Kinesis Data Streams Channels

Amazon Data Firehose, when using Kinesis Data Streams as a source, does not let users choose the starting position. The developer guide states, Amazon Data Firehose starts reading data from the LATEST position of your Kinesis stream. The API reference, specifically the KinesisStreamSourceConfiguration section, only includes KinesisStreamARN and RoleARN. The Amazon Data Firehose FAQ similarly states,

Firehose starts reading data from the LATEST position of your Kinesis Data Stream when it's configured as the source of a Firehose stream.

No statement on where it continues reading after an interruption was found in the developer guide, the API reference, or the FAQ.

Kinesis Data Streams channels deliver stream records to either an Amazon S3 general-purpose bucket or an Apache Iceberg streaming table. The CreateChannel request does not include a starting position parameter. The delivery section of the developer guide states, Read – the delivery reads records from all shards in the Kinesis Data Streams stream., but it does not state where reading starts. No statement was found on whether a new channel delivers records written before it was created.

Amazon MSK also has a feature called "Channel." The Amazon MSK developer guide states, A Channel does not backfill previously produced data — only data produced after enablement is delivered. This description applies to the Amazon MSK feature, but not to the Kinesis Data Streams channel.

7. Value Sets That Shrink by Layer

This section consolidates the value sets from Sections 3 through 6 into a single table. The values are those in the sources as of October 23, 2026.

Starting Positions Each Consumer Accepts

Layer	Consumer	DynamoDB Streams	Kinesis Data Streams
Stream API	`GetShardIterator`	`TRIM_HORIZON`, `LATEST`, `AT_SEQUENCE_NUMBER`, `AFTER_SEQUENCE_NUMBER`, `AT_TIMESTAMP`	`AT_SEQUENCE_NUMBER`, `AFTER_SEQUENCE_NUMBER`, `TRIM_HORIZON`, `LATEST`, `AT_TIMESTAMP`
Stream API	`SubscribeToShard`	Not applicable	`AT_SEQUENCE_NUMBER`, `AFTER_SEQUENCE_NUMBER`, `TRIM_HORIZON`, `LATEST`, `AT_TIMESTAMP`
Client library	KCL (with the adapter for DynamoDB Streams)	`LATEST`, `TRIM_HORIZON`, `AT_TIMESTAMP` (adapter 2.5.0 or later)	`LATEST`, `TRIM_HORIZON`, `AT_TIMESTAMP`
Managed consumer	Lambda ESM	`TRIM_HORIZON`, `LATEST`	`AT_TIMESTAMP`, `TRIM_HORIZON`, `LATEST`
Managed consumer	EventBridge Pipes	`TRIM_HORIZON`, `LATEST`	`TRIM_HORIZON`, `LATEST`, `AT_TIMESTAMP`
Managed consumer	Amazon Data Firehose	Not applicable	`LATEST` only; not settable
Managed consumer	Kinesis Data Streams channel	Not applicable	Not settable; no statement found

The table shows three points.

The two values used to specify the sequence number are only available in the stream API. The KCL keeps sequence numbers as its own checkpoints, and managed consumers do not allow users to write them.
In Kinesis Data Streams, AT_TIMESTAMP is present in every layer except Firehose and the channel. In DynamoDB Streams, it was added to the API and adapter as a result of a change on October 15, 2026.
For DynamoDB Streams, the Lambda ESM and EventBridge Pipes rows have two values in the sources as of the check date. These two rows may change when the sources are revised.

8. What This Configuration Returned

The values presented in this section were obtained on October 23, 2026 (UTC) using the following configuration. They are not values that the sources guarantee. All timestamps are recorded in UTC.

Region: us-east-1. CloudFormation created one on-demand DynamoDB table (its stream uses NEW_IMAGE), one Lambda function that only logs the keys and times of the records it receives, its execution role, and a role for EventBridge Pipes.
Data was written to the table using the same partition key, writing values 1 through 5 for the sort key (sk) approximately every 2 seconds, and then, after a gap of a few seconds, values 6 through 10. The DynamoDB Streams API was called using AWS CLI version 2.38.5. According to the CHANGELOG for AWS CLI v2, the AT_TIMESTAMP feature for dynamodbstreams was added in version 2.38.1.
The Lambda ESM and the EventBridge pipe were created with the AWS CLI commands create-event-source-mapping and create-pipe. The actual account ID, ARNs, stream label, shard IDs, and sequence numbers are masked.

8.1 `GetShardIterator`

The first column lists the attempts made, the second column describes the relevant documentation, and the third column shows the results obtained with this configuration.

What was tried	Documentation	Returned in this configuration
`AT_TIMESTAMP` with a time between `sk` 5 and `sk` 6, in milliseconds	The first record at or after the time	The first record was `sk` 6
`AT_TIMESTAMP` with the `ApproximateCreationDateTime` of `sk` 6, to the second	The first record at or after the time	The first record was `sk` 6
`AT_TIMESTAMP` with the same second plus 0.999 seconds	No statement found	The first record was `sk` 7; `sk` 6 was not returned
`AT_TIMESTAMP` one day before the table was created	Points to `TRIM_HORIZON`	The first record was `sk` 1, the same 10 records as `TRIM_HORIZON`; no error
`AT_TIMESTAMP` 600 seconds in the future	`ValidationException`	`ValidationException`: `One or more parameter values were invalid: Timestamp parameter cannot be greater than the current timestamp`
`AT_TIMESTAMP` 5 seconds in the future	`ValidationException`	The same `ValidationException` and message
`AT_SEQUENCE_NUMBER` and `AFTER_SEQUENCE_NUMBER` with the sequence number of `sk` 3	At, and right after, the record	The first record was `sk` 3, and `sk` 4
`LATEST`, then one `GetRecords`, then a new record `sk` 11	Just after the most recent record	0 records before the write; `sk` 11 after it
`GetRecords` with an iterator taken 18.3 minutes earlier	Expires 15 minutes after it is returned	`ExpiredIteratorException`: `Shard iterator has expired`

The result on the third line shows that when the time was later than the exact second but within the same second (0.999 seconds after it), sk 6, created in that second, was not returned. With the time at the exact second, sk 6 was returned, as the second line shows. This outcome is consistent with the two conditions listed in Section 4.2: the time has millisecond precision, while the record time it is compared with is rounded down to the second. However, this is a single observation, not a statement in the sources.

The older time used in the fourth example was tested on a stream that had been running for less than one hour. The trim horizon was the first record in the stream, and the stream did not contain any records that had already been removed after exceeding a 24-hour retention period. The behavior in scenarios where records have exceeded their retention period was not verified in this configuration.

8.2 The Lambda ESM and EventBridge Pipes

What was tried	Documentation	Returned in this configuration
Lambda ESM on the DynamoDB stream with `StartingPosition` `AT_TIMESTAMP`	The documentation does not list `AT_TIMESTAMP` for DynamoDB Streams	Rejected: `InvalidParameterValueException`: `Unsupported starting position for arn type: <stream ARN>`
EventBridge Pipes with the DynamoDB stream as the source and `StartingPosition` `AT_TIMESTAMP`	The API Reference lists only `TRIM_HORIZON` and `LATEST`	Rejected: `ValidationException`: `[instance value ("AT_TIMESTAMP") not found in enum (possible values: ["TRIM_HORIZON","LATEST"])]`
Lambda ESM on the same stream with `TRIM_HORIZON`	It may take several minutes to start polling	The first batch (`sk` 1 to 10) reached the function about 76 seconds after creation
Disable the ESM; write `sk` 21 to 23 about 1 second after `GetEventSourceMapping` returned `Disabled`	Lambda stops processing records when the mapping is disabled; it may take several minutes to stop polling	The three records reached the function within 1 second of each write
Disable the ESM; write `sk` 31 to 33 about 7 minutes after `Disabled`; wait about 3.7 minutes; enable it again	Lambda resumes processing from the last record processed	Nothing was delivered while disabled; `sk` 31 to 33 arrived in one batch about 64 seconds after enabling; `sk` 1 to 23 were not delivered again

This table records the following three points.

The DynamoDB Streams ESM and EventBridge Pipes rejected creation with AT_TIMESTAMP in this configuration. This result is consistent with the value sets in the sources in Sections 6.1 and 6.4. It is the response of this configuration on October 23, 2026, and this article keeps describing the sources as "the documentation does not list it."
Immediately after disabling the ESM, even after GetEventSourceMapping returned Disabled, new records still reached the function. This is consistent with the statement in Section 6.3 (that stopping and restarting polling during updates may take several minutes). Disabled cannot be read as meaning that polling has stopped.
Records written several minutes after disabling the ESM did not arrive while it was disabled, but arrived only once after it was re-enabled. Older records did not reappear. This is consistent with the statement in Section 6.2 (that it resumes from the same position).

8.3 What This Configuration Did Not Show

This configuration was built using only DynamoDB Streams. It did not test a time in the future for Kinesis Data Streams (Section 4.4), the Kinesis Data Streams ESM and pipe, or the behavior of the KCL and the adapter (Section 5). AT_TIMESTAMP and old sequence numbers after records have been removed past the retention period (Section 4.3) could not be checked on a stream younger than 24 hours. The starting position after an ESM is recreated (Section 6.2) was not tested either.

9. Failure Modes

This section lists common failures that can be read from the statements in the sources in this article, and that are likely to occur in operation.

Assuming that the October 15, 2026 change reached every consumer: "What's New" specifically refers to KCL and the adapter. The DynamoDB Streams rows for the Lambda ESM and EventBridge Pipes do not list AT_TIMESTAMP in the sources as of the check date (Sections 6.1 and 6.4).
Expecting an error for a time older than the retention period: The API and the adapter move it to the oldest record. Because nothing stops with an error, an error does not tell you that some records could not be recovered (Sections 4.3 and 5.3).
Expecting an old sequence number to be moved forward like an old time: In DynamoDB Streams, sequence numbers older than the trim point might result in a TrimmedDataAccessException (Section 4.3).
Expecting the same exception for a time in the future in every layer: The DynamoDB Streams API will return a ValidationException, the adapter will reject the request before calling the API, and Lambda's ESM will indicate cannot be in the future. For the Kinesis Data Streams API, no statement was found (Sections 4.4, 5.3, and 6.1).
Expecting a changed KCL initial position to apply at the next start: The initial position is only used when creating a lease. Shards with checkpoints will continue from the checkpoint (Section 5.2).
Switching the time or the initial position in a running application: The application may read from different positions for each shard. The documentation suggests either deleting the lease table or using a new application name (Section 5.4).
Expecting an expired iterator to read again from the same position: An iterator expires after 15 minutes in DynamoDB Streams and after 5 minutes in Kinesis Data Streams. A new iterator sets the position against the retention period at that time (Section 4.5).
Expecting no missed events when an ESM or a pipe is recreated with LATEST: Polling during creation and updates is "eventually consistent," and the documentation states that events may be missed when using LATEST (Section 6.3).
Expecting no more invocations once an ESM returns Disabled: The documentation indicates that it may take several minutes for the polling to stop after an update. In the configuration described in Section 8.2, a record written immediately after receiving a Disabled response was delivered to the function (Sections 6.3 and 8.2).
Expecting a pipe to keep reading after its DynamoDB stream is disabled and enabled again: When the stream is re-enabled, it will have a new ARN, and the pipe will no longer be usable (Section 6.4).
Reading the Amazon MSK Channel statement as a statement about Kinesis Data Streams channels: The Amazon MSK Channel is a feature of a different product with the same name (Section 6.5).

10. Frequently Asked Questions About Stream Starting Positions

Q1. Can every DynamoDB Streams consumer use AT_TIMESTAMP from October 15, 2026?

According to the sources, two layers can use it: the stream API and the adapter. What's New names the KCL and the adapter, and the adapter documentation lists version 2.5.0 or later as a prerequisite. As of October 23, 2026, the documentation for Lambda ESM and EventBridge Pipes does not list support for DynamoDB Streams' AT_TIMESTAMP feature. This article does not describe this as "cannot be used." However, in the configuration in Section 8.2, creating an ESM and a pipe with AT_TIMESTAMP was rejected for both (see Sections 6.1 and 6.4).

Q2. What happens when AT_TIMESTAMP is given a time older than the retention period?

If you specify a timestamp older than the retention period for AT_TIMESTAMP, no error will occur. Both the DynamoDB Streams and Kinesis Data Streams API references state that reading starts from the oldest record (TRIM_HORIZON). The adapter documentation also states, It does not return an error. It continues to explain that records older than the retention period cannot be retrieved (Sections 4.3 and 5.3).

Q3. What happens when a time in the future is given?

The behavior varies depending on the layer. The DynamoDB Streams API returns a ValidationException. The adapter rejects the request before calling the API, and processing does not begin. The Lambda ESM indicates, StartingPositionTimestamp cannot be in the future. For the Kinesis Data Streams API, no statement on a time in the future was found (see Sections 4.4, 5.3, and 6.1).

Q4. If the KCL initial position is changed and the application restarts, does it read from the new position?

In shards with checkpoints, it will not. The initial position is only used when creating a lease, and shards with checkpoints will continue from the checkpoint. Only shards that have not started will use the new configuration, which can result in different positions for each shard (see Sections 5.2 and 5.4).

Q5. Where does a Lambda ESM read from after it is disabled and enabled again?

It resumes from the same location. The UpdateEventSourceMapping documentation states pause invocation and resume later from the same location, and the DynamoDB ESM documentation states that it resumes from the last processed record. Even with the configuration described in Section 8.2, records written while the ESM was disabled were received after it was re-enabled. No statement was found on what happens to records that pass the retention period while the ESM is disabled (see Section 6.2).

Q6. Can the StartingPosition of a Lambda ESM be changed later?

The UpdateEventSourceMapping request does not include a field for StartingPosition. CloudFormation classifies the update as Replacement. Based on these two points, it can be inferred that the starting position is specified during the initial creation of the ESM and that to change it, the ESM must be recreated. However, this is this article's inference, not one statement in the sources. No statement was found on where the recreated ESM will begin reading from (Section 6.2).

Q7. Where in Kinesis Data Streams does Amazon Data Firehose start reading?

It reads from LATEST. The developer guide states this, and the API reference documentation for setting the source does not include an option to specify a starting position (Section 6.5).

11. Summary

The value set of starting positions shrinks by layer: The stream API has 5, KCL has 3, and managed consumers have 3 or fewer. DynamoDB Streams with Lambda ESM and EventBridge Pipes have 2 (Section 7).
The change on October 15, 2026, reached the API and the adapter: What's New names the KCL and the adapter. The DynamoDB Streams rows for the Lambda ESM and EventBridge Pipes do not list AT_TIMESTAMP yet (Sections 6.1 and 6.4).
Old times are moved forward, while old sequence numbers can cause exceptions: A time is moved to the oldest record without an error. However, DynamoDB Streams sequence numbers might result in a TrimmedDataAccessException (Section 4.3).
Handling of future timestamps varies by layer: There are the API's exception, the adapter's rejection, and the ESM's cannot be in the future. For the Kinesis Data Streams API, no statement was found (Section 4.4).
Checkpoints override the initial position: KCL initial positions are only used when creating a lease. Changing them while the application is running can mix starting positions across shards (Section 5).
The starting position of an ESM or a pipe is written at creation: The update APIs have no field for it. An ESM that is disabled and enabled again resumes from the same location, and an ESM or a pipe created with LATEST may miss events during creation (Section 6).

12. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi