Shard Optimization - Size vs. Count

For many use cases there is no real reason to store data in indices that cover a specific set time period. A good solution to your problem could be to use ILM and rollover. When you use rollover you can set the maximum size and age of primary shards and have Elasticsearch create a new index behind the scenes when either limit is breached. You could make the larger index have e.g. 7 primary shards and set the max age to 1 month and the max size to 40GB. The smaller index could have the same settings. This would leave you with 28 shards to index into which should spread out well across the cluster. The generated indices will rollover at different points in time and cover different time periods, but you would be able to control the shard size and count well.