OpenSearch Support Options: Project, AWS or Independent

OpenSearch has no vendor in the usual sense. Support for OpenSearch comes from the OpenSearch project community for maintained versions, from Amazon Web Services for Amazon OpenSearch Service, and from independent providers for self-managed OpenSearch clusters, including OpenSearch 1.x, which is now end of life.

Where OpenSearch came from, and why it matters for support

OpenSearch is an open source search and analytics suite that began in 2021 as a fork of Elasticsearch and Kibana 7.10, created after Elastic moved those products away from the Apache License to the Elastic License and SSPL. OpenSearch and OpenSearch Dashboards remain under the Apache License 2.0. In 2024 AWS transferred the project to the OpenSearch Software Foundation, part of the Linux Foundation, so the OpenSearch project is now governed like other open source projects of its size rather than owned by one company.

The consequence for support is simple. Elastic does not support OpenSearch. The foundation does not sell support. Nobody is contractually behind the open source software unless you arrange it.

What the OpenSearch project maintains

The project's release and maintenance policy aims for a new minor version roughly every eight weeks. A major version stays under maintenance until the next major version enters maintenance or one year passes, whichever is longer. At the time of writing OpenSearch 3.x is the current line, OpenSearch 2.x is in maintenance and will keep receiving bug fixes and security patches until OpenSearch 4.0 is released, and OpenSearch 1.x reached end of life after 6 May 2025.

Maintenance means patches in new versions of OpenSearch. It does not mean anyone answers when your OpenSearch cluster goes red. Community help is the forum, Slack and GitHub.

Amazon OpenSearch Service

Amazon OpenSearch Service, the successor to Amazon Elasticsearch Service, is the managed option. AWS runs the OpenSearch Service domain, handles patching, snapshots and node replacement, and supports the service through your AWS Support plan. It also still hosts older versions of Elasticsearch, on its own support schedule for each engine version, which is separate from the project's.

What AWS support does not take on is the part that causes most incidents: index and shard design, mappings, query performance, ingestion pipelines, access control configuration and cost. A domain can be perfectly healthy from the AWS side and unusable from yours.

Where independent OpenSearch support fits

• Self-managed OpenSearch on Linux, virtual machines or Kubernetes, with no vendor to call.
• OpenSearch 1.x past end of life, and clusters still on open source Elasticsearch 7.10 that are deciding between OpenSearch and Elasticsearch.
• Cluster operations: red and yellow cluster state, unassigned shards, JVM heap pressure, oversharding, snapshot and restore that was never tested, slow log analytics dashboards in OpenSearch Dashboards.
• Migrations: Elasticsearch to OpenSearch, version upgrades, and moves between self-managed clusters and Amazon OpenSearch Service. The two code bases have diverged since the fork, so client libraries, plugins and some query and index features need checking.
• Newer use cases such as vector search and retrieval augmented generation, observability and anomaly detection, where sizing mistakes are expensive.

AceMQ provides 24/7 OpenSearch support for self-managed clusters and Amazon OpenSearch Service, with a 15-minute emergency SLA and named senior engineers, and supports Elasticsearch estates on the same terms. Examples: a snapshot and restore remediation and an OpenSearch migration assessment.

The OpenSearch incidents that actually page people

• Unassigned shards after a node loss. Disk watermarks, zone awareness and replica settings decide whether the cluster can heal. On Amazon OpenSearch Service you cannot log in to a node, so diagnosis is through the allocation explain API and CloudWatch, and the remedy is often a configuration change that triggers a blue/green deployment.
• Blue/green deployments that never finish. On the managed service a configuration change builds a new set of nodes and migrates shards. With too many shards, too little free storage or a red index, it stalls for hours while the domain runs degraded and costs double.
• JVM memory pressure. The same causes as Elasticsearch: too many shards per node, heavy aggregations, and instance types chosen for price. On the managed service, the only levers are instance size, shard count and query design.
• Security plugin lockouts. Fine-grained access control, role mappings and SAML or Cognito integration are powerful and easy to misconfigure. A bad change can lock every user out of OpenSearch Dashboards at once.
• Snapshot and restore. Automated snapshots on the managed service cannot be restored to another domain the way manual snapshots can. Teams discover the difference during a migration or a recovery.

Moving between versions, and between Elasticsearch and OpenSearch

OpenSearch 1.x is wire-compatible with Elasticsearch 7.10, which is what made early migrations simple. The code bases have diverged since, so a move today needs checking at three levels: index compatibility, which may require reindexing; client libraries, because Elasticsearch clients from 7.14 onwards reject non-Elastic servers and the OpenSearch clients must be used instead; and features, since machine learning, alerting and security are implemented differently on each side. From OpenSearch 1.x, which is end of life, the route is an upgrade to the last 1.3 release, then to 2.x, reindexing any index that was originally created on Elasticsearch 6.x. Rolling upgrades work for self-managed clusters. On the managed service an upgrade is a button, and a rehearsal on a restored snapshot is still the only way to know how long it takes.

Choosing

On Amazon OpenSearch Service, AWS support covers the platform and you need help with everything you put on it. Self-managed, the project gives you patches and no response time. If search or log analytics is in the path of revenue or incident response, that gap is worth closing before the cluster closes it for you.