OpenSearch Domain

On this page

• Coverage by target cloud
• How the backends compare
  • Infrastructure-only adaptation
• On Google Cloud, Azure, and Private Kubernetes
  • Via OpenSearch
• On Google Cloud
  • Via Elastic Cloud (managed)
• On Azure
  • Via Azure Native Elastic
• On OCI
• Debug this service

​

Coverage by target cloud

​

How the backends compare

Each row compares a capability of OpenSearch Domain with its adaptation on each backend. A dash means this row is not stated for that backend.

​

Infrastructure-only adaptation

​

On Google Cloud, Azure, and Private Kubernetes

​

Via OpenSearch

​

How it works

Tensor9 provisions OpenSearch in your Kubernetes cluster, through an OpenSearchCluster resource or a Helm chart, and points your application at its endpoint. Your OpenSearch client sends document and search requests straight to the cluster’s OpenSearch API; nothing from Tensor9 sits in between. You operate the cluster and its storage.

​

Engine and plugins

The cluster runs the OpenSearch engine with its bundled plugins, so the listed document, index, search, aggregation, ingest and scripting operations keep their OpenSearch APIs. The distribution includes k-NN vector search, SQL, PPL, Index State Management, Alerting, Anomaly Detection and ML Commons, and their _plugins APIs run on the cluster. Match the engine and plugin versions to the ones your application uses on AWS. Two deployments of the same engine are not identical if their versions differ.

​

Topology and access

You define node pools with CPU, memory and PersistentVolume capacity. A dedicated cluster_manager pool keeps the cluster quorum: use at least three eligible nodes and spread replicas across failure domains. (OpenSearch renamed the master role to cluster_manager in version 2.0.) Configure shard allocation and plan rolling upgrades for your version. The OpenSearch Security plugin controls roles, role mappings and internal users, including SAML, OIDC or LDAP sign-in where supported, and document- or field-level access. You translate your AWS IAM-based access rules into this configuration.

​

Storage and backups

PersistentVolumes and their StorageClasses set disk capacity, IOPS and encryption. Availability depends on node placement, quorum and index replicas. Register a snapshot repository, and schedule snapshots and their retention with OpenSearch Snapshot Management (not the same feature as Elasticsearch Snapshot Lifecycle Management). An S3-compatible repository needs the repository-s3 plugin and the object store’s endpoint settings. Keep backups outside the cluster’s failure domain, and test a restore.

​

Limitations

• A managed uptime SLA is not available. The cluster is self-managed. Tensor9 provisions it and its endpoint, but adds no managed durability guarantee; availability is what your placement, quorum and replicas provide.
• AWS IAM access control is not supported. You must express access rules in the OpenSearch Security plugin’s roles, role mappings and users.
• Encryption behaves differently: AWS KMS key settings are not kept. Encryption at rest comes from the StorageClass of the PersistentVolumes, not from a domain’s AWS KMS key.
• Elasticsearch licensing APIs are not supported. _license and _xpack are Elasticsearch endpoints, not OpenSearch APIs.

​

Other considerations

Before going live. Replace the bootstrap certificates and default credentials before you expose the cluster. Moving from AWS. The cluster starts empty. Restore a compatible snapshot or reindex from the source, then check index mappings and queries before cutover. Size shards, replicas and storage for your workload; shard sizes in the tens of gigabytes are a starting point to evaluate, not a fixed limit. What you operate. You run Kubernetes capacity, storage expansion, cluster health, upgrades and snapshots.

​

On Google Cloud

​

Via Elastic Cloud (managed)

​

How it works

Your application keeps its OpenSearch client. Its requests go to a Tensor9 adapter, which translates the supported APIs and authentication and sends them to an Elastic Cloud Hosted deployment running Elasticsearch 8.x. Tensor9 provisions the deployment as an ec_deployment resource in your Google Cloud environment. Elastic operates Elasticsearch and Kibana; you choose the deployment configuration.

​

Requests and authentication

The adapter forwards the supported document, search, aggregation, index, cluster, ingest and scripting operations, translating request and response differences. For example, the point-in-time path _search/point_in_time becomes _pit. The adapter checks AWS SigV4 signatures; its requests to Elasticsearch use Elastic credentials or API keys. You configure backend permissions in Elastic’s security model. Elasticsearch 8.x accepts compatible-with=7 headers for its earlier REST API, and the adapter uses them where they apply. This does not make every OpenSearch request or client version compatible. Check your queries, response parsing and client behavior against the listed operations. See Elastic’s API compatibility documentation.

​

Plugin features

