2 ms·
One issue that we had in the past was the following - hope this is resolved now. Say you have an autoscaling group spanned across zones A and B, and say you h
by ecesena 11y ago
One issue that we had in the past was the following - hope this is resolved now.
Say you have an autoscaling group spanned across zones A and B, and say you have 1 machine in zone A and 1 in machine B.
Now, the price in zone A goes up, and your machine in zone A dies.
The issue (bug?) was that the autoscaling group was trying to re-instantiate a new VM in zone A. Of course, since the price was high, the new VM was basically immediately dying. And so on.
Edit: issue apart, it's a great way that can save money, especially if you have a group of VMs whose computation can be interrupted/restarted relatively cheaply.
- samlin86 11y agoI agree that was an annoying issue. They've recently changed it though, such that it will retarget unfulfilled bids for spot instances in a different zone in order to reach your desired capacity. Win! See: https://forums.aws.amazon.com/ann.jspa?annID=3647 https://forums.aws.amazon.com/ann.jspa?annID=3647
- alien_ 11y agoWith 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.