# Uneven load onto data nodes in different AWS Availability Zones

**URL:** <https://discuss.elastic.co/t/uneven-load-onto-data-nodes-in-different-aws-availability-zones/208861>\
**Category:** Elasticsearch\
**Created:** [November 21, 2019, 10:52am UTC](https://discuss.elastic.co/t/uneven-load-onto-data-nodes-in-different-aws-availability-zones/208861 "2019-11-21T10:52:10Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![a06ced31bae02498a46d](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/a06ced31bae02498a46d/32/58087_2.png) [@a06ced31bae02498a46d](https://discuss.elastic.co/u/a06ced31bae02498a46d)\
**Post date:** [November 21, 2019, 10:52am UTC](https://discuss.elastic.co/t/uneven-load-onto-data-nodes-in-different-aws-availability-zones/208861/1 "2019-11-21T10:52:11Z")

</div>

We have data nodes in 3 different AWS AZs (availability zone), we have 3 separate coordinator nodes.  
We noticed that data nodes in one of the AZ experience less load then the nodes in the other 2 AZs.  
It turned out that one of the coordinator nodes was in the wrong AZ – it was in the availability zone in which cluster has no data nodes at all.

In other words, we had data nodes in A, B, C zones and had 3 coordinator nodes in A, B, D but not in C. This resulted in data nodes in zone "C" to receive less load: lower CPU usage, etc.

When we replaced a coordinator node in AZ D with a node in AZ C load became balanced.

Our coordinator nodes are behind an ELB and ELB metrics show all 3 coordinator nodes were receiving same amount of requests.

We have AWS zone awareness plugin enabled which makes sure no primary and replica of any shard are in the same AZ.  
We have 40 nodes in the cluster and every index has exactly 40 shards (20 primary and 20 replicas) – hence are shard distribution across the nodes is perfectly even.  
The ElasticSearch version is 6.8.

Is there anything that would make a coordinator node to "prefer" data nodes in the same zone and avoid routing requests to the data nodes in different AZs?

NOTE: We don't have an adaptive replica selection feature enabled.

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [November 21, 2019, 12:02pm UTC](https://discuss.elastic.co/t/uneven-load-onto-data-nodes-in-different-aws-availability-zones/208861/2 "2019-11-21T12:02:40Z")

</div>

> [@a06ced31bae02498a46d](#):
>
> Is there anything that would make a coordinator node to "prefer" data nodes in the same zone and avoid routing requests to the data nodes in different AZs?

Yes, [allocation awareness does that](https://www.elastic.co/guide/en/elasticsearch/reference/current/allocation-awareness.html#allocation-awareness):

> Elasticsearch prefers using shards in the same location (with the same awareness attribute values) to process search or GET requests. Using local shards is usually faster than crossing rack or zone boundaries.

That's true of all versions released today, but [it won't in 8.0.0](https://github.com/elastic/elasticsearch/pull/45735) and [in 7.5.0 there is a system property to disable this behaviour](https://github.com/elastic/elasticsearch/pull/46375) too.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [December 19, 2019, 12:02pm UTC](https://discuss.elastic.co/t/uneven-load-onto-data-nodes-in-different-aws-availability-zones/208861/3 "2019-12-19T12:02:44Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.