OpenSearch and Elasticsearch have different plugin APIs, so the adapter translates them: - k-NN. knn_vector mappings become dense_vector, and queries become Elasticsearch’s knn form. - SQL. Requests to _plugins/_sql go to _sql, with response fields translated. - Index State Management. Policies map to Elasticsearch Index Lifecycle Management (ILM) where their actions fit. - Alerting, anomaly detection and machine learning. These map to Elasticsearch _watcher and _ml. Some of them need a commercial Elastic subscription.

​

Deployment, availability and security

The ec_deployment resource exposes hot, warm, cold and frozen tiers, instance size, one to three availability zones, and autoscaling per tier. Storage comes bundled at the selected tier’s disk-to-memory ratio. Elastic Cloud publishes monthly availability commitments of 99.5%, 99.9% and 99.95% for one-, two- and three-zone deployments, subject to the subscription and its high-availability conditions. Choose topology and subscription together. Access control uses Elastic’s security configuration, API keys and single sign-on, not OpenSearch Security roles. Document- and field-level security and other commercial features depend on the subscription you buy. The hosted offering’s subscription terms apply regardless of the source-code license. Elastic added an AGPLv3 option for the free source portions in 2024; see its licensing FAQ.

​

Limitations

• Some OpenSearch APIs are not supported. PPL, the OpenSearch Security API, notifications and observability objects are outside the mapping. They need Elastic-native configuration or a change in your application.
• Index State Management behaves differently: custom states are not kept. ILM has fixed phases, so custom ISM states and transitions cannot be represented and do not round-trip.
• Restoring OpenSearch snapshots is not a supported migration path. Do not assume an OpenSearch snapshot restores into Elasticsearch across the engine fork. Move data with a reindex or bulk import instead.
• Elasticsearch licensing APIs are not supported. _license and _xpack are not OpenSearch APIs and are not part of the mapping.

​

Other considerations

Moving from AWS. The deployment starts empty. Move data with a compatible remote reindex or a bulk export and import. Review mappings, analyzers and index settings before loading data, and test representative queries before you switch traffic. Backups. Elastic Snapshot Lifecycle Management sets backup schedules and retention. Make sure it meets the recovery requirements you had with AWS-managed snapshots. Sizing. Choose shard layout, replicas, data tiers and memory for your indexing and query load. Published engine benchmarks describe their own versions and datasets, not this mapping. Measure your deployed application, including translated operations, when choosing capacity.

​

On Azure

​

Via Azure Native Elastic

​

How it works

Your application keeps its OpenSearch client. Its requests go to a Tensor9 adapter, which translates the supported APIs and authentication and sends them to a managed Elasticsearch 8.x endpoint on Azure Native Elastic. Tensor9 creates the Elastic resource in the customer’s Azure tenant through the Azure Native integration. Elastic operates Elasticsearch, and the resource is bought and billed through the customer’s Azure subscription.

​

Requests and authentication

The adapter forwards the supported document, search, aggregation, index, cluster, ingest and scripting operations. It translates differences in requests and responses, such as the point-in-time path: _search/point_in_time becomes _pit. The adapter checks the AWS SigV4 signature on each request, then calls Elasticsearch with Elastic credentials or API keys. You configure backend permissions in Elastic’s security model. Elasticsearch 8.x accepts compatible-with=7 headers for its earlier REST API. The adapter uses them where they apply, alongside its own translations. This does not make every OpenSearch request or client version work. Test your application’s queries, response parsing and client behavior against the listed operations. See Elastic’s API compatibility documentation.

​

Plugin APIs

OpenSearch and Elasticsearch have different plugin APIs. The adapter maps k-NN vector fields from knn_vector to dense_vector and converts the query to Elasticsearch’s knn form. SQL requests move from _plugins/_sql to _sql, with the response fields translated. Index State Management (ISM) policies map to Elasticsearch Index Lifecycle Management (ILM) where their actions fit ILM’s phases. Alerting, anomaly detection and machine learning map to Elasticsearch’s _watcher and _ml features. Some of these need a commercial Elastic subscription. The operations table shows which APIs are translated and which are not supported.

​

Deployment, security and availability

The Azure resource does not expose the deployment’s topology. You set size and topology in the Elastic Cloud console. The documented default is 16 GB RAM, 560 GB storage and two availability zones, with instances up to 256 GB RAM. Elastic Cloud publishes monthly availability commitments of 99.5%, 99.9% and 99.95% for one-, two- and three-zone deployments, subject to the subscription and its high-availability conditions. The subscription also decides which commercial features you get, so choose topology and subscription together. Security uses Elastic’s own configuration, API keys and single sign-on, not OpenSearch Security roles. Document- and field-level security and other commercial features depend on the subscription you buy. The hosted offering’s subscription terms apply whatever the source-code license. Elastic added an AGPLv3 option for the free source portions in 2024; see its licensing FAQ.

