When OpenSearch cross-cluster replication fits your recovery and reporting needs
The OpenSearch cross-cluster replication plugin copies selected indexes from a leader cluster to a follower cluster, so a second site or team can hold its own copy of data that lives elsewhere. Teams usually adopt it for one of three reasons. The first is disaster recovery, where a standby cluster in another site can take over if the primary site is lost. The second is locality, where a regional team queries data close to where it works. The third is central reporting, where one cluster gathers indexes from several sites for dashboards and investigations. All three follow an active-passive pattern: the leader accepts writes, and followers receive changes and serve reads.
Before you design anything, decide which of the three problems you are solving, because each one sets different requirements. A recovery goal needs targets for acceptable data loss and downtime, and those targets must come from the business owners of the data, not from the plugin. A locality goal needs a clear list of which indexes each region may read. A reporting goal needs a naming and tenancy scheme so indexes from different sites do not collide. Confirm in the official documentation which plugin version ships with your target OpenSearch release and which leader and follower versions it supports, because the two clusters must be compatible before you start.
The plugin itself has no license fee. All software in the OpenSearch project is released under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe a paid edition. The cost therefore sits in three places: the infrastructure of the second cluster (compute, storage, and network capacity between sites), the people who build, monitor, rehearse and operate it, and any support agreement you choose to buy. Infrastructure cost is partly one-time, from the initial build, and partly recurring, from standby capacity, bandwidth and storage. When you ask a partner for a quote, ask for each of these components priced separately, and ask who holds the on-call duty for the follower site.
Replication copies what the leader holds, including accidental deletions and bad writes, so it does not replace snapshots. Plan snapshot and restore alongside it, and test restores as well as failovers. Replicated data also keeps its sensitivity, so configure the Security plugin on the follower with the same role-based and field-level controls the leader enforces, and give the replication user only the permissions it needs. Before go-live, confirm that the standby can carry the workload it is meant to take over, and that the failover and failback steps have been written down and rehearsed by the team that will run them.
OpenSearch cross-cluster replication options and when each fits
This table compares the main choices a team makes with OpenSearch cross-cluster replication: how much data to replicate, where the copy goes, and whether replication is the right tool for the goal. Read each row as a decision: the fit describes when the option makes sense, the trade-off describes its operational or recovery cost, and the last column lists what to check in the documentation for your version. The main takeaway is that replication suits continuous standby or reporting copies, while snapshots, reindexing and migration tooling suit other goals.
| Option | Best fit | Main trade-off | Confirm in the docs |
|---|---|---|---|
| Whole-index replication to a disaster recovery site | Standby site must hold every index the business needs to recover | Standby carries full storage and network load for all replicated data | Supported version range, failover and failback steps, security configuration on the follower |
| Selected-index replication | Critical indexes need a standby while lower-value data stays local | New indexes outside the pattern stay unprotected until someone updates the rules | How patterns are matched, whether new indexes are picked up automatically, and any rule limits |
| One-way replication to a central reporting cluster | Several source clusters feed one read-only analytics cluster | Target absorbs fan-in load, and reporting lags behind source data | Fan-in limits, read-only behavior of follower indexes, and how source roles map to target roles |
| Replication versus snapshot and restore for disaster recovery | Replication suits a warm standby with small lag; snapshots suit periodic recovery copies | Replication keeps clusters coupled; snapshots restore to an older point and take longer to bring back | Recovery point and time objectives proven in your own failover test, plus snapshot repository settings |
| Replication versus remote reindexing | One-time or occasional copy where documents need transformation into new mappings | Reindexing re-reads source data through the API and does not keep changes flowing | Whether deletes and updates propagate, source throughput limits, and available mapping options |
| Replication versus Migration Assistant | One-time move to a new cluster, possibly across several major versions, with a cutover | Built for migration cutover. It is not a standing disaster recovery design | Supported source and target versions, and whether live traffic capture fits your cutover window |
| Two-way or active-active writes | Little fit with the active-passive plugin when writes must land in both clusters | Conflict handling for simultaneous writes sits outside replication and needs its own design | Whether followers block writes, and whether the version supports any active-active pattern |
What both clusters must match before replication starts
Cross-cluster replication only works when the leader and follower clusters agree on version, network path, security, topology and shard placement. Each check below should be settled on paper before any replication settings are changed, because a mismatch found after setup usually means reconfiguring working clusters.
Compatible OpenSearch versions on both sides
Confirm that the leader and follower clusters run OpenSearch versions the replication plugin supports together. Check whether the plugin requires identical minor versions or allows a range, and whether an upgrade on one side must happen first. Record the exact versions on every node, because a rolling upgrade can leave the clusters briefly on different builds. Plan any upgrade window before the replication design is approved.
Network reachability and TLS between clusters
Each follower node must reach the transport port of the leader cluster, and the leader must accept connections back for the replication traffic. Map the firewall rules, routing and any load balancers between data centers or cloud accounts. Confirm that transport TLS is enabled on both sides and that each cluster trusts the other's certificate chain, including intermediate authorities and hostname verification, before testing begins.
Security plugin users and roles
Replication runs under an identity that must hold permissions on both clusters. Decide which user or service account performs replication, which indexes it may read on the leader, and which roles it needs on the follower to write. Verify that the Security plugin configuration is identical or deliberately aligned across both clusters, since a role that exists on one side only will fail silently when replication starts. Keep the replication account separate from human administrator accounts.
Dedicated cluster manager nodes
The OpenSearch cluster documentation recommends dedicated cluster manager nodes, and that recommendation matters more when a cluster also serves replication traffic. Check that each cluster has a stable set of cluster manager nodes separate from data, ingest and coordinating roles. Document how many eligible nodes each cluster has and how quorum is maintained if one site or zone is lost, because a cross-site outage should not stall the cluster manager election on the surviving side.
Shard allocation awareness on each side
Shard allocation awareness tells OpenSearch to place replica shards on nodes in different zones or racks. Configure the attribute on both clusters so that a primary and its replica never share a failure domain. Review how shards are spread across nodes in each cluster before adding replication, because a leader or follower with uneven placement will carry extra load during failover. Include the awareness attribute names in the runbook so operators can verify them after a node replacement.
Plugin versions and release-specific documentation
The replication plugin version must match the OpenSearch release running on each cluster, and that matching rule is documented per release. No version constraints were supplied for this plugin in this brief, so confirm the exact compatibility table, required plugin versions and any prerequisite settings in the OpenSearch documentation for the release you run. Check the release notes for known issues before choosing a version, and record the outcome in your change request.
How to set up OpenSearch cross-cluster replication between two clusters
This sequence sets up active-passive replication of selected OpenSearch indexes from a source cluster to a target cluster, which supports disaster recovery, data locality or central reporting. Each step ends with a check you can run, so a failed check shows which layer to fix before you continue. Cluster build and installation choices are covered in the install docs.
Confirm the replication plugin on both clusters
The platform team confirms that the cross-cluster replication plugin is installed and enabled on both the source and target clusters, on every node that takes part. Use the cluster's own plugin listing for each node and compare the versions against the plugin documentation for your release. Installation methods, including Docker, Helm, the Kubernetes Operator, tarball, RPM, Debian, Ansible and Windows, are documented in the install docs, so build or repair the clusters there first. The step is done when every node reports the plugin and both clusters run versions that the documentation supports for replication between them.
Register the remote cluster connection
On the target cluster, register the source cluster as a remote connection, using the seed nodes and the TLS and certificate setup your security team has approved. Ask the network team to confirm that the required transport ports are reachable between the two clusters from both directions. The step is done when the cluster settings show the remote connection as connected from the target side. If the connection stays disconnected, check the network path, DNS and certificates before changing anything else.
Create replication roles and users on both sides
Create a dedicated account on each cluster with only the cluster and index permissions that the replication documentation lists for the leader and follower roles. Keep this account separate from human administrator accounts and from application accounts, so its activity can be audited on its own. Map the role to the account through the Security plugin, using the authentication backend your organization already runs. The step is done when the account authenticates on both clusters and a permission check on the indexes to be replicated passes without broader access.
Start replication for selected indexes
Choose the indexes to replicate, beginning with one non-production index, and start replication for it from the target cluster. Record the index names, the leader and follower index names, and the owner of each in your change log. Watch the index move from its initial sync to an active following state on the target. The step is done when the replication status for the test index reports an active state with no errors. The exact replication settings and their syntax belong in the plugin reference for your version, so use that reference rather than copying settings from older examples.
Verify counts, mappings and replication status
After replication catches up, compare document counts between the source and target indexes, allowing for documents still arriving during active writes. Check that the target index mappings match the source, because replicated indexes must follow the leader's mapping. Review the replication status and any task errors on both clusters, then run a sample query against the target. The step is done when counts agree within the lag your team accepted, the mappings match and replication reports no errors. Save these results as the baseline for ongoing monitoring.
Choosing active-passive replication for disaster recovery and reporting
Active-passive means one cluster, the leader, accepts writes from applications while a second cluster, the follower, receives those changes and holds a copy that the business can read or promote. In the OpenSearch replication plugin, the follower replicates indexes from the leader, so the decision covers which indexes move, as well as which clusters exist. Before you choose this design, state what the follower is for: disaster recovery standby, reporting copy, or both. These purposes pull in different directions. A standby must stay current and be ready to take traffic, while a reporting copy must absorb heavy queries without affecting anything else. Write that purpose down, because every later decision depends on it.
Failover is the first operational question. Decide what triggers promotion of the follower, who has authority to make that call, and how applications are redirected to the new leader. Because the follower trails the leader, changes that the leader accepted just before a failure may not exist on the follower. Define how you will measure that lag, how far behind the follower may run against your recovery targets, and how the business will reconcile missing writes. Test the procedure on a schedule in a non-production environment and keep the results. Confirm the promotion, reverse replication and resume steps for your OpenSearch version in the replication plugin documentation, and treat any runbook that does not match that version as a draft.
Access on the standby needs its own decision. Decide which identities may read the follower, which may initiate a promotion, and which must never write to it. Many teams assume the follower is a passive copy that nobody touches, then find a pipeline or an administrator writing to it during an incident. The OpenSearch Security plugin provides role-based access control, document-level and field-level security and audit logs, so you can scope follower access the same way you scope the leader. Confirm how replicated indexes handle role and permission changes in your version, and check that roles on the follower match the intent on the leader, since a separately configured cluster can drift. Keep audit records of who changed those roles.
Reporting queries load the follower, and that load should be planned, not discovered. A reporting copy takes analytical queries that would otherwise compete with ingestion on the leader, so size its data and coordinating nodes for that work. Apply the cluster design guidance: dedicated cluster manager nodes, replicas on separate nodes, and shard allocation awareness so that copies do not share one failure domain. Also decide whether reports may run while a failover test or promotion is in progress. A standby that is also serving dashboards may need to be taken out of reporting duty during a drill, and the people who own those dashboards should know that before the drill begins.
Regional data residency rules can decide where copies may live, sometimes before any technical choice is made. A follower in another region or data center is a second copy of the data, and if that data includes personal or regulated information, the copy may be subject to the same transfer and storage limits as the original. Map which indexes contain regulated data, decide whether those indexes replicate at all, and confirm the decision with legal counsel and your data protection owner before you name a target location. Selective replication of indexes is the mechanism that lets some data stay local while other data reaches a central reporting copy. Record each decision, because the people assessing compliance will ask how residency was enforced and how it is verified over time.
Securing the replication link and the permissions behind it
Cross-cluster replication moves index data between two clusters, so it inherits every access and transport risk of both. The controls below cover who can start and read replication, how the traffic between clusters is protected, and where evidence of that activity is kept. Work through them together, because a tightly scoped replication user does little good on an unencrypted link or with audit records stored on the cluster they describe.
Role-based access for the replication user
The OpenSearch Security plugin provides role-based access control, which governs what each user, role and backend identity can do on each cluster. Give the replication user on the follower side only the index and cluster permissions that replication needs, and confirm which replication-specific permissions apply to your OpenSearch version in the plugin documentation. Review which roles can start, pause, stop or change replication so that routine index administration does not quietly alter a disaster recovery link.
Least privilege on the leader cluster
The leader cluster needs to grant read access to the indexes being replicated, and nothing more. Scope the leader-side role to specific index patterns instead of wildcards that would expose system or unrelated indexes. Document which account the follower uses to connect, who holds its credentials, and how it is rotated, because that account is the most sensitive piece of the link.
TLS for node and client traffic
OpenSearch Security provides TLS for node-to-node and client traffic. Enable it on both clusters and confirm the certificate settings that apply to your version, including how certificates are issued, which certificate authority signs them and how they are renewed before expiry. Expired or mismatched certificates are a common cause of replication failure, so include certificate lifecycle in the runbook rather than treating it as a one-time setup step.
Encrypting the link between clusters
Replication traffic crosses the network between two clusters, often between data centers or cloud regions. Treat that path as untrusted: encrypt it end to end, restrict it to the required source and destination addresses and ports, and confirm that the replication connection uses the cluster's TLS configuration rather than a plaintext route. Validate the encrypted path with a test replication before relying on it for recovery.
Authentication backends for operators and services
The Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token authentication backends. Choose the backend that matches how your administrators and automation sign in, and map their groups to roles on both clusters so that access is consistent. Decide in advance which accounts are human and which are service identities, since replication depends on the service identities staying valid.
Audit records stored outside the cluster
The Security plugin writes audit logs that record authentication and access events. Send those records to storage outside the cluster they describe, so that an attacker or a failed node cannot alter or erase evidence of replication changes. Confirm which audit categories your version supports, decide how long records are kept, and check that someone reviews them. The audit logging topic covers the configuration in more detail.
How version lifecycle and upgrades affect replicated clusters
Plan the upgrades for both clusters in a replication pair before either one moves. The leader cluster, which holds the source indexes, and the follower cluster, which pulls changes through the replication plugin, must run versions that are supported together. A version mismatch or an unsupported pairing can break replication, and the damage may not show up until a follower falls behind or stops applying changes. Treat the two clusters as one change in your calendar, not as two separate maintenance tasks. Before you schedule anything, confirm the supported version pairs in the OpenSearch migrate or upgrade documentation and record the result with the change request.
The release lifecycle determines how often you will need to make these decisions. OpenSearch versions stay under maintenance until the next major version enters maintenance or one year passes, whichever is longer. During maintenance, a version receives bug fixes and security patches but no new features. OpenSearch also targets a new minor version about every eight weeks, so the 3.8.0 release on August 4, 2026 and the 3.9.0 release on September 29, 2026 are roughly eight weeks apart. A pair that is supported today can move toward end of maintenance over time. Build a recurring review of both clusters' versions into your operations calendar rather than waiting for a security advisory to force the work.
Write the upgrade order down before the first change window. The runbook should name which cluster moves first, whether replication is paused during each step, how the team confirms that followers have caught up before and after each node or cluster change, and the point at which you stop and roll back. Ask your implementation partner or internal platform team to walk through each step against the documented procedure for your starting and target versions. Do not rely on memory of a previous upgrade, because the supported pairs and the required order can change between minor releases.
Test the full sequence in a non-production copy of both clusters before you touch production. The copy should hold replicated indexes with realistic document counts and settings, the same security configuration and the same replication rules, so the test shows what production will do. Measure whether replicated data stays consistent after each step and whether the follower resumes replication cleanly. Also check the plugin and OpenSearch Dashboards versions that your clusters run, and confirm in the documentation whether they must match the core version. Record anything that fails, change the runbook, and repeat the test until the sequence runs without surprises.
Keep the runbook as an operational record, not a one-time document. For each cluster, list the current version, the target version, the supported pair you checked, the order of steps, the test result and the owner who signs off. Add a trigger that tells the team when a version is approaching the end of its maintenance window so the next upgrade is planned early. The effort to produce the first runbook is one-time, but the test cycle and sign-off repeat with every upgrade. Ask any partner quoting this work to show which of these items are included in the fixed scope and which will be handled by your team.
Limits to confirm in your environment before you rely on replication
These six items decide whether replication behaves the way your recovery or reporting design assumes. Treat each one as an open question to answer from vendor documentation or your own test results. Work through them in order before you commit to a topology, and record the answers in the design document.
Supported version pairs
Ask which leader and follower versions the replication plugin supports together, and whether that pairing is covered for the exact OpenSearch releases you plan to run. Confirm this against the vendor documentation, because the OpenSearch release cadence means a pairing that works today may change with a later minor version. Also confirm whether your current clusters can take part in replication during a planned upgrade window.
Index settings and mapping changes
Confirm which index settings, mappings, aliases and templates replicate from leader to follower, and which must be created on the follower by hand. Test a schema change on a non-production index before you rely on it, and check how field type changes and analyzers are handled. Mismatched mappings can make replicated data behave differently in queries and dashboards, so record the expected result for each index you replicate.
Behavior when the follower is unavailable
Ask what happens when the follower cluster is down, cut off from the network or short on capacity. Confirm whether the leader keeps the operations the follower has not yet received, how long that retention lasts, and how much disk headroom the leader needs to cover it. Also confirm whether replication resumes on its own after recovery or needs manual action. Rehearse an outage in a test environment and measure how far the follower falls behind.
Deletes and index setting changes
Confirm how document deletes, index deletions, closing or renaming indexes, and changes to index settings on the leader are carried to the follower. Some of these operations may not replicate the way teams expect, and a mistaken delete on the leader could reach the follower. Decide whether the follower also needs its own snapshots so that a leader-side error does not remove the only copy of the data.
Resource overhead on both clusters
Ask the vendor how much extra CPU, memory, heap, network bandwidth and disk the replication feature adds on the leader and on the follower. Confirm how that overhead grows with indexing rate and the number of replicated indexes, including the cost of retained operations during an outage and the bandwidth between sites. Size both clusters for this load using your own indexing rates, and measure it during testing.
Plugin in your distribution
Confirm whether the cross-cluster replication plugin ships in the OpenSearch distribution you chose, whether that is a tarball, container image, Helm chart or operator, and whether it is enabled by default. Check that the plugin version matches the cluster version on both sides and that the security settings replication needs are supported by your install method. Record the answer in your build standard before design begins.
What OpenSearch cross-cluster replication costs and what it asks of your team
Is OpenSearch cross-cluster replication free to use?
The software is free to use. All software in the OpenSearch project is released under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe a paid edition. What you pay for is the infrastructure that runs the clusters, the people who design and operate them, and any outside help you buy. Confirm the license terms of any plugin, connector or hosted service you add to the stack, since those are separate decisions from the core project. Ask any partner to state in writing which components carry a license cost, if any, before you compare quotes.
What drives the cost of a cross-cluster replication project?
The main drivers are the number of clusters involved, the number of indexes and shards to replicate, the network path between sites, the testing scope and the compliance evidence you need. Each one adds design, build and verification work. Clusters in a second data center or cloud region add network and storage capacity on both sides. A high index count raises the work needed to choose which indexes to follow and to confirm they replicate correctly. Strict audit or retention requirements add evidence steps. Ask for a quote that lists each driver separately so you can see which ones your environment changes.
How long does a first cross-cluster replication setup take?
The duration depends on the scope written into the engagement, so no fixed figure applies to every team. The time moves with the same drivers as cost: how many clusters are involved, how complex the network path is, how much failover testing you require and how much of your existing identity and storage design must be settled first. Ask the partner to break the timeline into design, build, testing and handover phases with the dependencies named. A written scope lets you check each phase against your own change calendar.
What does our team need to provide before outside help starts?
Your team should provide the access and decisions that only you can supply. That includes the cluster inventory with versions, the list of indexes and their owners, the recovery point and recovery time targets your business has agreed, network routes and firewall change approvals between sites, certificate and identity sources, and a named contact for security and operations. Someone also needs to own the decisions on which data may leave a region. Gather these before the first design session, because missing inputs are the most common source of schedule slips.
Can our own engineers set up cross-cluster replication without a partner?
Yes, a team with OpenSearch operations experience can build it, provided it has time to test failover, document the runbook and rehearse recovery. The work is mainly about configuring the replication plugin, securing the connection between clusters, sizing both sides and proving that the secondary cluster can take over. Teams with little prior exposure to cluster roles, shard allocation or TLS between clusters usually find the testing and documentation take longer than the configuration. Many organizations split the work, keeping routine operations in house and buying design review or a fixed-scope build.
What does a DeployOpen quote include for this work?
DeployOpen quotes follow a written scope. Before work starts, the scope, deliverables and timeline are agreed in writing, so the quote reflects the clusters, indexes, network path, testing and evidence you specify. DeployOpen does not publish a price list. Ask for the quote to show design, build, configuration, failover testing, documentation, handover and any ongoing support as separate lines. Ongoing support, upgrades and continuous testing are available as retainers and are priced separately from the initial build.
Does DeployOpen issue compliance certificates for our replication setup?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, such as logs, configuration records and tested recovery procedures. Independent auditors and certification bodies issue audit reports, attestations and certifications. Ask your assessor early which evidence they expect for backup, retention and access control, and include that list in the scope so the build produces it. Confirm the requirements with your assessor, since they decide what counts as sufficient.
What should I check in a replication scope before signing?
Check that the scope names every cluster, index pattern and site, states the recovery targets it must meet and lists the failover tests to be run and recorded. Confirm who operates the clusters after handover and what documentation they receive. Look for the security controls covered, including TLS between clusters, role-based access and audit logging, and ask how the partner will verify each one. Finally, confirm which OpenSearch version and plugin set the design targets, since maintenance windows and upgrade paths depend on it.
How DeployOpen scopes, builds and supports OpenSearch replication
DeployOpen plans and builds OpenSearch cross-cluster replication inside the clusters and networks you control. Each engagement starts with a written, fixed scope that names the indexes, regions and recovery goals involved, and the work is tested and documented before handover. Ongoing support is available as a retainer for changes after go-live.
How we scope
- The written scope lists which indexes, index patterns and tenants replicate to the follower cluster.
- It records the source and target clusters, their network path and the security plugin roles on each side.
- Recovery expectations, failover ownership and acceptance tests are agreed in writing before any build work starts.
How we build
- Cluster roles follow the OpenSearch cluster guidance, with dedicated cluster manager nodes and shard allocation awareness on both sides.
- Authentication and TLS for node and client traffic are configured with the Security plugin, using your identity provider.
- Replication starts for the agreed indexes, then lag and failover behavior are tested against the written criteria.
How we hand over
- Handover includes the architecture record, configuration files and the runbook for failover and failback.
- Your team walks through the test results, monitoring of replication status and the procedure for rebuilding a follower.
- Open items, known limits and the upgrade assumptions for future OpenSearch minor and major versions are written down.
How we support
- Ongoing support is available as a retainer covering monitoring reviews, patching and changes to replicated indexes.
- Version upgrades are planned against the OpenSearch release and maintenance schedule before they are applied.
- Failover tests can be repeated on a schedule, with results recorded as evidence for your auditors or internal reviews.
