Hi Brandon, this is just with test data, so only 5000 documents, spanned over the 5 years, so maybe 1 or 2 documents per month. We've pushed in 100k documents over the same number of shards and confirmed that the times don't really increase with volume of documents, only volume of shards.
We've scaled up on aws to double the number of cores, and confirmed that increases performance by a factor of 2, sometimes over 2. So that is an option for us. We also can combine the number of indexes. We are creating an index per month per document type (we have around 30 types with different properties), per year. I dont see any reason why we couldn't drop the month out, reducing the number of shards by a factor of 12. I think creating index patterns for each year would be a pain atm because Kibana doesn't make it easy to switch index pattern for the visualisations.
Some of this may become a non issue if our clients don't need 5 years of data, we don't know yet so are working on worst case possibility for our performance tests. But given that we all know if you ask a client how long you want to keep data for, they will always say forever 
. I've designed everything around hot/warm architecture, but currently only have a need for the hot, but potentially we are already setup to move older data to smaller nodes (xpack costs may make this impossible, we are 3 node platinum holders).
thank you for your help thus far. I do hope these niggles get ironed out in some respect in the product over the next few versions. I know 7 is in development. So many people have asked similar questions as this over the years so Im sure the team are aware of these limitations.