AWS announced time-series support for its next-generation OpenSearch Serverless collections on October 28, 2026. The feature adds a warm tier for less frequently accessed data. For a team planning log searches, one detail deserves attention before choosing a seven-day hot window: what starts the timer?
AWS announcement: next-generation time-series collections
Read the clock behind the setting
AWS’s warm-after documentation says index.warm.after is measured from creation of the underlying storage holding the data. It is not measured from a document’s ingestion time or timestamp value. Documents in the same underlying storage move together, so a document added later can spend less than the configured period in hot storage.
An index can hold both hot and warm data. This setting applies to NextGen time-series collections; Classic, search and vector-search collections do not support it. Confirm the collection type before using this guidance.
AWS documentation: warm-after timing and supported collections
A fictional timeline makes the difference visible
Imagine underlying storage created at day zero and a warm-after period of seven days. An invented log document arrives at day six and is placed in that same storage. For a simplified exercise, suppose the storage becomes eligible to move at day seven. The document has then spent about one day hot: seven minus six.
That arithmetic illustrates the clock’s starting point. It is not a measured AWS transition schedule or a promise about which storage receives a real document. A document’s event date is another separate value; changing the date in this exercise does not restart the storage clock.
Write the search requirement before the number
Instead of writing only “seven days hot,” describe which records a dashboard needs, the age range it searches and the response time its users can accept. Include late-arriving events in the proposed trial. This turns an ambiguous duration into a reader-visible requirement that a team can actually evaluate.
AWS’s launch blog notes that warm searches can have higher latency. A useful trial would compare representative recent-only and mixed-age queries under the same recorded workload. Keep query ranges, observed response times and result checks together. No independent latency or cost test was performed for this article.
AWS launch blog: hot and warm query behavior
Keep retention and later changes separate
Warm tiering and retention answer different questions. For NextGen time-series collections, index.data.retention controls how long data is kept before deletion. Shortening retention also applies to already indexed data and can permanently remove older records. A storage-tier decision should therefore have a separate retention review.
AWS documentation: NextGen retention and deletion behavior
Lengthening warm-after does not bring data already warm back into hot storage, according to AWS’s warm-after guide. Record the current state as well as the proposed setting when reviewing a change.
For the handoff, ask the operator to show the collection type, effective index settings and evidence from the chosen queries. Leave unresolved behavior marked as untested. This is an evaluation worksheet, with a fictional timing example; it is not a tested migration procedure or a recommendation to change production settings.
Which Clock Controls Warm-After?
