# Possible to have Elasticsearch prefer same availability zone shard allocation? **URL:** \ **Category:** Elasticsearch\ **Created:** [May 25, 2025, 2:08pm UTC](https://discuss.elastic.co/t/possible-to-have-elasticsearch-prefer-same-availability-zone-shard-allocation/378504 "2025-05-25T14:08:58Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![BenB196](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/benb196/32/83401_2.png) [@BenB196](https://discuss.elastic.co/u/BenB196)\ **Post date:** [May 25, 2025, 2:08pm UTC](https://discuss.elastic.co/t/possible-to-have-elasticsearch-prefer-same-availability-zone-shard-allocation/378504/1 "2025-05-25T14:08:58Z")
Hi All, I'm curious if anyone knows if the following scenario is possible within Elasticsearch. Suppose I have a 6-node cluster spread across 3 availability zones (AZ) (2 nodes per AZ). I want to have _some_ resiliency, but my use-case doesn't require a significant amount and focuses more on cost savings. In this case, I want to minimize the amount of cross-AZ traffic (cost) that would happen. I'd like to be able to tell Elasticsearch that when it schedules an index/shards, to keep the primary and replica shard in the same AZ if _possible_, but don't allocate on the same node. If _not possible_, then try to allocate across AZs, but when possible again, to move the shards back to the same AZ. I've looked at the following doc areas, but couldn't really find anything that would indicate this is possible: - [Shard allocation awareness | Elastic Docs](https://www.elastic.co/docs/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/shard-allocation-awareness) - [Cluster-level shard allocation and routing settings | Elastic Documentation](https://www.elastic.co/docs/reference/elasticsearch/configuration-reference/cluster-level-shard-allocation-routing-settings) - [Index-level shard allocation | Elastic Docs](https://www.elastic.co/docs/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/index-level-shard-allocation) ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [May 25, 2025, 2:18pm UTC](https://discuss.elastic.co/t/possible-to-have-elasticsearch-prefer-same-availability-zone-shard-allocation/378504/2 "2025-05-25T14:18:53Z")
I believe what you are asking for is indeed not possible but wanted to add a comment as well. > [@BenB196](#): > > I'd like to be able to tell Elasticsearch that when it schedules an index/shards, to keep the primary and replica shard in the same AZ if _possible_ If you were able to do this you would end up with both primary and replica in the same AZ. This gives you protection and resiliency against node-level failures but you would lose part of your data if a full AZ fails. If node-level failure resiliency is sufficient or a viable tradeoff, why not simply deploy all nodes in a single AZ? You could still use reasoinably frequent snapshots to ensure you could restore the cluster with limited data loss if you lost the full AZ. ---
**Author:** ![Rafa\_Silva](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rafa_silva/32/147814_2.png) [@Rafa\_Silva](https://discuss.elastic.co/u/Rafa_Silva)\ **Post date:** [May 25, 2025, 10:37pm UTC](https://discuss.elastic.co/t/possible-to-have-elasticsearch-prefer-same-availability-zone-shard-allocation/378504/3 "2025-05-25T22:37:04Z")
Interesting use case — unfortunately, Elasticsearch doesn’t support “prefer same AZ” for primaries and replicas out of the box. With allocation awareness, it actually tries to spread them across AZs for resilience. If you want both shards in the same AZ, you’d need to avoid awareness and use index-level allocation filtering — but that gets manual fast. Would be great if Elastic added soft preferences like this in the future.