Making configuration changes in Amazon OpenSearch Service - Amazon OpenSearch Service (successor to Amazon Elasticsearch Service)
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China.

Making configuration changes in Amazon OpenSearch Service

Amazon OpenSearch Service uses a blue/green deployment process when updating domains. Blue/green typically refers to the practice of running two production environments, one live and one idle, and switching the two as you make software changes. In the case of OpenSearch Service, it refers to the practice of creating a new environment for domain updates and routing users to the new environment after those updates are complete. The practice minimizes downtime and maintains the original environment in the event that deployment to the new environment is unsuccessful.

Changes that usually cause blue/green deployments

The following operations cause blue/green deployments:

  • Changing instance type

  • Performing service software updates

  • If your domain doesn't have dedicated master nodes, changing data instance count

  • Enabling or disabling dedicated master nodes

  • Changing dedicated master node count or instance type

  • Enabling or disabling Multi-AZ

  • Changing storage type, volume type, or volume size

  • Choosing different VPC subnets

  • Adding or removing VPC security groups

  • Enabling or disabling Amazon Cognito authentication for OpenSearch Dashboards

  • Choosing a different Amazon Cognito user pool or identity pool

  • Modifying advanced settings

  • Enabling or disabling the publication of error logs, audit logs, or slow logs to CloudWatch

  • Upgrading to a new OpenSearch version

  • Enabling or disabling Require HTTPS

  • Enabling encryption of data at rest or node-to-node encryption

  • Enabling or disabling UltraWarm or cold storage

  • Disabling auto-tune and rolling back its changes

Changes that usually don't cause blue/green deployments

In most cases, the following operations do not cause blue/green deployments:

  • Changing access policy

  • Changing the automated snapshot hour

  • Enabling auto-tune or disabling it without rolling back its changes

  • If your domain has dedicated master nodes, changing data node or UltraWarm node count

There are some exceptions depending on your service software version. If you want to be absolutely sure that a change will not cause a blue/green deployment, perform a dry run before updating your domain.

Determine whether a change will cause a blue/green deployment

You can conduct a dry run of a planned configuration change to determine whether it will cause a blue/green deployment. When making a change in the console, you're prompted to choose Run Analysis, and OpenSearch Service calculates the type of deployment the change will cause.

You can also perform a dry run analysis through the configuration API. For example, this UpdateDomainConfig request tests the deployment type caused by enabling UltraWarm:

POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/my-domain/config { "ClusterConfig": { "WarmCount": 3, "WarmEnabled": true, "WarmType": "ultrawarm1.large.search" }, "DryRun": true }

The request returns the type of deployment the change will cause but doesn't actually perform the update.

Response

{ "ClusterConfig": { ... }, "DryRunResults": { "DeploymentType": "Blue/Green", "Message": "This change will require a blue/green deployment." } }

Possible deployment types are:

  • Blue/Green - The change will cause a blue/green deployment.

  • DynamicUpdate - The change won't cause a blue/green deployment.

  • Undetermined - The domain is still in a processing state, so the deployment type can't be determined.

  • None - No configuration change.

Initiating a configuration change

When you initiate a configuration change, the domain state changes to Processing until OpenSearch Service has created a new environment with the latest service software, at which point it changes back to Active. During certain service software updates, the state remains Active the whole time. In both cases, you can review the cluster health and Amazon CloudWatch metrics and see that the number of nodes in the cluster temporarily increases—often doubling—while the domain update occurs. In the following illustration, you can see the number of nodes doubling from 11 to 22 during a configuration change and returning to 11 when the update is complete.


      Number of nodes doubling from 11 to 22 during a domain configuration
        change.

This temporary increase can strain the cluster's dedicated master nodes, which suddenly might have many more nodes to manage. It can also increase search and indexing latencies as OpenSearch Service copies data from the old cluster to the new one. It's important to maintain sufficient capacity on the cluster to handle the overhead that is associated with these blue/green deployments.

Important

You do not incur any additional charges during configuration changes and service maintenance. You're billed only for the number of nodes that you request for your cluster. For specifics, see Charges for configuration changes.

To prevent overloading dedicated master nodes, you can monitor usage with the Amazon CloudWatch metrics. For recommended maximum values, see Recommended CloudWatch alarms for Amazon OpenSearch Service.

Charges for configuration changes

If you change the configuration for a domain, OpenSearch Service creates a new cluster as described in Making configuration changes in Amazon OpenSearch Service. During the migration of old to new, you incur the following charges:

  • If you change the instance type, you're charged for both clusters for the first hour. After the first hour, you're only charged for the new cluster. EBS volumes aren't charged twice because they're part of your cluster, so their billing follows instance billing.

    Example: You change the configuration from three m3.xlarge instances to four m4.large instances. For the first hour, you're charged for both clusters (3 * m3.xlarge + 4 * m4.large). After the first hour, you're charged only for the new cluster (4 * m4.large).

  • If you don't change the instance type, you're charged only for the largest cluster for the first hour. After the first hour, you're charged only for the new cluster.

    Example: You change the configuration from six m3.xlarge instances to three m3.xlarge instances. For the first hour, you're charged for the largest cluster (6 * m3.xlarge). After the first hour, you're charged only for the new cluster (3 * m3.xlarge).