Custom endpoint aliases | Elasticsearch Service Documentation

› ›

« Managing plugins and extensions through the API Edit your user settings »

Custom endpoint aliasesedit

Custom aliases for your deployment endpoints on Elasticsearch Service allow you to have predictable, human-readable URLs that can be shared easily. An alias is unique to only one deployment within a region.

Create a custom endpoint alias for a deploymentedit

New deployments are assigned a default alias derived from the deployment name. This alias can be modified later, if needed.

To add an alias to an existing deployment:

From the Deployments menu, select a deployment.
Under Custom endpoint alias, select Edit.
Define a new alias. Make sure you choose something meaningful to you.

Make the alias as unique as possible to avoid collisions. Aliases might have been already claimed by other users for deployments in the region.
Select Update alias.

Remove a custom endpoint aliasedit

To remove an alias from your deployment, or if you want to re-assign an alias to another deployment, follow these steps:

From the Deployments menu, select a deployment.
Under Custom endpoint alias, select Edit.
Remove the text from the Custom endpoint alias text box.
Select Update alias.

After removing an alias, your oranisation’s account will hold a claim on it for 30 days. After that period, other users can re-use this alias.

Using the custom endpoint URLedit

To use your new custom endpoint URL to access your Elastic products, note that each has its own alias to use in place of the default application UUID. For example, if you configured the custom endpoint alias for your deployment to be test-alias, the corresponding alias for the Elasticsearch cluster in that deployment is test-alias.es.

You can get the application-specific custom endpoint alias by selecting Copy endpoint for that product. It should contain a subdomain for each application type, for example es, kb, apm, or ent.

With the REST Clientedit

As part of the host name:

After configuring your custom endpoint alias, select Copy endpoint on the deployment overview page, which gives you the fully qualified custom endpoint URL for that product.
As an HTTP request header:

Alternatively, you can reach your application by passing the application-specific custom endpoint alias, for example, test-alias.es, as the value for the X-Found-Cluster HTTP header.

With the `TransportClient`edit

While the TransportClient is deprecated, your custom endpoint aliases still work with it. Similar to the REST Client, there are two ways to use your custom endpoint alias with the TransportClient:

As part of the host name:

Similar to HTTP, you can find the fully qualified host on the deployment overview page by selecting Copy endpoint next to Elasticsearch. Make sure to remove the unnecessary https:// prefix as well as the trailing HTTP port.

As part of the Settings:

Include the application-specific custom endpoint alias as the value for request.headers.X-Found-Cluster setting in place of the clusterId:

// Build the settings for our client.
String alias = "test-alias.es"; // Your application-specific custom endpoint alias here
String region = "us-east-1"; // Your region here
boolean enableSsl = true;

Settings settings = Settings.settingsBuilder()
    .put("transport.ping_schedule", "5s")
    //.put("transport.sniff", false) // Disabled by default and *must* be disabled.
    .put("action.bulk.compress", false)
    .put("shield.transport.ssl", enableSsl)
    .put("request.headers.X-Found-Cluster", alias)
    .put("shield.user", "username:password") // your shield username and password
    .build();

String hostname = alias + "." + region + ".aws.found.io";
// Instantiate a TransportClient and add the cluster to the list of addresses to connect to.
// Only port 9343 (SSL-encrypted) is currently supported.
Client client = TransportClient.builder()
        .addPlugin(ShieldPlugin.class)
        .settings(settings)
        .build()
        .addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName(hostname), 9343));

For more information on configuring the TransportClient, see

Create a custom domain with NGINXedit

If you don’t get the level of domain customization you’re looking for by using the custom endpoint aliases, you might consider creating a CNAME record that points to your Elastic Cloud endpoints. However, that can lead to some issues. Instead, setting up your own proxy could provide the desired level of customization.

The setup described in the following sections is not supported by Elastic, and if your proxy cannot connect to the endpoint, but curl can, we may not be able to help.

Avoid creating CNAMEsedit

To achieve a fully custom domain, you can add a CNAME that points to your Elastic Cloud endpoint. However, this will lead to invalid certificate errors, and moreover, may simply not work. Your Elastic Cloud endpoints already point to a proxy internal to Elastic Cloud, which may not resolve your configured CNAME in the desired way.

So what to do, instead?

Setting up a proxyedit

Here we’ll show you an example of proxying with NGINX, but this can be extrapolated to HAProxy or some other proxy server.

You need to set proxy_pass and proxy_set_header, and include the X-Found-Cluster header with the cluster’s UUID. You can get the cluster ID by clicking the Copy cluster ID link on your deployment’s main page.

server {
    listen 443 ssl;
    server_name elasticsearch.example.com;

    include /etc/nginx/tls.conf;

    location / {
        proxy_pass        https://<UUID>.eu-west-1.aws.elastic-cloud.com/;
        proxy_set_header  X-Found-Cluster <UUID>;
    }
}

This should work for all of your applications, not just Elasticsearch. To set it up for Kibana, for example, you can select Copy cluster ID next to Kibana on your deployment’s main page to get the correct UUID.

Doing this for Kibana or Enterprise Search would not work with Cloud SSO.

To configure `tls.conf in this example, check out https://ssl-config.mozilla.org/ for more fields.