alien_

How hard would it be to convert it to other more or less related laptop models?

Would it make sense to have a shared component that applies on multiple models, and a smaller part to be model-specific?

The AMI creation is only needed if you store data on the machines, which you shouldn't do anyway, not even with on-demand ones.

You should always try to keep the instances stateless and store any data outside the instances, such as on S3 or EFS.

Now also open source and available on GitHub: https://github.com/cristim/autospotting

The latest version is adding support for EC2 Classic security groups and full-blown launch configuration setups which as of now make it usable enough for environments of real-life complexity.

I've looked in a bit more detail and it seems to attach the nodes to the ELB used by the AutoScaling group, while I am attaching them to the group itself, which indirectly adds them to the load balancer.

I'm curious how does that tool handle the scaling of the group, since the nodes are actually outside the group and can't contribute to group-wide metrics like average CPU usage, often used for scaling out.

I didn't know about that one, indeed, it seems pretty similar.

It's because so far I am only considering replacing the nodes slowly, one at a time, mostly in order not to hit any soft limits that may be defined on the account(like total number of instances), but also in order to give the user the chance to stop it in case things go south for whatever reason during the evaluation, since as I warned, this thing is likely full of bugs at this point.

Yes, but I actually did start a few weeks before the spot fleet was launched.

The problem with the spot fleet 1) it's kind of awkward to use 2) it has statically defined capacity so you can't scale it 3) it has a static bid price, so if at some point your are outbid on all the group's bids, you end up with no capacity 4) among other things it lacks integration with the ELB so you can't really use it for so many use cases.

My solution is simpler, better integrated with the rest of AWS and more resilient and once I iron out the bugs and get it production-ready, it should be a better choice.

With my approach the AutoScaling group would always replace failed instances with the on-demand ones identical to those initially defined on the group's launch configuration.

All I do is I later attempt to replace them with whatever I can buy from the spot market.

On the other hand, the spot bidding implemented out of the box in AutoScaling will fail if you are outbid in all Availability Zones at the same time, since it doesn't fall back to on-demand instances. I've seen people often use a second on-demand AutoScaling group that would scale out when you get outbid on the spot one, but then you have a problem defining scaling policies so that they can scale nicely, and/or shifting the capacity between them. Someone had a nice talk at re:invent about how they do all that.