Spot instances are unstable by design, and can go down any time. However, in practice I have seen very few terminations. My longest uptime has been above 300 days (in region eu-west-1)
In my experience, at least on us-east-1, I’ve seen multiple spot instances get terminated every day, with “no capacity” errors when trying to submit new spot requests, so YMMV.
True, I’ve seen more terminations in other regions/for other instance types. However, even with a daily termination, this would mean ~5 minutes of downtime (as a new instance boots up) which for many personal projects should be sufficient. The key is to specify as many instance types as possible.
Can confirm this as well (at least for us-east-1). We use to use spot instances for builds, and even though the builds were roughly 10-15 minutes, there were cases of intermittent spot instance termination.
Easier to just eat the cost of on-demand in my experience. Maybe it is region specific.
This is an impressive saving! $2.50/month is two thirds of what even Hetzner would charge (though you would get a slightly better VM there).
You haven’t found that terminations are very common though I suspect that they’re the sort of thing that wouldn’t happen for ages and then you’d get a month with lots of terminations and so lowish uptime.
I don’t know, I run a few projects on Hetzner 3€ or Scaleway 3€ machines and unless you really need the cpu/ram to have (a) dedicated machine(s) per project, I feel this sounds like an overcomplicated solution. I guess that’s a moot point if you’re actually using not-micro instances.
Yes I’m not about to do this myself because the saving wouldn’t be worth it for me (I also use Hetzner) but I suppose I just appreciate the ingenuity! Honestly anything that gets people talking about how much people overpay to rent computers is gods work in my view. Might as well link my own blog post while I’m on about it: https://calpaterson.com/amazon-premium.html
$2.50/month is the price of a vultr instance with 1 vCPU, 512 MiB of RAM and 10 GB of SSD disk. That’s sufficient for a bunch of low-volume hosting things. It’s an extra $1/month for an IPv4 address, but if you’re building a load of microservices then you can probably get away with a single front-end machine and the others on v6-only networks.
See Root Volume persistence section. They create an ami based on your root image (plus root volume snapshots). That’s not to say you shouldn’t have backups, using something like litestream, mysql-backup, etc.
At least for Azure, you have a choice of VMs being destroyed or deallocated. If they’re deallocated, the disks persist (and you keep paying for them) and you can redeploy the VM. You can opt in to a notification that lets you do a graceful shutdown, as long as you can do so within 30 seconds. I’m tempted to try one of the 72-core machines for package building and have it throw the built packages at an NFS share from a file storage thing and use the local SSD (which is thrown away if the VM is deallocated) for all intermediate build products.
More and more I see the trend to move toward cloud container(not VM) workspace with a well integrated IDE (including VCS, CI, CD integration).
Your stateful data can stay on a set of container volumes or a container image layer. The workspace is composable and reproducable which is great for testing environment.
I save myself the headache and run my things on hetzner cloud and scaleway, which are both cheap, have excellent hardware and no crazy traffic prices.
In my experience, at least on us-east-1, I’ve seen multiple spot instances get terminated every day, with “no capacity” errors when trying to submit new spot requests, so YMMV.
True, I’ve seen more terminations in other regions/for other instance types. However, even with a daily termination, this would mean ~5 minutes of downtime (as a new instance boots up) which for many personal projects should be sufficient. The key is to specify as many instance types as possible.
Can confirm this as well (at least for us-east-1). We use to use spot instances for builds, and even though the builds were roughly 10-15 minutes, there were cases of intermittent spot instance termination.
Easier to just eat the cost of on-demand in my experience. Maybe it is region specific.
This is an impressive saving! $2.50/month is two thirds of what even Hetzner would charge (though you would get a slightly better VM there).
You haven’t found that terminations are very common though I suspect that they’re the sort of thing that wouldn’t happen for ages and then you’d get a month with lots of terminations and so lowish uptime.
I don’t know, I run a few projects on Hetzner 3€ or Scaleway 3€ machines and unless you really need the cpu/ram to have (a) dedicated machine(s) per project, I feel this sounds like an overcomplicated solution. I guess that’s a moot point if you’re actually using not-micro instances.
Yes I’m not about to do this myself because the saving wouldn’t be worth it for me (I also use Hetzner) but I suppose I just appreciate the ingenuity! Honestly anything that gets people talking about how much people overpay to rent computers is gods work in my view. Might as well link my own blog post while I’m on about it: https://calpaterson.com/amazon-premium.html
I added a clarification in the post about instance type scores and an option to fall back to on-demand until scores improve.
$2.50/month is the price of a vultr instance with 1 vCPU, 512 MiB of RAM and 10 GB of SSD disk. That’s sufficient for a bunch of low-volume hosting things. It’s an extra $1/month for an IPv4 address, but if you’re building a load of microservices then you can probably get away with a single front-end machine and the others on v6-only networks.
Won’t you lose your root image, though, if spot.io makes a bad prediction?
See Root Volume persistence section. They create an ami based on your root image (plus root volume snapshots). That’s not to say you shouldn’t have backups, using something like litestream, mysql-backup, etc.
I read that, but my assumption was they did that on migration, but maybe I misunderstood and they do it regularly?
It seems to be both
At least for Azure, you have a choice of VMs being destroyed or deallocated. If they’re deallocated, the disks persist (and you keep paying for them) and you can redeploy the VM. You can opt in to a notification that lets you do a graceful shutdown, as long as you can do so within 30 seconds. I’m tempted to try one of the 72-core machines for package building and have it throw the built packages at an NFS share from a file storage thing and use the local SSD (which is thrown away if the VM is deallocated) for all intermediate build products.
I believe spot.io supports Azure and other providers, but I haven’t tried it myself.
More and more I see the trend to move toward cloud container(not VM) workspace with a well integrated IDE (including VCS, CI, CD integration).
Your stateful data can stay on a set of container volumes or a container image layer. The workspace is composable and reproducable which is great for testing environment.