An OSI layer 4 load balancer configured with a static private IP address on the virtual network, that can be used to round robin requests across Elasticsearch nodes. The private IP address is configured with vNetLoadBalancerIp parameter.

The following settings apply to the internal load balancer

When coordinating nodes are deployed, they are attached to the internal load balancer backend pool. When no coordinating nodes are deployed, the data nodes are attached to the backend pool. The load balancer receives incoming requests on port 9200 and round robins them across the backend pool over port 9200, with a TCP health probe that checks connectivity every 30 seconds, taking nodes out of the backend pool when health probes fail. An idle timeout of 5 minutes is also configured.

When Kibana is deployed, Kibana is configured to communicate with Elasticsearch through the internal load balancer.

An OSI layer 4 load balancer configured with a public IP address that can be used to send requests to Elasticsearch from the public internet.

The following settings are applicable to the external load balancer

When choosing to deploy with an external load balancer, both an internal and external load balancer are deployed; when Kibana is deployed, it will be configured to communicate with Elasticsearch through the internal load balancer. The external load balancer receives incoming requests on port 9200 and round robins them across the backend pool over port 9201, with a TCP health probe that checks connectivity every 30 seconds, taking nodes out of the backend pool when health probes fail. Since both the internal and external load balancer contain the same VMs in their backend pools, the external load balancer communicates with the backend pool over port 9201, to work around a limitation in Azure. On each Elasticsearch node VM, incoming traffic on port 9201 is re-routed to port 9200 using a persistent iptables configuration, and then routed back to 9201 for the outgoing response.

As with the internal load balancer, when coordinating nodes are deployed, they are attached to the external load balancer backend pool. When no coordinating nodes are deployed, data nodes are attached to the backend pool. The load balancer round robins requests across the backend pool over port 9200, with a TCP health probe that checks connectivity every 30 seconds, taking nodes out of the backend pool when health probes fail. An idle timeout of 5 minutes is also configured.

An OSI layer 7 load balancer configured with a dynamically assigned public IP address that can be used to send requests to Elasticsearch from the public internet. Application Gateway can be configured with a certificate to configure SSL/TLS between the client and Application Gateway, performing SSL termination at the gateway. The following parameters are used to configure Application Gateway

When choosing to deploy with Application Gateway, both Application Gateway and an internal load balancer are deployed; the internal load balancer is configured as the backend pool for Application Gateway.

A custom health probe is configured that reports healthy for the backend pool for status codes between 200-399, and for status code 401, which may be returned when Elastic Stack Security is enabled, since the health probe makes requests without any form of authentication.

The public IP address of Application Gateway is not returned in the template outputs, but can be retrieved after successful deployment with

Azure CLI 2.0.

gateway_ip_resource=$(az network public-ip show --name "es-app-gateway-ip" \
  --resource-group "<resource group>")

# jq needs to be installed
gateway_fqdn=$(jq -r .dnsSettings.fqdn <<< $gateway_ip_resource)
gateway_ip="https://${gateway_fqdn}:9200"

Azure PowerShell.

$gatewayIpResource = Get-AzureRmPublicIpAddress -Name "es-app-gateway-ip" `
  -ResourceGroupName "<resource group>"

$gatewayIp = "https://$($gatewayIpResource.DnsSettings.Fqdn):9200"