Investigate weighting of instance types

[cristim]

This may allow us to replace a number of smaller instances with a single bigger instance, as long as the price is proportionally lower.

Also depends on #5

[xlr-8]

Could we discuss what would be the use case?

Considering that the algorithm currently tries to get the most powerful instance for the lowest price, I have trouble to think about when using it. Would it be to try to save some more, for something more powerful anyway?

[cristim]

It's all about minimizing the price per desired unit of capacity.

All the prices mentioned below are fictional examples assumed to be stable for a relatively long period of time.

Let's say you run on c3.large on-demand instances and the application is CPU-intensive like many tend to be

• The c3.large is usually around $0.1/hour on the spot market but the current price is 0.5 and you need to replace that on-demand instance now.
• At this time the almost identical c4.large is the cheapest and it costs 0.18
• The c3.xlarge that has 2x capacity costs 0.2.

The algorithm would currently give you the less powerful c4.large instead of the c3.xlarge which costs just slightly more but is twice as powerful.

This feature would allow the user to divide the cost by the number of CPU cores of the candidate spot instance type so that would launch a larger instance that costs least per CPU core.

The algorithm would need to be configurable to allow the user to specify which unit of capacity is more important for the application (CPU, memory, maybe instance store disk, etc. but CPU and memory are good for a start) and based on that to select the instance type that optimizes for more capacity for the least cost.

As usual, that value should be passed as a tag set on each group, and when absent the algorithm should behave as it does now. We may also have it configurable at the stack level, although that could be done later.