Managed OpenSearch
Last reviewed by Tyler Eastridge
Managed OpenSearch from AceMQ means our engineers run your OpenSearch clusters for you: high availability and shard design, Index State Management for log analytics and search indices, snapshots with restore tests, version upgrades across 2.x and 3.x, monitoring and the pager. We work inside your cloud account, data centre or Kubernetes clusters (Tier 3), or on infrastructure AceMQ runs (Tier 4). If Amazon OpenSearch Service or Serverless suits you better, this page says so.
Support quotes answered within 1 hour, by a senior engineer.
Planning a build, upgrade or migration instead? See AceMQ OpenSearch consulting and services.
Customers
Partners
What's Included
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
We manage monitoring of what predicts OpenSearch incidents: cluster status and unassigned shards, disk against the watermarks, JVM heap pressure, rejected indexing and search requests, and snapshot age. Then we take the pager, so an alert reaches an engineer who knows your cluster.
Primary shard counts, shard sizes and index templates chosen against your data and queries, because the number of primaries is hard to change after an index exists. Oversharded and undersharded indices are found and fixed before they cause an outage.
Index State Management policies for rollover, force merge, snapshot, warm tiers and delete, attached to new indices by template and to existing ones explicitly, with the failed-action alerts that stop a policy from silently sticking.
Scheduled snapshots to object storage, a repository per major version, and a restore into a scratch cluster on a calendar, timed against your recovery objectives. A snapshot you have not restored is a hope.
Minor upgrades on an agreed cadence after a test on a copy. Major upgrades, 1.x to 2.x and 2.x to 3.x, run as projects inside the service with a reindex plan for old indices, a plugin check and a rollback.
Security plugin roles, tenants and role mappings (fine-grained access control) reviewed against least privilege, TLS settings checked, and the build you run tracked against the project's release notes and advisories. Access to your environment follows your change process and is logged.
Why AceMQ
Run managed OpenSearch in your own account, data centre or Kubernetes clusters (Tier 3) when residency and compliance keep the data in your boundary, or have AceMQ host it (Tier 4) when you want endpoints and no infrastructure to run. The operator is an OpenSearch specialist under an AceMQ contract, not a generic hosting provider.
AceMQ holds the contract, the SLA and the escalation path, and brings partner OpenSearch specialists in as the work needs them. Incidents start with an engineer who has your cluster layout and runbooks in front of them. The 15-minute response is a response time, not a resolution time.
Many OpenSearch incidents start upstream: a Logstash pipeline that floods one index, an ingest burst that outruns the shards, a dashboard query that scans every index. We manage the cluster and also work on ingest, index templates and query behaviour.
Snapshot, restore and upgrade runbooks, shard and ISM design notes and monitoring configuration are maintained as yours. If you bring operations back in-house, or move a cluster between your infrastructure and ours, there is a current handover pack.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
Managed OpenSearch compared
People who search for managed OpenSearch are usually comparing AWS products with a service that has people behind it. The AWS options are platforms: AWS runs the engine and you work inside its limits. AceMQ's managed service is engineers, who run OpenSearch on infrastructure you own or on ours. Each row answers one question.
| Question | AceMQ managed OpenSearch (Tier 3 or 4) | Amazon OpenSearch Service (domains) | Amazon OpenSearch Serverless |
|---|---|---|---|
| Who runs it | AceMQ engineers with partner OpenSearch specialists, under a contract with a 15-minute emergency response. | AWS runs the managed domain. You choose instance types, shard layout and index design, and you keep the on-call for what the data and queries do. | AWS, on demand. You create collections for time series, search or vector search and do not size nodes. |
| Where it runs | Your cloud account, data centre or Kubernetes (Tier 3), or infrastructure AceMQ runs (Tier 4). | AWS. | AWS. |
| Which versions | OpenSearch 3.x and 2.x. 3.9.0 is the project's current release, from 29 September 2026. | AWS lists OpenSearch 3.5, 3.3, 3.1, 2.19 and older lines, so its newest 3.x trails the project's. | Clients must be compatible with OpenSearch 3.x. |
| Upgrades | Planned as projects inside the service: reindex old indices, check plugins, test on a copy, roll back if needed. | In-place upgrades with pre-upgrade checks and an automatic snapshot. 1.3 and 2.x domains go to 2.19 first, then to 3.x. | No upgrade work, and no automatic migration from a domain: moving in means reindexing. |
| Customisation | Plugins, node roles, ISM, snapshot targets and settings as your workload needs. | A managed set of settings and plugins. | Custom plugins are not supported. |
| Best when | You have an existing estate, want data inside your own boundary, run on Kubernetes or on premises, or want one contract across search, messaging and databases. | You are on AWS and want AWS to run a standard OpenSearch domain. | You want search or log collections with no nodes to size, and can live inside the service's limits. |
Sources: opensearch.org releases; AWS documentation for Amazon OpenSearch Service (supported versions, upgrades) and Amazon OpenSearch Serverless; all checked 4 November 2026. AWS dates and versions are AWS service terms, not OpenSearch project dates. Vendor terms change, so check them before you commit.
ISM and snapshots
Many OpenSearch incidents on a long-lived cluster are lifecycle failures: an index that never rolled over, a policy that stopped, a snapshot nobody restored. These are the specifics we manage.
An ISM policy's template applies only to indices created after it exists. Indices that already exist need the policy attached explicitly, so a new policy can sit beside a hundred old indices doing nothing.
After a policy is attached, ISM runs a job every 5 minutes by default. An action timeout shorter than the work, plus one job interval per step, fails on a cluster that is merely busy.
OpenSearch snapshots are incremental, so frequent ones add little storage. Copying node data directories is not a consistent backup, and the project's documentation says snapshots are the only reliable way to back up a cluster.
An index can be restored only if it was created by the current or the previous major version, and the project recommends a separate repository for each major version. We test the restore path before an upgrade, not after.
The project's own comparison and migration guidance sits on the OpenSearch vs Elasticsearch page. OpenSearch vs Elasticsearch compared
Shard design
The number of primary shards is fixed when an index is created. A decision made on day one is paid for until the next reindex.
AWS's guidance is to keep shards between 10 and 30 GiB where search latency matters, and between 30 and 50 GiB for write-heavy log workloads. It is a good starting point on any OpenSearch cluster, tested against your queries.
Each shard uses CPU and heap. The same AWS guidance puts a ceiling at no more than 25 shards per GiB of Java heap on a node. A cluster of thousands of tiny daily indices hits that long before it runs out of disk.
Open source OpenSearch defaults a new index to one primary and one replica. Amazon OpenSearch Service domains default to five primaries and one replica. An index template written for one is often wrong for the other.
Splitting or shrinking is possible within limits, but a wrong design usually ends in a reindex into a new index and an alias switch. We plan it around ingest, and keep the old index until the new one has run a full business cycle.
Shard sizes and the heap ceiling are AWS's published guidance; we tune them against your queries and ingest rate.
2.x to 3.x
OpenSearch 3.9.0 is the current release. The project keeps the current and the previous major version maintained, and gives no calendar end date for 2.x: its maintenance runs until the GA release of 4.0. A managed service has to turn that into a plan.
A version stays under maintenance until the next major enters maintenance, or one year passes. Maintenance means bug fixes and security patches without new features. OpenSearch 1.x left maintenance on 6 May 2025.
AWS requires domains on 1.3 or 2.x to upgrade to 2.19 before 3.x. Indices created in OpenSearch 1.3 or Elasticsearch 7.10 must be reindexed first, and snapshots taken on 1.x are incompatible with 3.x.
AWS's pre-upgrade checks fail a domain with a red cluster, too many shards on a node, high disk or JVM pressure, or an optional plugin the target version lacks. We clear these before the window rather than during it.
Inventory of clients, plugins and old indices, a rehearsal on a restored copy, a rollback plan and a cutover window agreed with you. The old cluster stays available until the new one has carried real traffic.
AWS in-place upgrades take a snapshot first and can run from 15 minutes to several hours.
Tier 3 and Tier 4
Tiers 1 and 2 are AceMQ's OpenSearch support: you hold the pager and we respond and review. Tiers 3 and 4 are managed services: we hold it. The two managed tiers run the same operations. What differs is where OpenSearch runs and who owns the infrastructure.
AceMQ operates OpenSearch in your cloud account, data centre or Kubernetes clusters, with system access and your change process. You keep the account, the data and the infrastructure bill.
AceMQ hosts and operates OpenSearch on infrastructure it runs, with snapshots, upgrades and monitoring included. You get endpoints, not a cluster or an on-call rota.
If you run Amazon OpenSearch Service, AWS operates the service underneath and your AWS support entitlement stays yours. AceMQ works on sizing, shard and ISM design, snapshots, upgrade planning and the workload around it.
An estate can start with support and a review of shards, snapshots and the version position, then hand over operations. Nothing about Tier 3 or 4 requires a big-bang handover.
AceMQ does not publish prices for managed services. A quote is built from cluster count and size, ingest rate, cover hours and tier, and returns within 1 hour. Tiers 1 and 2 are set out on the OpenSearch support page. OpenSearch support: 24/7, 15-minute SLA
Choosing honestly
A managed AWS service is the right answer for some workloads. These are the differences that decide it.
You are on AWS, your workload fits a standard domain, and you want AWS to run it. Plan for the version calendar: AWS publishes standard and extended support dates per version, and extended support is charged.
You want collections you do not size, for search, time series or vector search, and you accept compute billed in OpenSearch Compute Units, no custom plugins and a reindex to get in.
You already run OpenSearch on virtual machines, on premises or on Kubernetes, need data to stay inside your boundary, want the project's newest versions, or want one contract for OpenSearch, Kafka, PostgreSQL and the rest.
Your estate is built on Elastic's features and you have no reason to move. A move between the two is a separate project, scoped on its own, and the migration guide sets out the work.
What none of them removes: mappings, query design and application behaviour still belong to whoever owns the workload. Elasticsearch to OpenSearch migration guide
Not a fit for
We would rather say so up front.
AceMQ is a specialist service with a contract and senior engineers. If you want a search collection you create by clicking, with no contract, buy it from AWS.
Analyzers, ranking and query tuning for a product catalogue are consulting, not operations. They sit on the OpenSearch page and can lead into a managed contract.
A scratch cluster with no uptime target needs a current version and a snapshot, not a managed service.
A migration to another engine is its own project. Once the data is there we can operate it if it is on our list.
Running several engines? One contract can also cover Elasticsearch, Kafka and PostgreSQL. Managed open source services
Escalation Path
Every tier reaches a senior OpenSearch engineer. There is no tier-1 triage layer to get through.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Typical engagements
Typical OpenSearch support and remediation engagements. Each card links to the scenario: the cluster or domain, what AceMQ checks or changes, and what the engagement delivers.
Insurance Services Provider
Emergency recovery of an OpenSearch domain where snapshot restores were failing partway through and leaving indices in a red state.
OpenSearch
Amazon S3OpenSearch Dashboards
LinuxPublic Sector Agency
24/7 enterprise support for OpenSearch clusters carrying regulated search and audit workloads, including security plugin and upgrade coverage.
OpenSearchOpenSearch DashboardsLinux
KubernetesDigital Media Platform
Assessment of the technical and licensing implications of moving a large Elasticsearch estate to OpenSearch, including client and plugin compatibility.
OpenSearch
ElasticsearchAmazon S3
TerraformDigital Commerce Platform Team
A typical engagement for a team that runs Elasticsearch for site search and wants a written comparison of OpenSearch, Apache Solr and staying put, based on the queries and features it actually uses.
ElasticsearchOpenSearchApache SolrB2B SaaS Platform Provider
Consulting engagement to design tenant isolation, index strategy, and query governance for OpenSearch serving thousands of customer tenants.
OpenSearchKubernetesOpenSearch DashboardsTerraform
Platform Engineering Team
A typical engagement for a platform team weighing a move from Splunk to OpenSearch: inventory every saved search, alert and dashboard, and map each one to a replacement before any data moves.
SplunkOpenSearchKubernetesLinuxSupport options
AceMQ offers OpenSearch support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for clusters and domains your team runs, proactive monitoring that catches shard, ISM and storage problems first, managed OpenSearch on your own infrastructure, and fully managed OpenSearch on AceMQ infrastructure. OpenSearch 1.x, 2.x and 3.x are covered, self-managed or on Amazon OpenSearch Service.
You run it, we back you up
Best for: Teams that run OpenSearch themselves, on AWS or elsewhere, and need senior cover beyond what the platform provider answers.
You run it, we watch it with you
Best for: Teams that want the blue/green stall or the lockout found in a review, not on a Friday evening.
We run it in your cloud or data centre
Best for: Regulated estates that must keep search and audit data inside their own cloud account or network.
We host it and run it, as a service
Best for: Teams that want OpenSearch search or log analytics without operating the cluster, and do not need it in their own account.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs OpenSearch day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for OpenSearch
Support is one part of what AceMQ does for OpenSearch. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
Yes. Tier 3 runs in your AWS, Azure or Google Cloud account, on virtual machines, on Kubernetes you run, or on premises including air-gapped sites, using your access controls and change process. AceMQ works with system access and administrative access to the cluster, inside that change process and logged. Tier 4 is the alternative when you would rather run no infrastructure. Amazon OpenSearch Service and Serverless are run by AWS, so Tiers 3 and 4 do not apply to them; ask us about support for the workload around them.
OpenSearch 2.x is in maintenance, which the project ends at the GA release of 4.0, and it gives no calendar date. AceMQ operates 2.x in the meantime and plans the move to 3.x as a project inside the service, with a reindex of old indices, a plugin check and a rollback. On AWS the route goes through 2.19 first.
Stay if your estate depends on Elastic features and nothing is pushing you. Move if you want Apache 2.0 terms, AWS's managed service or OpenSearch's governance. A move is a separate project with a reindex and client changes, not part of managed operations. The comparison and the migration guide set out the differences with sources.
Yes, where it is Logstash and OpenSearch Dashboards feeding the cluster. Ingest flooding one index, a stalled output and a slow dashboard query are common causes of OpenSearch incidents, so they are in scope. Other collectors, agents and sources are scoped case by case with your engineers.
Yes. AceMQ works on OpenSearch in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Managed OpenSearch is quoted per scope, with no list price: the price depends on the number of environments and nodes, the SLA, whether AceMQ runs OpenSearch on your infrastructure (Tier 3) or on ours (Tier 4), and the access and change process you need. Request a quote and AceMQ replies within 1 hour.
Let's talk
Reactive cover, proactive reviews, or AceMQ running OpenSearch for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
Production incident right now?Email an OpenSearch Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