​

Limitations

• PPL is not supported. Elasticsearch has no PPL, and the adapter does not translate PPL requests. Replace them with an application change. - The OpenSearch Security API is not supported. OpenSearch Security configuration is not translated. Configure users, roles and permissions in Elastic’s security model instead. - Notifications and observability objects are not supported. They have no Elasticsearch equivalent. They need backend-native configuration or an application change. - ISM behaves differently: custom states and transitions are not mapped. ILM has fixed phases, so only ISM actions that fit those phases are mapped. - Snapshots behave differently: an OpenSearch snapshot does not restore into Elasticsearch. Backup schedules and retention use Elastic Snapshot Lifecycle Management, which has a different API from OpenSearch snapshots. - Some features need a commercial Elastic subscription. Parts of alerting, anomaly detection and machine learning, and document- and field-level security, depend on the subscription you buy. - The _license and _xpack endpoints are not supported. They are Elasticsearch licensing APIs, not OpenSearch APIs, and are outside the mapping.

​

Other considerations

Before going live. Review mappings, analyzers and index settings before loading data. Check representative queries, including translated operations, before switching traffic. Moving from AWS. The deployment starts empty. Move data with a compatible remote reindex or a bulk export and import. Replace AWS-managed snapshots with Elastic Snapshot Lifecycle Management schedules and retention that meet your recovery requirements. Sizing. Choose shard layout, replicas, data tiers and memory for your indexing and query load. Published engine benchmarks describe their own versions and datasets; they do not measure this mapping. Measure your deployed application, including translated operations, when choosing capacity.

​

On OCI

​

How it works

Your application keeps its OpenSearch client and requests. Tensor9 provisions OCI Search with OpenSearch in the customer’s Oracle Cloud tenancy and points the application at the cluster’s opensearch_fqdn endpoint. Document and search requests go straight to the managed cluster; Tensor9 is not in the request path. Oracle operates the OpenSearch service.

​

Engine and plugins

OCI runs OpenSearch itself, not a fork. The listed core REST operations and the supported plugins use the native OpenSearch APIs, including k-NN, SQL/PPL, Index State Management, Alerting, Anomaly Detection, ML Commons, Neural Search and Security Analytics. OCI documents versions 2.11, 2.15, 2.18, 2.19.1, 3.2 and 3.6. Match the engine and plugin versions to your application before migrating. The same engine on another provider still needs a version-compatibility review; it does not guarantee identical behaviour for every request.

​

Topology and security

You size the data, leader and OpenSearch Dashboards nodes, with optional coordinator, machine-learning and search tiers. The cluster runs in the customer’s VCN and subnet. Oracle manages the software and spreads data nodes across availability domains. Access control uses the OpenSearch Security plugin, with security_mode set to ENFORCING and a master user. It supports SAML, LDAP and OIDC sign-in, and document- and field-level security on supported versions.

​

Limitations

Where Amazon OpenSearch Service and OCI differ

• AWS IAM access policies are not supported. Domain access_policies do not apply directly. On OCI, access control goes through the Security plugin described above.
• Customer-managed encryption keys are not supported. OCI manages storage encryption, and this mapping has no per-domain AWS KMS key setting.
• Elasticsearch _license and _xpack endpoints are not supported. They are not part of OpenSearch.
• Backups behave differently: OCI keeps daily backups for 14 days. You cannot change that schedule or retention. For other recovery points, use the Snapshot API with an Object Storage repository in the customer tenancy.
• Availability behaves differently: OCI states a 99.9% objective, not a contractual SLA. Node placement and replicas provide high availability. Check the current OCI service terms for the customer deployment.
• AWS sizing settings are not kept. The service uses Oracle compute and storage shapes, with the limits listed in the comparison. AWS instance families, EBS limits and UltraWarm settings are not interchangeable with them.

​

Other considerations

Before going live. Set up your recovery destinations and test a restore. Measure your workload on the chosen topology, and keep enough storage and replica capacity. Moving from AWS. The new cluster starts empty; OCI does not import the AWS domain’s indexes. Restore a compatible snapshot through a registered repository, or reindex from the source. Check mappings, analyzers, queries and the Security plugin configuration before you switch the endpoint.

​

Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.