Amazon OpenSearch Service Adds Clone-Based Upgrades: Validate Read Requests Only on a Cloned Cluster, Cancel Before Cutover or Roll Back Within a Retention Period You Set; Limited to OpenSearch 1.1 or Later and Elasticsearch 7.10, Five Upgrade Paths, and Both Clusters Are Billed During Validation

On November 10, 2026, AWS announced clone-based upgrades for Amazon OpenSearch Service. The notice says you can now validate a new OpenSearch version alongside your current one and cut over only when you are satisfied. If you find a problem, you can cancel before the cutover or roll back afterward. This report uses that notice and the OpenSearch Service developer guide page on version migration, which describes the steps, limits and charges. It does not cover how fast a clone is built, because neither page gives timings for clone-based upgrades.

The older method is the in-place upgrade. The guide says it upgrades the existing cluster of the domain as a blue/green deployment, and that you cannot pause, cancel or roll back it. It is available for OpenSearch 1.0 or later and Elasticsearch 5.1 or later. The guide says the upgraded cluster takes over as soon as the upgrade completes, even though pre-upgrade checks run first, and that an in-place upgrade can take from 15 minutes to several hours, during which OpenSearch Dashboards might be unavailable. To return to the earlier version after an in-place upgrade, the guide says to restore a snapshot on a new domain.

A clone-based upgrade works differently. OpenSearch Service creates a second cluster, the cloned cluster, on the target version and copies your data to it. The cluster your domain already runs on is the primary cluster, and it keeps serving traffic. The guide lists six steps. First, pre-upgrade checks run, the same ones as for an in-place upgrade, and the process does not continue unless they succeed. Second, a snapshot is taken, and again nothing proceeds unless it succeeds. Third, the cloned cluster is created and your data is copied to it; the domain keeps serving reads and writes from the primary cluster while the clone stays in sync. Fourth, the upgrade waits for you to validate the clone. The notice says you can run the same search queries on both clusters and compare performance with Amazon CloudWatch metrics, and the guide adds that you can optionally send a share of read traffic to the clone. Fifth is the cutover. Sixth is an optional retention period.

Several conditions are easy to miss. Validation covers reads only: the guide says you can validate the cloned cluster with your own read requests, and that is all. During cutover, OpenSearch Service blocks writes until cutover completes, while the clone catches up and traffic moves to it. The guide says the domain endpoint does not change. A rollback is possible only after cutover and only during the retention period you set. That period starts when cutover completes. If you set no retention period, the guide says OpenSearch Service deletes the primary cluster immediately after cutover, which leaves nothing to roll back to. Canceling before cutover deletes the cloned cluster and leaves the domain as it was.

The eligibility rules are narrow. The notice says clone-based upgrades are available for domains running OpenSearch 1.1 or later or Elasticsearch 7.10, in AWS Commercial Regions where the service is offered, except Asia Pacific (New Zealand), Asia Pacific (Taipei), Asia Pacific (Thailand) and Mexico (Central). The guide lists five supported paths: Elasticsearch 7.10 to OpenSearch 1.3, OpenSearch 1.1 to 1.3, OpenSearch 1.3 to 2.19, OpenSearch 2.x to 2.19, and OpenSearch 2.19 to 3.x. For other paths, the guide says to use an in-place upgrade. It also lists domains that are not supported: those using OpenSearch Optimized instances (OR1 or OR2), UltraWarm instances or cross-cluster replication, those with custom or third-party plugin packages associated, and those using SAML or Amazon Cognito authentication for OpenSearch Dashboards. You also cannot change the domain's configuration during the upgrade.

The cost rule is stated plainly. An in-place upgrade does not incur additional charges. For a clone-based upgrade, standard pricing applies to the clone's instances and storage, like any other nodes. You are charged for both the primary cluster and the clone while you validate, and if you keep the primary cluster for rollback, you pay for both until the retention period ends. The notice and guide give no dollar amounts. A longer validation or retention period therefore lengthens the time you pay for two clusters; the extra amount depends on your own instance and storage choices and on standard prices.

Before any upgrade, the guide asks for three things: take a manual snapshot, which can be restored on a new domain if you want the earlier version back; check the supported upgrade paths; and run the pre-upgrade check. It also warns that if you stream data into OpenSearch Service with services such as Amazon Data Firehose or Amazon CloudWatch Logs, you should check that those services support the newer version before migrating. The troubleshooting table lists conditions that block an upgrade, such as more than 1,000 shards on a node, disk usage above 90%, JVM memory pressure above 75% and a red cluster status. These checks apply to both upgrade types.

What is not in these two pages matters for planning. They give no measurement of how long a clone takes to build or catch up, no statement of how long writes are blocked during cutover, and no evidence about how closely clone performance predicts production performance. The guide says validation covers reads only, so this validation step cannot directly test write behavior. What follows is our judgment, not an AWS statement. A write-heavy team should plan separate non-production write tests and a cutover rehearsal. Any team that wants this safety net should also measure cutover duration on a non-production domain, decide in advance how long to keep the primary cluster, and budget for two clusters during that period.