In-place configuration changes. In-place changes for existing deployments substantially speed up configuration changes and are now the default for most operations that involve settings changes, upgrades, and deployment resizing. The benefits include:

The speed and reliability of in-place configuration changes comes from applying the changes to the existing instances of your deployment, such as the Elasticsearch nodes and Kibana instances, followed by a rolling restart. There is no downtime for highly available deployments with two or more availability zones, provided that deployments are sized to support their workloads.

Elasticsearch Service previously used only a grow-and-shrink approach for deployment changes. This approach adds new instances, migrates data from old instances to the new ones, and then shrinks the deployment by removing the old instances. Grow-and-shrink provides high availability during configuration changes even for single availability zones. The tradeoff is that changes frequently require replacing some or all of the deployment, triggering a potentially long-running data migration process for larger deployments.

When you change your deployment configuration, Elasticsearch Service will choose the right approach to apply the changes, using either the preferred in-place approach where possible or falling back to grow-and-shrink when necessary. Deployment changes that will continue to require a grow-and-shrink approach include:

When applying changes to non-highly available deployments, the Elasticsearch Service Console now warns you that your deployment may suffer a temporary loss of availability. If loss of availability is not acceptable, make sure to use at least two availability zones, even if only temporarily. Keep in mind that production systems should never use only one availability zone.

The grow-and-shrink approach may still be used in some other scenarios, for example when the host that your deployment runs on has insufficient capacity to scale up an Elasticsearch cluster and needs to use capacity on another host.

New deployment templates to support AWS M5d and R5d hardware. AWS provides memory- and CPU-optimised machines with attached NVMe storage instead of GP2 which offers more performant hardware with better disk performance. In order to support the new hardware, you can now make use of updated AWS deployment templates. The new templates still use the same naming convention and replace components using R4 with R5d, and M5 with M5d.

Social signup with Google. New users can now use social signup with Google, eliminating the need to verify email addresses or manage passwords when signing up for Elasticsearch Service.

Elasticsearch clusters provisioned prior to January 25th, 2019 have a CORS policy set at the proxy layer. This policy is now deprecated and we will be moving to a model that requires you to configure your own http module CORS policy. The http.cors.* settings are configurable as Elasticsearch user settings for all of your deployments.

The in-place configuration change improvements included in this release mean that single availability zone deployments will be temporarily unavailable while the change is applied. If availability is a concern, you should use two availability zones for your deployment, which requires no downtime and which ensures deployment availability during future configuration changes, upgrades, and hardware failures.