The Silo Problem
As organizations grow, they often end up with multiple OpenSearch clusters — one per team, one per environment, or one per compliance boundary. A security analyst investigating an incident needs to search across all of them simultaneously. The naive solution — copying all data into a single "combined" cluster — doubles storage costs and introduces replication lag.
The Solution: Cross-Cluster Search (CCS)
Cross-Cluster Search lets you query multiple clusters from a single entry point without moving data. You designate one cluster as the local cluster (where you send the query) and register one or more remote clusters (where the data lives).
Registering a remote cluster via the API:
PUT /_cluster/settings
{
"persistent": {
"cluster.remote.marketing-cluster.seeds": [
"marketing-opensearch.us-east-1.es.amazonaws.com:9300"
]
}
}
Querying across clusters:
GET /marketing-cluster:logs-*,engineering-cluster:logs-*/_search
{
"query": {
"bool": {
"must": [
{ "match": { "message": "unauthorized" } },
{ "range": { "@timestamp": { "gte": "now-24h" } } }
]
}
}
}
The syntax remote-cluster-name:index-pattern tells OpenSearch to route that portion of the query to the named remote cluster. The local cluster acts as a coordinator: it fans out the query, collects partial results from each remote, merges them, and returns a unified response.
Key trade-offs:
| Concern | Detail |
|---|---|
| Latency | Adds one network round-trip per remote cluster. Keep clusters in the same region when possible. |
| Availability | If a remote cluster is down, the query fails for that portion. Use skip_unavailable: true to return partial results instead of failing entirely. |
| Security | Each cluster enforces its own IAM/fine-grained access control. The querying user must have read permissions on both clusters. |