# ELK architecture advice with S3

**URL:** <https://discuss.elastic.co/t/elk-architecture-advice-with-s3/69236>\
**Category:** Elasticsearch\
**Created:** [December 16, 2016, 5:31am UTC](https://discuss.elastic.co/t/elk-architecture-advice-with-s3/69236 "2016-12-16T05:31:38Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![Mark\_Harwood](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood/32/10538_2.png) [@Mark\_Harwood](https://discuss.elastic.co/u/Mark_Harwood)\
**Post date:** [December 19, 2016, 11:41am UTC](https://discuss.elastic.co/t/elk-architecture-advice-with-s3/69236/3 "2016-12-19T11:41:19Z")

</div>

On the masters front: the answer is always " **3 dedicated** master nodes" and anything else is an architectural compromise. The rationale for this is :

**Dedicated** because asking a master node to also perform indexing or searching duties can put it under stress. A master node must perform an important (but lightweight) managerial function so shouldn't be stressed by data loads in the same way you do with data nodes or [clusters can become unresponsive](https://discuss.elastic.co/t/an-error-while-bulk-indexing/69404)  
**3** because 1 represents a single-point-of-failure and 2 has the potential for split-brain.

Of course not everyone builds a cluster using 3 dedicated master nodes but it is important to know the trade-offs you're making when you stray from this advice.

---

_[View the full topic](https://discuss.elastic.co/t/elk-architecture-advice-with-s3/69236)._