OpenSearch clone-based upgrades: validation, rollback and costs

Check the five clone-upgrade paths and Region availability

On November 10, 2026, AWS announced that Amazon OpenSearch Service can create a clone on the target version, copy and synchronize production data to it, and let you validate it before cutover. A domain here means the managed OpenSearch Service cluster environment, not a website DNS name.

The current Developer Guide lists five clone-based paths: Elasticsearch 7.10 → OpenSearch 1.3; OpenSearch 1.1 → 1.3; OpenSearch 1.3 → 2.19; OpenSearch 2.x → 2.19; and OpenSearch 2.19 → 3.x. Use an in-place upgrade for other paths. Availability for OpenSearch 1.1 or later does not let you skip these supported paths.

The feature is available in AWS Commercial Regions offering OpenSearch Service, except Asia Pacific (New Zealand), Asia Pacific (Taipei), Asia Pacific (Thailand), and Mexico (Central). This article has not checked the options in a private account. Confirm the Region, current version and target version before planning an upgrade.

These domain configurations are not supported

Check whether the domain uses OpenSearch Optimized OR1 or OR2 instances, UltraWarm instances, cross-cluster replication, or associated custom or third-party plugin packages. The current guide excludes each of these configurations.

Domains using SAML or Amazon Cognito authentication for OpenSearch Dashboards are also unsupported. You cannot change the domain configuration during the upgrade, so do not plan to start the clone and then change configuration to resolve a limitation.

Take a snapshot, run prechecks, then validate real read requests

First, take a manual domain snapshot as a backup that can be restored on a new domain if you need the earlier version. Check the version path and application integrations too. If Amazon Data Firehose or CloudWatch Logs sends data to the domain, confirm that those services support the target version.

Second, run the pre-upgrade check and address any blockers it returns. The actual clone-upgrade workflow also runs checks and takes a snapshot before creating and synchronizing the target-version clone. The primary cluster continues serving reads and writes during this process.

Third, once the clone is ready, validate it with your own read requests and optionally send it a share of read traffic. You can run the same queries against both clusters and compare results and CloudWatch metrics. Clone validation supports reads only; it does not establish that application writes or a complete business workflow have been tested.

You can cancel before cutover; writes pause during cutover

After validation, decide when to cut over: move domain traffic from the primary cluster to the clone. OpenSearch Service blocks writes while the clone catches up, then moves traffic to it. The domain endpoint stays the same. Plan for the write pause and review application retries and recovery; an unchanged endpoint does not mean uninterrupted writes.

Writes remain blocked until cutover completes. The sources reviewed do not give a cutover-duration guarantee that applies to every domain. Before cutover, you can cancel the upgrade; the service deletes the clone and leaves the domain as it was.

Set post-cutover retention if you need a rollback window

A clone-based upgrade lets you return to the primary cluster after cutover only during the retention period you set. This window starts when cutover completes, not when clone creation or validation begins.

If you do not set a retention period, OpenSearch Service deletes the primary cluster immediately after cutover. Rollback support does not mean the old version is always retained by default. Decide on the window in advance and check the current official operating instructions for available durations and rollback steps. This article has not verified a numeric retention limit or performed a rollback.

An in-place upgrade cannot be paused, canceled or rolled back. Returning to the earlier version after an in-place upgrade requires restoring a snapshot on a new domain. Do not apply the clone-upgrade rollback window to an in-place upgrade.

Budget for both clusters during validation and retention

The current guide explicitly applies standard instance and storage pricing to the clone. Both the primary and clone are billed while you validate. If you keep the primary for rollback, you are charged for both until the retention period ends.

Include instance and storage costs at the actual Region prices when planning validation and retention. This article has not checked an account bill or quote, so it cannot give a universal amount or describe clone-based upgrades as free. The guide’s statement that there are no additional upgrade charges applies to in-place upgrades, not clone resources.