Problem
All three private connectivity pages tell readers that only ports 443 and 9243 are supported into an Elastic Cloud Hosted deployment over a private connection. Remote cluster traffic for cross-cluster search and cross-cluster replication uses port 9400 with the TLS certificate based security model, or 9443 with the API key based model. That path is supported when the local cluster runs in your own VPC or VNet. None of the three pages mention it.
This contradicts Remote clusters, which already documents the path as supported:
| Local cluster location |
Remote cluster |
Connection path |
Private connectivity applicable? |
| Self-managed or Elastic Cloud Enterprise cluster in your VPC or VNet |
Elastic Cloud Hosted deployment |
Public proxy address, or a private connection: create a VPC Endpoint (AWS), Private Endpoint (Azure), or Private Service Connect endpoint (GCP) and connect to the remote cluster through it. |
Yes (in this direction only). |
and states:
remote clusters with API key–based authentication use port 9443 by default
So the remote clusters page is correct and the private connectivity setup pages are behind it. A reader who starts from the setup pages, which is the natural entry point when configuring a private endpoint, has no way to learn that the remote cluster ports are usable.
Affected locations
The AWS page carries a more serious instance, because this one drives configuration rather than just describing it:
The security group for the endpoint should, at minimum, allow for inbound connectivity from your instances' CIDR range on ports 443 and 9243. Security groups for the instances should allow for outbound connectivity to the endpoint on ports 443 and 9243.
A reader who follows that builds a security group which silently drops remote cluster traffic. This is not only an omission, it is guidance that produces a broken configuration and a failure that is hard to diagnose from the client side.
Suggested wording
For the port notes on all three pages:
Elastic Cloud Hosted supports ports 443 and 9243 for Elasticsearch and Kibana traffic. Remote cluster traffic for cross-cluster search and cross-cluster replication uses port 9400 with the TLS certificate based security model, or 9443 with the API key based model. Refer to Connection paths and private connectivity for the supported combinations.
For the AWS security group paragraph, add a sentence:
If you use this endpoint for remote cluster traffic, also allow port 9400 or 9443, depending on the security model you configure.
Please leave the Serverless notes as they are
The neighbouring Serverless notes ("Elastic Cloud Serverless supports port 443") are correct and should stay. Remote clusters are not available in Elastic Cloud Serverless; cross-project search is the equivalent and does not require remote cluster configuration. Flagging so they don't get changed for symmetry.
One dependency
The Azure wording is pending internal confirmation that 9443 is reachable over Azure Private Link (tracked internally at elastic/ecp-traffic-team#2941). AWS and GCP can go ahead now. I'll confirm the Azure detail here once I have it, so please treat the Azure page as a follow-up rather than blocking the other two.
Origin
A customer attempted cross-cluster search from an Elastic Cloud on Kubernetes cluster into an Elastic Cloud Hosted deployment over a private connection, and it failed. Neither the customer nor support could determine from these pages whether the path was supported at all.
Problem
All three private connectivity pages tell readers that only ports
443and9243are supported into an Elastic Cloud Hosted deployment over a private connection. Remote cluster traffic for cross-cluster search and cross-cluster replication uses port9400with the TLS certificate based security model, or9443with the API key based model. That path is supported when the local cluster runs in your own VPC or VNet. None of the three pages mention it.This contradicts Remote clusters, which already documents the path as supported:
and states:
So the remote clusters page is correct and the private connectivity setup pages are behind it. A reader who starts from the setup pages, which is the natural entry point when configuring a private endpoint, has no way to learn that the remote cluster ports are usable.
Affected locations
The AWS page carries a more serious instance, because this one drives configuration rather than just describing it:
A reader who follows that builds a security group which silently drops remote cluster traffic. This is not only an omission, it is guidance that produces a broken configuration and a failure that is hard to diagnose from the client side.
Suggested wording
For the port notes on all three pages:
For the AWS security group paragraph, add a sentence:
Please leave the Serverless notes as they are
The neighbouring Serverless notes ("Elastic Cloud Serverless supports port 443") are correct and should stay. Remote clusters are not available in Elastic Cloud Serverless; cross-project search is the equivalent and does not require remote cluster configuration. Flagging so they don't get changed for symmetry.
One dependency
The Azure wording is pending internal confirmation that
9443is reachable over Azure Private Link (tracked internally atelastic/ecp-traffic-team#2941). AWS and GCP can go ahead now. I'll confirm the Azure detail here once I have it, so please treat the Azure page as a follow-up rather than blocking the other two.Origin
A customer attempted cross-cluster search from an Elastic Cloud on Kubernetes cluster into an Elastic Cloud Hosted deployment over a private connection, and it failed. Neither the customer nor support could determine from these pages whether the path was supported at all.