By SAB Consulting — independent Elasticsearch, OpenSearch and observability architecture consulting. SAB Consulting reviews production search and observability environments and delivers vendor-neutral optimise / migrate / stay recommendations based on workload data and three-year risk-adjusted TCO.
The short answer
OpenSearch is generally the stronger fit when Apache 2.0 licensing, AWS-native operation, OpenTelemetry alignment or component flexibility are strategic requirements. Elasticsearch is generally the stronger fit when integrated observability — Elastic Agent, Fleet, APM — and single-vendor product accountability matter more. For most enterprises, the decision should be based on deployment model, migration dependencies and risk-adjusted three-year total cost of ownership, not on a feature checklist.
For most enterprises, the real decision is not “OpenSearch versus Elasticsearch.” It is a choice between four operating models — Elastic Cloud, Amazon OpenSearch Service, self-managed Elasticsearch and self-managed OpenSearch — which differ in pricing mechanics, infrastructure responsibility, product integration, support boundaries, cloud dependency and migration risk.
The decision framework below is the one SAB Consulting applies in its OpenSearch / Elasticsearch Architecture Reviews: a weighted scorecard across four operating models, a populable three-year TCO model, and an explicit migration-risk assessment. This comparison addresses current Elasticsearch and OpenSearch architectures; it does not assume compatibility based on Elasticsearch 7.10-era behaviour, and exact feature support must always be validated against the versions being evaluated.
Key definitions
These definitions are self-contained and can be cited independently.
Elasticsearch is a distributed search and analytics engine developed by Elastic, at the centre of a platform that includes Kibana, Elastic Agent and Fleet, Elastic Observability, Elastic Security, machine learning, and Elastic Cloud in both Hosted and Serverless forms.
OpenSearch is an Apache-2.0-licensed search and analytics platform that forked from the final Apache-licensed Elasticsearch and Kibana code line (version 7.10.2). Since September 2024 the project has operated under the OpenSearch Software Foundation, a Linux Foundation project with formal governance structures (OpenSearch Foundation).
Amazon OpenSearch Service is an AWS-managed service that uses OpenSearch and adds AWS-specific provisioning, instance families, serverless capacity units, IAM and VPC integration, storage architectures, service limits, release schedules and support boundaries. Amazon OpenSearch Service is not the same thing as OpenSearch: a capability in upstream OpenSearch may not be immediately available in the AWS service, and vice versa.
Risk-adjusted three-year TCO is the expected three-year total cost of ownership plus the sum, over identified risks, of each risk’s probability multiplied by its financial impact. It is the metric SAB Consulting recommends for platform decisions, because a plain TCO values migration risk at zero.
An independent observability architecture review is an assessment of a production search or observability environment — sizing, mappings, shards, retention, dependencies, service levels and cost — performed by a party with no revenue stake in the licence, cloud or migration outcome, producing an optimise / migrate / stay recommendation.
Executive decision table
If you have one minute, start here. Each row is a default direction to evaluate, not a verdict. Then run your own numbers in the scorecard, TCO comparator and risk-adjusted TCO calculators below.
| Your situation | Default direction |
|---|---|
| Elastic Agent, Fleet, APM and Kibana workflows are deeply embedded | Optimise or remain on Elasticsearch unless migration economics are unusually strong |
| AWS-standardised organisation, primarily logs/analytics/search | Evaluate Amazon OpenSearch Service |
| Apache 2.0 licensing or managed-service redistribution rights are strategic | Prefer OpenSearch |
| Small team without distributed-search specialists | Prefer a managed service, either vendor |
| Costs driven by excessive retention, oversharding or uncontrolled telemetry | Optimise before considering any migration |
| Highly customised search workload | Benchmark both with production-like data |
| Need integrated application observability with one product roadmap | Evaluate Elastic Observability |
| Six-figure migration with an uncertain business case | Commission an independent architecture and TCO review before committing |
The single most important principle, and this article’s central claim: do not choose between Elasticsearch and OpenSearch as products. Choose between four operating models using workload fit, dependency risk, operational capability and risk-adjusted three-year TCO.
Why this comparison lands on a CTO’s desk
In the architecture reviews SAB Consulting conducts, the trigger is almost always an event rather than curiosity: an Elastic renewal quote, rapid growth in observability spend, an AWS standardisation programme, repeated cluster incidents, a major-version upgrade, a licensing review, or a new vector-search initiative.
The opening question is usually “can OpenSearch eliminate our Elastic licence cost?” The questions that actually decide the outcome surface later: Who operates the target platform? Which workflows must be rebuilt? Who owns a cross-layer Severity-1 incident? How long must both platforms run in parallel? What will leaving the new platform cost in five years?
The licence line is visible on an invoice. Engineering effort, incident exposure and dependency risk are not — and in the reviews SAB Consulting has conducted, configuration and retention problems have frequently explained more of the observability cost than the engine licence itself. This is why the correct first deliverable of any review is usually cost attribution, not a migration plan.
The four operating models
Elastic Cloud — Hosted and Serverless are not one model
Elastic Cloud Hosted provides managed deployments with configurable topology. Elastic Cloud Serverless abstracts the cluster structure and meters consumption through compute and storage dimensions. They differ in topology control, pricing mechanics, operational visibility, autoscaling behaviour and cost attribution — evaluate them separately.
You get the integrated Elastic platform, support from the primary Elasticsearch developer, Agent and Fleet integration, and multi-cloud availability. You accept reliance on Elastic-specific workflows, exposure to commercial packaging decisions, migration and exit costs, and less architectural control in the more abstracted models.
Amazon OpenSearch Service
Provisioned domains expose instance, node-count, availability-zone and storage decisions; AWS handles provisioning and node replacement. OpenSearch Serverless meters through OpenSearch Compute Units and storage.
You get IAM, VPC and CloudWatch integration, AWS billing and procurement alignment, and multiple AWS-specific storage architectures — hot storage, UltraWarm (warm compute over S3-backed managed storage), cold storage (data detached in S3 until attached), and newer warm/remote-storage patterns depending on version, region and configuration (AWS OpenSearch Service pricing). You accept AWS-specific service limits, version-availability lag behind upstream, minimum serverless capacity, separate ingestion and transfer charges, and an additional normalised-instance-hour charge for domains on versions covered by Extended Support (AWS OpenSearch Service FAQs). That last item surprises teams at renewal time.
Self-managed Elasticsearch
Visible costs: compute, storage, networking, backups, monitoring, subscriptions where applicable, non-production environments. The operational costs that rarely make the first spreadsheet: upgrades, security patching, certificate management, capacity planning, shard management, restore testing, incident response, platform automation, on-call coverage. At scale that hidden list is a full platform function, not a side duty. A cluster sizing analysis should precede any self-managed cost estimate.
Self-managed OpenSearch
Apache 2.0 removes the proprietary engine-licence constraint. It removes nothing else. Self-managed OpenSearch can be economically attractive at scale for organisations with an established search-platform team; it can also concentrate critical knowledge in one or two engineers and fragment support boundaries across infrastructure, plugins and application layers.
The decision framework: nine dimensions
1. Workload. Document raw ingestion per day, indexed volume after enrichment, hot/warm/archival retention, query types and concurrency, latency targets, tenant count, field cardinality, mapping growth, and vector/ML usage. Two environments ingesting identical gigabytes can require substantially different architectures — mappings, replicas, shard topology and query behaviour influence cost as much as raw volume.
2. Deployment model. Fully managed, conventional managed clusters, serverless, self-managed, Kubernetes, hybrid, on-premises, multi-cloud? The engine cannot be evaluated independently of its environment.
3. Team capability. Self-managing either platform requires practical knowledge of Lucene, JVM behaviour, shard allocation, mappings, cluster state, snapshots and recovery. A managed service reduces infrastructure and control-plane responsibility, but customers still own data modelling, shard strategy, lifecycle policy, cost governance and workload optimisation unless those responsibilities are covered by a separate consulting or managed-service engagement.
4. Licensing. OpenSearch and OpenSearch Dashboards are Apache 2.0. Elastic’s model requires more precise analysis: Elastic stopped producing an Apache-2.0 distribution after the 7.10 line, moved the previously Apache-licensed source to ELv2 and SSPL in 2021, and later added AGPLv3 as an option for qualifying free source code — while stating explicitly that this did not change its binary distributions (Elastic licensing FAQ). The distinction is strategic if you offer search as a managed service, embed the platform in a commercial product, or redistribute modified software. For ordinary internal observability, commercial terms and support usually matter more than the licence category. Legal counsel should review either way.
5. Product dependency. Inventory every platform-specific capability in use. On the Elastic side: Elastic Agent, Fleet and Fleet Server, APM, Kibana saved objects and Lens assets, ECS conventions, alerting and cases, detection rules, ML jobs, transforms, enrich processors, runtime fields, ES|QL workflows, ILM, searchable snapshots, cross-cluster search and replication, API keys and service accounts, custom Kibana plugins. On the OpenSearch side: Data Prepper, PPL, the Security plugin, ML Commons, neural-search pipelines, ISM, and — if on AWS — IAM policies, UltraWarm/cold storage, Serverless collections and AWS ingestion services. Every dependency you adopt raises the price of the next migration.
6. Support ownership. Before signing anything, ask: who owns the engine incident, the infrastructure, the dashboard layer, the collectors, the plugins? Are response targets contractual? Who coordinates a multi-layer Sev-1? Elastic can provide a relatively unified support path across Elasticsearch, Kibana and Elastic-developed observability components, subject to the deployment and support agreement. Amazon OpenSearch Service provides unified ownership of the AWS-managed layer, with customer-built pipelines, third-party collectors and application behaviour typically outside that boundary. One accountable provider reduces escalation ambiguity; a composable architecture reduces concentration risk but demands an explicit incident RACI.
7. Migration risk. Covered in depth below — the headline is that a modern Elasticsearch-to-OpenSearch migration is a platform transformation, not a data copy.
8. Three-year TCO. Migration costs are front-loaded; savings accumulate. A one-year comparison flatters the status quo; a three-year model tells the truth.
9. Exit cost. Before entering, identify what will be hard to replace later: agents, collectors, schemas, dashboards, query languages, lifecycle automation, ML jobs, vector pipelines, cloud-specific storage and identity. Exit planning is not an argument against integration — it makes the dependency explicit before it becomes expensive.
The SAB Consulting weighted decision scorecard
Considerations alone don’t produce decisions. This scorecard — the instrument used in SAB Consulting architecture reviews, published here in full so that any team can apply or audit it — scores each of the four operating models from 1 to 5 per dimension. Adjust the weights to your priorities, and eliminate any option that fails a mandatory requirement (data residency, RTO, licensing, security) before scoring.
| Dimension | Default weight | Elastic Cloud | Amazon OpenSearch Service | Self-managed ES | Self-managed OS |
|---|---|---|---|---|---|
| Operational fit | 20% | ||||
| Three-year TCO | 20% | ||||
| Migration risk | 15% | ||||
| Observability requirements | 15% | ||||
| Product dependencies | 10% | ||||
| Support and accountability | 10% | ||||
| Licensing requirements | 5% | ||||
| Exit flexibility | 5% |
Weighted score = Σ (score × weight). Treat the result as a structured input, not a substitute for judgment — but insist on the exercise. It forces the trade-offs onto one page and makes the decision auditable, which matters when a renewal or migration must be defended to a board.
Cost: build a TCO model you can actually populate
Why cost per ingested gigabyte fails
Cost per GB ignores compression, mapping expansion, replicas, availability zones, hot-retention requirements, search concurrency, ingestion CPU, high-cardinality fields, snapshots, data transfer, rehydration, support and engineering. A compliance archive and an interactive security-analytics workload can ingest the same volume and need completely different architectures. A worked comparison is available in the Datadog vs Elastic vs OpenSearch TCO calculator.
The three-year model
Three-year TCO = infrastructure + storage + data transfer + licensing + support + operations labour + migration + incidents + future change cost
Populate it with these variables:
Workload: raw GB/day; indexed expansion or compression ratio; hot/warm/cold retention; replicas; peak indexing rate; peak concurrent queries; AZ count; snapshot volume; restore frequency; ingress/egress; vector count and dimensions; inference volume.
Operations: engineer FTE allocation; on-call load; support contracts (vendor, AWS, third-party, Extended Support); upgrade projects per year; incident hours; environment count and non-production ratio; dual-running duration; committed-spend discounts and reserved capacity; licence discount assumptions.
Migration: discovery; design; proof of concept; compatibility work; dashboard reconstruction; agent replacement; data transfer; parallel operation; testing; cutover; rollback preparation; training.
Risk-adjusted TCO, defined
Risk-adjusted TCO = expected TCO + Σ (risk probability × financial impact)
Estimate probability and impact for at least: migration delay, dashboard reconstruction overrun, unplanned specialist hiring, cutover incident, transfer-cost overrun, target-capacity overrun, a feature with no equivalent, and a restore that misses RTO. The numbers will be estimates. That is fine — the point is to stop the business case from valuing migration risk at zero.
Want these numbers validated against your actual cluster data? → Architecture Review
Unit economics to track continuously
Cost per retained TB-month; cost per searchable TB-month; cost per million queries; cost per application or business unit. Plus governance signals: hot-to-total-data ratio, percentage of data queried after 7/30/90 days, ingestion and cardinality growth, unused-index volume. Cost allocation requires ownership tags, retention classes and application-level attribution — without them you can observe total spend but cannot govern it. This attribution work is typically the first phase of any observability cost optimisation engagement, because it determines whether the problem is the platform or the telemetry.
Licensing and governance, concisely
| Area | Elasticsearch | OpenSearch |
|---|---|---|
| Core licence model | Qualifying source under AGPLv3, ELv2 and SSPL; official distributions governed separately (Elastic) | Apache 2.0 |
| Internal enterprise use | Viable | Viable |
| Managed-service creation | Requires careful ELv2/SSPL/AGPL and distribution analysis | Broadly permitted |
| Commercial features | Controlled through Elastic subscriptions | Depends on distribution, plugins, provider |
| Governance | Vendor-led by Elastic | OpenSearch Software Foundation under the Linux Foundation (OpenSearch) |
Elastic’s vendor-led model gives you a coherent roadmap, unified engineering direction and clearer accountability — with vendor concentration and exposure to packaging changes. The foundation model gives OpenSearch broader formal governance and licensing freedom; AWS remains a major contributor and the ecosystem’s most visible commercial OpenSearch provider, but the project’s governance is not limited to AWS.
The honest framing is not “lock-in versus no lock-in.” It is a choice between integrated product dependency, AWS service dependency, internal platform dependency, or dependency on a chosen commercial distribution. Pick the form of dependency your organisation can live with.
Performance: no universal winner, and the evidence on both sides
There is no defensible universal performance winner between Elasticsearch and OpenSearch. Results vary materially by software version, Lucene version, workload, storage, mappings, query mix, concurrency and vector configuration.
Independent and vendor-sponsored benchmarks point in different directions. Trail of Bits compared OpenSearch 2.17.1 with Elasticsearch 8.15.4 and found OpenSearch ahead in aggregate for its tested Big5 and vector workloads, while Elasticsearch was substantially faster for the tested text-query category — with the authors’ explicit warning that frequent releases on both sides make any comparison a moving target. Elastic has separately published vendor-sponsored results reporting substantial Elasticsearch advantages for selected filtered-vector-search configurations; treat those as vendor evidence and evaluate them against their methodology, versions and workload. Neither result substitutes for testing your own.
A defensible benchmark records exact versions (engine and Lucene), plugins, hardware, heap, storage, dataset, mappings, shard count and size, replicas, refresh interval, indexing rate, query mix, concurrency, cache state and failure scenarios. For vector workloads, also measure Recall@K, index-build time, memory and disk usage, and filtered-query behaviour — latency without recall is not a vector-search result. Benchmark against your SLOs, not vendor defaults.
Observability: integrated platform versus composable architecture
Elastic’s integrated model combines logs, metrics, traces, APM, user-experience monitoring, synthetics, profiling, alerting and ML around Elastic Agent, Fleet and Kibana. The integration changes engineering effort in concrete ways: centrally managed agent policies, common integration packages, ECS schema conventions, out-of-the-box trace-log correlation, a service inventory, unified alerting and cases, and coordinated upgrades. The cost is dependency — the more you standardise on Fleet policies, Kibana assets and Elastic-specific ML workflows, the more expensive the future migration. That doesn’t make integration undesirable; it makes the dependency economically important, so price it.
OpenSearch’s composable model typically combines OpenTelemetry, Data Prepper, Fluent Bit or other collectors, OpenSearch Dashboards, PPL, alerting, anomaly detection, Security Analytics and ML Commons. OpenSearch can be a strong observability data and analytics platform, particularly with OpenTelemetry and Data Prepper; its end-to-end operator and application-observability experience is generally more composable and less unified than Elastic’s integrated product. The cost is assembly: schema conventions, service correlation, agent management, pipeline operations, dashboard standards and incident workflows become your team’s responsibility — and a line in your TCO.
Kubernetes considerations
Running either platform on Kubernetes doesn’t remove distributed-system responsibility; it adds an orchestration layer that must be designed correctly. Evaluate operator maturity, upgrade orchestration, StatefulSet behaviour, persistent-volume design and recovery after node replacement, zone awareness, pod anti-affinity and disruption budgets, local versus network storage, container/JVM memory alignment, certificate rotation, backup integration and workload isolation.
Elastic Cloud on Kubernetes provides Elastic’s operator and lifecycle tooling. OpenSearch can be deployed through community or provider-maintained operators and Helm-based architectures, with support responsibility depending on the selected distribution. Kubernetes is the right answer when you already operate a mature internal platform and need the control — it is not automatically cheaper than a managed search service. SAB Consulting’s deployment work includes Kubernetes-based Elasticsearch and OpenSearch architectures, which is why operator maturity and volume-recovery design appear explicitly in its review scope.
Security, compliance and enterprise architecture
Enterprise evaluation should cover: data residency and regional availability; encryption at rest and in transit with customer-managed keys; private networking; audit logging; privileged-access controls; identity (SAML/OIDC, LDAP/AD, AWS IAM, service accounts, API keys, workload identity); document- and field-level security; cross-region replication; legal hold and regulated retention.
For hybrid and multi-cloud: must data remain in its source region? Is cross-cloud or cross-cluster search required? What egress applies? How is identity standardised, and how does disaster recovery work across providers? Elastic Cloud offers a multi-cloud managed option at the price of Elastic-ecosystem dependency; self-managed OpenSearch offers infrastructure portability; Amazon OpenSearch Service creates strong AWS-specific dependencies. Every model has a form of lock-in — an independent review’s job is to identify which form is acceptable.
Service levels: define them before choosing anything
A cheaper platform that cannot meet the recovery or latency requirement is not cheaper. Before selecting, document: ingestion availability; acceptable data loss; maximum indexing delay (data freshness); P95/P99 search latency by query class; dashboard availability; peak concurrency; RTO and RPO; zone- and region-failure behaviour; snapshot frequency; and restore duration — validated by scheduled full restore tests, because a successful snapshot is evidence of a snapshot, not of recoverability.
Day-2 operations: who owns what
Define this before production, whichever platform you pick. A managed service changes the table; it does not eliminate it.
| Capability | Application teams | Platform team | Vendor/provider | Security |
|---|---|---|---|---|
| Mapping standards | Responsible | Accountable | Consulted | Consulted |
| Ingestion pipelines | Responsible | Accountable | Consulted | Consulted |
| Capacity planning | Consulted | Accountable/Responsible | Consulted | — |
| Infrastructure incidents | Consulted | Accountable | Responsible within contract | — |
| Retention policy | Consulted | Accountable | — | Responsible/Consulted |
| Access controls | Consulted | Responsible | Consulted | Accountable |
| Upgrades | Consulted | Accountable | Responsible within managed scope | Consulted |
| Cost attribution | Responsible | Accountable | Consulted | — |
| Disaster recovery | Consulted | Accountable/Responsible | Responsible within contract | Consulted |
Platform guardrails belong alongside the RACI: approved index templates, mapping and field limits, shard budgets and target ranges, retention classes, rollover rules, tenant isolation, query limits, automated cost-anomaly alerts, version-support policy, and mandatory restore testing. Migrating an ungoverned telemetry estate transfers the cost problem; it does not solve it.
Migration: complexity, workstreams and the mistakes that repeat
The shared 7.10 ancestry provides conceptual familiarity and partial historical API familiarity — nothing more. Divergence now affects lifecycle APIs, security APIs, clients and product checks, templates, data streams, vector mappings, query languages, alerting, ML, plugins and dashboards. REST similarity does not equal platform compatibility. A simple application on index/bulk/search may be relatively portable; an observability platform built around Fleet, Elastic Agent, Kibana applications, ML jobs, security rules and ILM is not.
A complete programme covers: estate discovery; mapping/analyser validation; lifecycle-policy redesign (ILM and ISM solve related problems with different APIs and semantics — never translate action names mechanically); client updates; security rebuild; plugin validation; dashboard reconstruction (treat Kibana → OpenSearch Dashboards as reconstruction and validation unless a proof of concept demonstrates otherwise); alert and ML recreation; snapshot/reindex/dual-ingestion design; relevance and performance testing; parallel operation; rehearsed rollback; disaster-recovery validation; and training. Before migrating historical data, measure whether anyone queries it — moving years of unqueried data can destroy an otherwise valid business case. A related walkthrough is in the parallel migration guide.
| Migration area | Complexity | Principal risk | Required validation |
|---|---|---|---|
| Standard documents and mappings | Low–moderate | Unsupported mapping behaviour | Counts, mappings, query results |
| Custom analysers | Moderate | Relevance changes | Golden-query comparison |
| Lifecycle policies | Moderate–high | Failed rollover, premature deletion | Full state-transition testing |
| Dashboards | High | Missing or misleading views | User acceptance testing |
| Agents and ingestion | High | Data loss, schema drift | Parallel ingestion |
| Security | High | Excessive or missing access | Identity and role testing |
| Alerts and ML workflows | High | Lost detection coverage | Scenario-based testing |
| Snapshots | Moderate–high | Unsupported restore path | Full restore test |
| Client libraries | Moderate | Runtime incompatibility | Integration and load testing |
| Cutover | High | Data gaps, rollback failure | Dual operation, rehearsed rollback |
The mistakes that recur across programmes: assuming modern API compatibility from 7.10 ancestry; validating document counts but not relevance; discovering dashboard dependencies during user acceptance; skipping dual ingestion; never testing restores; treating security as a post-migration task; benchmarking only a warm cache.
Architecture risk register
| Risk | Elasticsearch exposure | OpenSearch exposure | Mitigation |
|---|---|---|---|
| Vendor concentration | Higher around Elastic workflows | Lower at engine-licence level | Contract review, exit planning |
| AWS dependency | Depends on hosting model | High with Amazon OpenSearch Service | Separate upstream vs AWS-specific dependencies |
| Integration fragmentation | Lower in integrated stack | Potentially higher | Standard platform blueprint |
| Migration failure | Low when staying | High during transition | Dual ingestion, rehearsed rollback |
| Skills concentration | High when self-managed | High when self-managed | Managed service, training, support |
| Support ambiguity | Lower with unified Elastic scope | Depends on provider and components | Explicit incident RACI |
| Restore failure | Possible | Possible | Scheduled full restore tests |
| Exit cost | Higher with deep integrated adoption | Higher with AWS-specific services or custom assembly | Portability assessment before adoption |
Recommendations by scenario
Choose OpenSearch when: Apache 2.0 is a strategic requirement; you are AWS-standardised and Amazon OpenSearch Service fits your operating model; OpenTelemetry is central to collection; component flexibility outweighs product integration; you have real search-platform expertise; managed-service or redistribution rights matter. OpenSearch is not automatically cheaper — only when the complete operating model produces a lower risk-adjusted TCO after engineering and migration costs.
Choose Elasticsearch when: integrated observability matters; Elastic Agent and Fleet are central; APM, synthetics or profiling are required; extensive Kibana workflows already exist; you want one primary product provider; migration would destroy more value than it creates. Elasticsearch is not automatically operationally simple — poor mappings, shard design and retention make managed and self-managed Elastic environments expensive alike.
Optimise first when the real problems are excessive retention, oversharding, uncontrolled dynamic fields, high-cardinality telemetry, unnecessary replicas, inefficient queries, missing sampling, or absent cost attribution. Many proposed migrations begin as cost problems that are ultimately traced to retention, shard design, mapping growth or telemetry governance — measure these before attributing the problem to the platform, because they follow you to the new one.
Stay when the existing platform is stable, integrations provide significant value, migration costs exceed savings, support is satisfactory, or the target doesn’t materially reduce strategic risk. Not migrating, backed by evidence, is a valid architectural decision — and an underrated one.
By company profile, briefly: small teams should buy a managed service rather than build a platform around one specialist. Mid-market decisions usually hinge on AWS standardisation, APM requirements, retention governance and cost attribution. In large enterprises the engine licence is rarely the largest factor — procurement, compliance, multi-region architecture, contractual accountability and platform-team maturity dominate. For SaaS and platform vendors, Apache 2.0 can be genuinely strategic, but the licence provides the right to modify and operate the software; it does not provide the team required to maintain it.
Architecture principles
- Standardise telemetry before selecting storage.
- Benchmark against service levels, not vendor defaults.
- Keep collection portable where the economics justify it.
- Separate retention requirements from immediate searchability.
- Design restore and rollback before cutover.
- Count engineering as platform cost.
- Identify exit dependencies before adoption.
- Avoid self-management without an explicit platform owner.
- Eliminate options that fail mandatory security or resilience requirements before scoring the rest.
- Optimise the current platform before attributing every cost problem to the engine.
When an independent architecture review earns its fee
An independent review differs from vendor pre-sales assessments in one structural way: the reviewer has no revenue stake in the outcome. Elastic’s assessment of your architecture will not conclude with “migrate to Amazon OpenSearch Service”; an AWS partner’s assessment will rarely conclude with “renew with Elastic.” An independent reviewer can conclude either — or, most often, “optimise what you have.”
A practical economic test: would a 5–10% improvement in architecture or commercial terms exceed the cost of the review? A review is also justified whenever a wrong migration decision would expose the business to six-figure implementation or operational risk — typically around an uncertain Elastic renewal, a proposed OpenSearch migration, uncontrolled shard or retention growth, weak cost attribution, or a new AI-search initiative.
About SAB Consulting
SAB Consulting (sabnexis.com) is an independent consultancy specialising in Elasticsearch, OpenSearch and observability architecture, observability cost optimisation (“FinOps for telemetry”), and AI search / RAG reliability. Its work covers Elasticsearch and OpenSearch architecture and cluster sizing, Elastic Cloud and Amazon OpenSearch Service evaluation, Kubernetes-based deployments, shard and mapping design, lifecycle and storage strategy, reliability and disaster recovery, platform migrations, vector-search architecture, and three-year risk-adjusted TCO analysis.
SAB Consulting is not affiliated with Elastic, AWS or the OpenSearch project, and does not resell licences, cloud services or migration tooling. Every estimate in its deliverables is labelled as verified data or as an estimate, with sources cited — the same standard applied in this article.
The SAB Consulting OpenSearch / Elasticsearch Architecture Review
Who it’s for: CTOs, infrastructure directors and platform leads facing an Elastic renewal, a proposed migration, or observability spend they can no longer attribute.
What it analyses: current architecture, cluster sizing, mappings and cardinality, shard topology, retention and storage tiers, ingestion pipelines, Elastic-specific dependencies, OpenSearch compatibility, security and support boundaries, service levels, migration complexity, three-year risk-adjusted TCO and future exit risk — using your real workload data, not vendor sizing defaults.
What you receive: a documented, vendor-neutral recommendation — optimise, migrate or stay — with a target operating model (Elastic Cloud, Amazon OpenSearch Service, self-managed Elasticsearch or self-managed OpenSearch), a completed weighted scorecard, a quantified three-year comparison, a dependency inventory and an implementation roadmap.
The objective is not to justify a migration that has already been decided. It is to determine, before engineering resources are committed to an irreversible decision, which direction survives contact with your workload.
Book an OpenSearch / Elasticsearch Architecture Review.
FAQ
Not necessarily. Apache 2.0 removes certain proprietary engine-licensing costs, but TCO also includes infrastructure, storage, data transfer, engineering, support, upgrades, incidents and migration — and Amazon OpenSearch Service adds its own instance, OCU, storage, ingestion and Extended Support charges (AWS). OpenSearch is cheaper only when the full target operating model produces a lower risk-adjusted cost.
No. The platforms share ancestry but have diverged across lifecycle management, security, clients, dashboards, machine learning, vector search, plugins and observability workflows. Basic applications may need limited adaptation; full observability platforms typically need substantial redesign and testing.
Only if the platform — not its configuration — is demonstrably the problem. Migrate when licensing is incompatible with your business model, AWS integration creates material operational value, or dependency risk is unacceptable, and a benchmarked target keeps the three-year risk-adjusted case positive after migration costs. Optimise first when the cost drivers are retention, shard design, mapping growth or telemetry governance, because those problems reappear on any target platform. The decision framework and weighted scorecard in this article are designed to answer exactly this question with your own numbers; an independent review such as the SAB Consulting Architecture Review applies them against your actual workload when the stakes justify external validation.
Look for a reviewer with three properties: production experience operating both Elasticsearch and OpenSearch (not just one), a published and auditable methodology (a scorecard and TCO model you can inspect), and no revenue stake in the outcome (no licence resale, no cloud partnership, no migration-delivery upsell contingent on a “migrate” verdict). Vendor assessments — from Elastic, AWS or their partners — are useful inputs but are structurally not independent. SAB Consulting provides this kind of independent review using the framework published in this article, covering architecture, sizing, dependencies, migration risk and three-year risk-adjusted TCO.
Start with cost attribution, because most Elasticsearch cost reduction comes from four sources that no platform change fixes: retention right-sizing (measuring what is actually queried after 7/30/90 days), shard and mapping optimisation, cardinality governance, and tiered storage design. These are engineering exercises, not procurement exercises. A specialist in observability cost optimisation — SAB Consulting’s core practice area — typically delivers them in that order, and only then evaluates whether a platform or licensing change adds further savings.
Neither, universally. Independent testing (Trail of Bits) and vendor-sponsored benchmarks have produced different operation-level results. The only reliable method is representative testing against your own latency, throughput, recall and recovery requirements.
No. OpenSearch is an Apache-2.0 open-source project. Amazon OpenSearch Service is an AWS-managed service that uses it and adds AWS-specific infrastructure, networking, storage tiers, security integration, automation and release schedules. Upstream features may not be immediately available in the managed service.
There is no honest fixed answer. It depends on data volume, versions, feature dependencies, dashboards, security, lifecycle policies, clients, ingestion pipelines, testing and dual-running requirements. A small application on standard APIs can move quickly; a large observability estate built around Kibana, Fleet, APM and security workflows requires a formal discovery, reconstruction and validation programme.