Remote cluster connections in Elasticsearch unlock cross-cluster search and cross-cluster replication across separate deployments, keeping data and workloads split while still allowing shared queries and replication workflows.

A remote cluster is identified by an alias (for example dr-site) and configured on the local cluster using dynamic settings under cluster.remote.<alias>.*. In the default sniff mode, the local cluster connects to the remote deployment over the transport interface (typically port 9300) using one or more seed addresses, then discovers additional remote nodes to maintain a pool of transport connections.

Successful connections depend on routing, firewalls, and compatible transport TLS and authentication configuration between clusters. In sniff mode, remote nodes must publish addresses reachable from the local cluster, otherwise discovery and connection attempts fail. Nodes that run CCS/CCR requests must have the remote_cluster_client role (or avoid removing it from node.roles), and skip_unavailable can be used to make a remote cluster optional for searches.

Steps to configure an Elasticsearch remote cluster connection:

  1. Choose a short remote cluster alias using lowercase letters, digits, and hyphens. 
    dr-site

    The alias becomes the prefix for CCS index targets such as dr-site:logs-*.

  2. Collect one or more reachable remote transport seed addresses in the host:9300 format. 
    192.0.2.51:9300
192.0.2.52:9300

    Seeds must point to the remote cluster's transport addresses (not the HTTP port 9200).

    Exposing the transport port to untrusted networks risks cluster compromise; restrict access to trusted networks and known source IPs.

  3. Set the remote cluster seeds in the local cluster persistent settings. 
    $ curl --silent --show-error --header "Content-Type: application/json" --request PUT "http://localhost:9200/_cluster/settings?pretty" --data '{
  "persistent": {
    "cluster.remote.dr-site.seeds": [
      "192.0.2.51:9300",
      "192.0.2.52:9300"
    ]
  }
}'
{
  "acknowledged" : true,
  "persistent" : {
    "cluster" : {
      "remote" : {
        "dr-site" : {
          "seeds" : [
            "192.0.2.51:9300",
            "192.0.2.52:9300"
          ]
        }
      }
    }
  },
  "transient" : { }
}

    For secured clusters, use HTTPS on the API endpoint and add --user plus --cacert (or another trust mechanism) to the curl command.

  4. Enable skip_unavailable to avoid failing cross-cluster search when the remote cluster is offline. 
    $ curl --silent --show-error --header "Content-Type: application/json" --request PUT "http://localhost:9200/_cluster/settings?pretty" --data '{
  "persistent": {
    "cluster.remote.dr-site.skip_unavailable": true
  }
}'
{
  "acknowledged" : true,
  "persistent" : {
    "cluster" : {
      "remote" : {
        "dr-site" : {
          "skip_unavailable" : "true"
        }
      }
    }
  },
  "transient" : { }
}

    Setting skip_unavailable affects cross-cluster search behavior; cross-cluster replication still requires the remote cluster to be reachable.

  5. Verify the remote cluster connection using the /_remote/info endpoint. 
    $ curl --silent --show-error "http://localhost:9200/_remote/info?pretty"
{
  "dr-site" : {
    "seeds" : [
      "192.0.2.51:9300",
      "192.0.2.52:9300"
    ],
    "connected" : true,
    "mode" : "sniff",
    "skip_unavailable" : true,
    "num_nodes_connected" : 2,
    "max_connections_per_cluster" : 3,
    "initial_connect_timeout" : "30s"
  }
}

    If connected is false, confirm firewall access to 9300 and review transport TLS trust and certificate names on both clusters.

  6. Test a cross-cluster search request using the remote cluster alias as an index prefix. 
    $ curl --silent --show-error "http://localhost:9200/dr-site:logs-*/_count?pretty"
{
  "count" : 5,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  }
}

    Replace logs-* with a known index or data stream pattern that exists on the remote cluster.