Amazon OpenSearch Cross-Cluster Replication
Does ZopNight manage Amazon OpenSearch Cross-Cluster Replication?
OpenSearch cross-cluster replication bills no replication fee, but every follower domain is a complete OpenSearch cluster metering its own instance-hours and storage 24/7. Unused replication targets therefore multiply search spend. ZopNight discovers replication via a dedicated provider on the 6-hour cycle and attributes follower-domain cost to flag idle targets.
Rules that fire on Amazon OpenSearch Cross-Cluster Replication
No active rule family targets Amazon OpenSearch Cross-Cluster Replication today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, cost tracking, and recommendations only. |
OpenSearch cross-cluster replication copies indexes from a leader domain to follower domains for read locality and disaster recovery. Every follower domain is a fully billed OpenSearch cluster, so unused replication targets multiply search spend.
Followers pay full fare
Replication itself adds no service fee; what it does is justify the existence of another domain. A follower runs its own data nodes billing instance-hours, its own EBS or UltraWarm storage billing per GB, and, if configured like its leader (the default instinct), its own dedicated master nodes. Inter-region replication adds cross-region data transfer on the replication stream. The result is that a leader-plus-follower pair costs roughly double a standalone domain, before anyone has confirmed that queries actually reach the follower.
Replication targets, checked for readers
A dedicated provider discovers cross-cluster replication relationships on the 6-hour cycle, with follower-domain cost attributed from Cost Explorer or CUR 2.0. Recommendations target underused replication targets: follower domains whose search request metrics show no local read traffic, which means the replication is shipping data continuously to a cluster nothing queries. For DR-motivated followers, the finding becomes a sizing question: whether the recovery objective needs a same-sized always-on follower or whether snapshot-based restore into a smaller footprint would meet it.
How followers go quiet
Geo-locality projects are the usual origin: a follower placed near a user population that then gets served from the leader anyway, because routing the reads was the step that never shipped. Migration flows contribute. Replication set up to move to a new domain, cutover completed, replication left running backward into the old one. And DR followers inherit every scaling decision the leader makes, growing in lockstep with production while serving zero queries.
Confirming replication topology
The OpenSearch console shows domains and their configurations; the replication relationships are visible through each domain’s cross-cluster connections. Per-domain search and indexing metrics in CloudWatch settle whether a follower is a read replica in fact or only in intention; indexing throughput without search throughput is the idle-target signature.