# AWS Disk Latency Issues **URL:** \ **Category:** Elasticsearch\ **Created:** [September 14, 2016, 7:02am UTC](https://discuss.elastic.co/t/aws-disk-latency-issues/60461 "2016-09-14T07:02:08Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![mgvarley](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mgvarley/32/687_2.png) [@mgvarley](https://discuss.elastic.co/u/mgvarley)\ **Post date:** [September 14, 2016, 7:02am UTC](https://discuss.elastic.co/t/aws-disk-latency-issues/60461/1 "2016-09-14T07:02:08Z")
I have been running Elasticsearch on AWS for some time now, running on 2 x r3.xlarge instances with a t2.small as a tie breaker and have had no issues however the cost of the stack is high and I am looking for ways to optimise and save money. With the recent move to doc values as defaults and less emphasis on memory I have been experimenting with smaller instances and EBS storage rather than expensive instance stores. I first tried with 2 x t2.large each with an 80gb gp2 (default SSD) EBS but after 45 minutes or so of running a large test batch disk latency starts to go crazy and requests start timing out. I then tried with 2 x m4.large using EBS optimised volumes and exactly the same behaviour! Any advice as to what AWS limits I might be hitting and what possible next steps could be would be hugely appreciated. Looking at the cost of provisioned iops I would be better off reverting to the r3s with instance storage. ![](https://us1.discourse-cdn.com/elastic/original/2X/7/7fe88d20272f816fe9b8101db088dfede123d60f.png) ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 10:20pm UTC](https://discuss.elastic.co/t/aws-disk-latency-issues/60461/2 "2017-07-05T22:20:25Z")