Is there a way for an EC2 instance in an autoscaling group to decline a scale-down termination request? I'm in a situation with highly dynamic load...and I don't want to terminate an instance that's in the first part of its charging hour. Even with the autoscale policy losestToNextInstanceHour I see cases where an instance is terminated that has 40 minutes left on its hour...and within that 40 minutes the load increases again.
So, I want my instances to be able to "thanks for asking me to terminate but I decline". Is this possible?
You could change instance protection to "Protect From Scale In" for the instances you want reject scale-in termination. http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/AutoScalingBehavior.InstanceTermination.html#instance-protection
Yes, you can. You can select an instance in Autoscaling group and choose Protect From Scale in.
It can be easily done via AWS Console. Go to ASG then instances then select the instances you want to protect then from actions just above the select box choose the option.
You can also do it via: http://docs.aws.amazon.com/autoscaling/latest/userguide/as-instance-termination.html#instance-protection
You can even edit settings in ASG and change settings according to lifetime of an instance: http://docs.aws.amazon.com/autoscaling/latest/userguide/as-instance-termination.html#custom-termination-policy
Related
I have created ec2 instance and it's part of the auto scaling group and i want to stop this instance so i can save money while this server being not used.Whenever i want to use this server that time i can start the instance.
AutoScaling Group is able to take care of this process for you.
You can change the size of the group manually, or you could schedule custom configurations to scale-up or scale-down as per your needs.
This is all supported through AWS APIs, so you can do this through AWS Console or automating the configuration.
Instances in ASG can't be stopped. If you want to stop one instance you have to detach it from ASG. When you are ready to start it, you can attach it again.
But really, you should reconsider how you use ASG. Detaching and re-attaching instances from ASG is meant for mostly troubleshooting purposes, not something you do regulatory just to save cost. Its better to set minimum and desired capacity of ASG to 0 if you don't want any instance in it.
I'm considering using spot instances in an auto-scaling group. While I'm aware that I'll receive a 'Spot instance interruption notice' if my spot instances are going to get terminated, what is unclear from the documentation is if my auto-scaling group will spin up new on-demand instances to replace these when the notice occurs, or if they only get replaced on termination. I'm aware that I could listen for these notices manually, but it seems like something that an auto-scaling group should be able to handle automatically.
I've tried testing this out on an existing auto-scaling group that had spot instances by changing the launch configurations 'spot price' to be lower than the current price. This did not work as it would only effect new instances and not currently running ones. I'm unsure of how to change an existing spot request's price.
What I'm hoping will happen is that on-demand instances will be spun up in the two minutes I have from the interruption notice till the time of termination.
If the Launch Configuration in your Auto Scaling Group is configured to use Spot instances then the new instance will indeed be a Spot instance.
The situation you describe is one of the challenges of using Spot instances; although the cost is very low, Spot instances can be terminated and the underlying resources used for a paying customer to fulfill an on-demand or Reserved Instance at anytime.
One way to avoid this is to use Reserved Instances. If you have a predictable long-term need for an instance, or are running a production workload, using Reserved instances is an effective way to lower your costs (albeit, not as low as a spot instance) without having to worry that you could lose your instance(s) at anytime.
Regarding changing the price, updates to pricing are applied to new instances only. After updating pricing simply terminate your existing instances and they’ll be replaced by your ASG with instances at the new price.
I have foreseen a problem that could happen with my application but I am unsure if it is possible to solve, and perhaps the architecture needs to be redesigned.
I am using an AutoScalingGroup (ASG) on AWS to create EC2 instances that host game servers that players can join. At the moment, the ASG is scaled manually via a matchmaking API which changes the desired capacity based on its needs. The problem occurs when a game server is finished.
When a game finishes, it signals to the matchmaker that it is finished and needs terminating, and the matchmaker will then scale down the ASG accordingly, however, it doesn't seem to know exactly which instance to remove, and it won't necessarily be the one that needs terminating.
I can terminate the instance, but then as the ASG desired capacity is never changed when the instance is terminated, another server is created.
Is there a way I can scale down the ASG, as well as specifying which servers to remove from the group?
In a nutshell, the default termination policy during scale in is designed to remove instances that use the oldest launch configuration.
Currently, Amazon EC2 Auto Scaling supports the following termination policie:
OldestInstance Terminate the oldest instance in the group. This option is useful when you're upgrading the instances in the Auto Scaling group to a new EC2 instance type. You can gradually replace instances of the old type with instances of the new type.
NewestInstance Terminate the newest instance in the group. This policy is useful when you're testing a new launch configuration but don't want to keep it in production.
OldestLaunchConfiguration Terminate instances that have the oldest launch configuration. This policy is useful when you're updating a group and phasing out the instances from a previous configuration.
ClosestToNextInstanceHour Terminate instances that are closest to the next billing hour. This policy helps you maximize the use of your instances and manage your Amazon EC2 usage costs.
Default Terminate instances according to the default termination policy. This policy is useful when you have more than one scaling policy for the group.
Instance protection
One of the possible solutions could be to use Instance protection. The auto-scaling provides an instance protection to control whether instance can be terminated when scaling-in.
Therefore, enable the instance protection for ASG to protect instances from scaling-in by default. Once you are done with you server, decrease a value of desired number of instances, remove instance protection from particular instance (either using CLI or SDK; note that this protection remains enabled for the rest of instances) and auto-scaling will terminate that exact instance.
For more information about instance protection, see Instance Protection
The oldest server is removed. If you want to scale down a specific server, you will have to kill that server before changing desired capacity.
Is there a way to elegantly Script/Configure Spot instances request, if Spot not available in some specified duration, just use OnDemand. And if Spot instance gets terminated just shift to OnDemand.
Spot Fleet does not do this (it just manages only Spot), EMR fleets have some logic around this. You can have auto scaling with Spot or on Demand not both (even though you can have 2 separate ASGs simulate this behavior).
This should be some kind of a base line use case.
Also does an Event get triggered when a Spot instance is launched or when it is Terminated. I am only seeing CLIs to check Spot status, not any CloudWatch metric/event.
Cloudwatch Instance State events can fire when any event changes states.
They can fire for any event in the lifecycle of an instance:
pending (launching), running (launch complete), shutting-down, stopped, stopping, and terminated, for any instance (or for all instances, which is probably what you want -- just disregard any instance that isn't of interest), and this includes both on-demand and spot.
http://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#ec2_event_type
http://docs.aws.amazon.com/AmazonCloudWatch/latest/events/LogEC2InstanceState.html
You could use this to roll your own solution -- there's not a built in mechanism for marshaling mixed fleets.
I used to do this from the ELB with health checks. You can make two groups, one with spot instances and one with reserved or on demand. Create a CW alarm when spot group contains zero healthy hosts, and scale up the other group when it fires. And the other way around, when it has enough healthy hosts scale down the other group. Use 30 sec health checks on alarm you use to scale up and 30-60 minute cooldown on scale down.
There is also Spotml which allows you to always keep a spotInstance or an onDemand instance up and running.
In addition to simply spawning the instance it also allows you to
Preserve data via persistent storage
And configure a startup script each time a new instance is spawned.
Disclosure: I'm also the creator of SpotML, it's primarily useful for ML/DataScience workflows that can largely just run on spot instances.
I'm looking for a way to temporarily disable an existing AWS auto-scaling group without deleting/recreating the group, or its triggers.
"Disabling" meaning: prevent any instance creation or deletion for a short period of time without wiping the whole related configuration.
Our current release process creates and configure new EC2 instance and inject them in our ELB once ready. It also remove old instances and stop them. For a very short time, the ELB contains twice the usual amount of EC2 instances.
This amount may exceed MAX instance count in the ELB for a very short duration. During this process, we'd like to prevent the auto-scaling group from terminating random supernumerary instances.
I could not find any « disable » option in amazon console.
It may not match auto-scaling group philosophy. Did I missed something ?
Is there a tool for that through amazon command line tools or boto framework ?
In the autoscaling lingo, what you are asking about is suspending processes. In a nutshell each of the autoscaling activities (launch, terminate etc.) can be disabled for as long as you want.
It doesn't look you can set this from the web console (although it does display what processes are available), so you'll either have to use the api or the command line tools
From the cli that's just
aws autoscaling suspend-processes --auto-scaling-group-name MyGroup
and later on
aws autoscaling resume-processes --auto-scaling-group-name MyGroup
You can pass specific processes to suspend resume as extra arguments, but you probably don't need to do that.
Not the best way to do things, but works if you do not have CLI access at the moment.
to use the web console to remove all instances from an aws scaling group: Set max. instances, min. instances, and desired instances to 0;
You can make the MAX instance = 3 and MIN instance = 3 i.e. Specifying the same instance count for both min and max.
This way there shouldn't be any change in the instance count no matter what your rules are.
Set your Desired Capacity Min and Max to 0. Save. Check on Activity History and you'll see the instances being terminated.
You can also remove the Default option in Termination policies and then stop your instance so that it doesnt pop up a new instamnce when you stop your instance and you can make necessary changes to it
From horse's mouth...thanks to wonderful aws documentation here
I'm coping all the steps here just in case if the url changes:
Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/,
and choose Auto Scaling Groups from the navigation pane.
Select the check box next to the Auto Scaling group.
A split pane opens up in the bottom of the Auto Scaling groups page.
On the Details tab, choose Advanced configurations, Edit.
For Suspended processes, choose the process to suspend.
Choose Update.