What is the Cloud ID in Elastic Cloud, and how do clients use it to connect?

## What the Cloud ID is When you create a hosted deployment in Elastic Cloud, the console shows a **Cloud ID** next to the endpoint URLs. It is a compact way of saying "here is where this deployment lives" in a single string that can be pasted into a client configuration file, instead of separate Elasticsearch and Kibana URLs. Structurally it is two parts joined by a colon: a label (the deployment name you chose, used only for readability) and a base64-encoded payload. Decoding the payload yields the deployment's DNS suffix plus identifiers for the individual components — the Elasticsearch endpoint and the Kibana endpoint. A client that understands the format reconstructs `https://<es-id>.<host>` and connects over TLS. ## How clients consume it Elastic's official language clients expose a `cloud_id` constructor argument. Beats accept `cloud.id` together with `cloud.auth`. The Logstash Elasticsearch output accepts `cloud_id` and `cloud_auth`. In every case the setting replaces the hosts/URL setting — you do not supply both. The practical benefit is that a fleet of shippers can be configured from one string plus one credential, and the string does not change if the underlying instances are replaced, because it names the deployment's stable endpoint rather than any individual node. That matters on a managed service where nodes come and go: you never point a client at a node address. ## What it is not Three misreadings show up constantly. First, **it is not a credential**. Anyone holding a Cloud ID knows where your cluster is, which is roughly the same as knowing its URL. Authentication is separate: an API key, or the `elastic` superuser / a role-scoped user. Store the credential in a secret manager; the Cloud ID itself can sit in config. Second, **it is not a private network path**. A hosted deployment's endpoint is reachable from the internet unless you restrict it — Elastic Cloud offers traffic filters (IP allow-lists and cloud-provider private-link connectivity) for that. The Cloud ID neither grants nor removes network reachability. Third, **it is not universally understood**. `curl`, a browser, or a third-party client that has never heard of Elastic Cloud needs the actual URL. If you need it, base64-decode the second half and read the host out, or simply copy the endpoint from the console — the console shows both. ## Authentication that pairs with it For anything but a throwaway experiment, pair the Cloud ID with an **API key** rather than the `elastic` superuser. An API key can be scoped to specific indices and privileges and revoked independently, which is what you want in a shipper running on many hosts. Beats and Logstash accept an API key in place of `user:password`; language clients take an `api_key` argument next to `cloud_id`. ## Troubleshooting If a client using a Cloud ID fails to connect, work through the layers in order. A malformed or truncated string usually fails at parse time with a client-side error before any network call — that is a copy/paste problem. A TLS or DNS error means the endpoint resolves but the network is blocked, typically a traffic filter or an egress firewall. A 401 means the ID resolved fine and the credentials are wrong or revoked. A 403 means the credentials are valid but the API key lacks the privilege for the index it is writing to. Distinguishing these four is the whole diagnostic skill here, and interviewers who ask about the Cloud ID at all are usually probing whether you understand that endpoint configuration and authentication are separate concerns. ## When you would not use it Self-managed clusters have no Cloud ID — there is no console minting one — so code that is meant to run against both a local development cluster and a hosted deployment normally takes a URL and falls back to the Cloud ID path only when the environment supplies it. Keeping both options in the configuration surface is a small amount of work that avoids branching client code later.