Support AutoSpotting use cases

[cristim]

This looks like a neat library, and I'm planning to try it on https://github.com/AutoSpotting/AutoSpotting looking into hopefully replacing our current custom compatibility logic.

We have a bunch of additional features I mentioned below, I'd love to see at least some of these implemented in this library, so I can hopefully reduce or even entirely replace my custom logic:

• uses an instance ID(assumed to be from the current region) as comparison baseline instead of the region-agnostic instance type supported currently
• considers actually used resources on the baseline running instance instead of the maximum available in the specs, for example currently we consider the attached instance store volumes in the block device mapping not the total available, but there may be others.
• consider spot pricing of the target instance type, returning the better-priced compatible spot instance type in the same region or AZ(would be nice to be configurable between Region and AZ).
• sorts the result in increased order of the spot price.
• efficient when it comes to API calls and network traffic by storing a lot of static data(having some of it cached for a day or so may be acceptable though).

If you think this makes sense to be implemented in this project, I'll create more granular issues for all these pieces of functionality so we can discuss each of them in more detail.

[bwagner5]

Hey @cristim thanks for opening this issue! I definitely think there is room for further discussion on most of these, feel free to create separate issues for them.

• uses an instance ID(assumed to be from the current region) as comparison baseline instead of the region-agnostic instance type supported currently

• considers actually used resources on the baseline running instance instead of the maximum available in the specs, for example currently we consider the attached instance store volumes in the block device mapping not the total available, but there may be others.

It seems to me that these two would have to go together to make this useful. I don't think just allowing instance-id as the base would be useful since it would basically just look up the instance type and then pass that into instance-selector. If instance-selector does lookup actual resource usage, then that might make sense.

• consider spot pricing of the target instance type, returning the better-priced compatible spot instance type in the same region or AZ(would be nice to be configurable between Region and AZ).
• sorts the result in increased order of the spot price.

These also seem related, but since spot prices change and there is already features in ASG to handle dynamic pricing (lowest-price allocation strategy and spot max price), I don't quite see the need of figuring out which one is cheaper. It would be better to pass all compatible instance types into the launch template and then let ASG figure out which one to use based on the configuration of max-price or the allocation strategy.

The sorting part seems related to this issue as well: #21

• efficient when it comes to API calls and network traffic by storing a lot of static data(having some of it cached for a day or so may be acceptable though).

Yeah, this data would be easily cached since it doesn't change very often. It hasn't made sense so far in the project since this tool is usually executed in an ad-hoc manner, so the next run would usually require the cache to be evicted anyways to account for potentially new instance types. But I can see the usefulness if you want to run this for a bunch of workloads within an account as a system component.