I use 1 spot instance and would like to be emailed when prices for my instance size and region are above a threshold. I can then take appropriate action and shut down and move instance to another region if needed. Any ideas on how to be alerted to the prices?
There's two ways to go about this that I can think of:
1) Since you only have one instance, you could set a CloudWatch alarm for your instance in a region that will notify you when the spot price rises above what you're willing to pay hourly.
If you create an Alarm, and tell it to use the EstimatedCharges metric for the AmazonEC2 service, and choose a period of an hour, then you are basically telling CloudWatch to send you an email whenever the hourly spot price for your instance in the region it's running in is above your threshold for wanting to pay.
Once you get the email, you can then shut the instance down and start one up in another region, and leave it running with its own alarm.
2) You could automate the whole process with a client program that polls for changes in the spot price for your instance size in your desired regions.
This has the advantage that you could go one step further and use the same program to trigger instance shutdowns when the price rises and start another instance in a different region.
Amazon recently released a sample program to detect changes in spot prices by region and instance type: How to Track Spot Instance Activity with the Spot-Notifications Sample Application.
Simply combine that with the ec2 command-line tools to stop and start instances and you don't need to manually do it yourself.
Related
I am running an Elastic Beanstalk load-balanced application for a year now. I'm looking for ways to cut back on costs and have discovered I could potentially use reserved ec2 instances instead of the On-Demand instances we are currently using. Currently, my load balancer uses two instances.
I want to make the switch but am unsure about how the process is actually done. I want everything to be crystal clear before doing anything.
From my understanding, if I reserve two of the same type of instance as used in my App, (t2.large with Linux) for the same availability zones (1 in eu-west1b, another in eu-west1c) I could use these instances for the load balancer. Will the same-type instances I currently have deployed immediately fall under rates of a reserved instance? Will I have to rebuild my environment and and build two new instances that match the reserved ones?
A Reserved Instance a method of pre-paying for Amazon EC2 capacity.
If you were to buy two Reserved Instances (in your case, 2 x t2.large Linux), then for every hour of the year while the Reserved Instance is valid you will be entitled to run the matching instance types (2xt2.large Linux) at no hourly charged.
There is no need to identify which instance is a Reserved Instance. Rather, the billing system will pick a matching instance that is running each hour and will not bill any hourly charges.
Therefore, if these are the only matching instances you are running, then they will (by default) be identified as Reserved Instances and will not receive hourly charges. If you run other instances, however, there is no way to control which instance(s) receive the pricing benefit.
It is possible to purchase a Reserved Instance with, or without, identifying the Availability Zone. If an AZ is selected, then the pricing benefit of the Reserved Instance only matches an instance running in that AZ, and there is also a capacity reservation to give you priority when running instances that match the Reserved Instance. If no AZ is selected, then the pricing benefit applies across any instances running in that region, but there is no capacity reservation.
Bottom line: Yes, it will apply immediately (for the number of instances for which you have purchased Reserved Instances). There is no need to start/stop/rebuild anything.
For anyone looking for a bit more certainty than John's (correct) answer, here's the official AWS docs on the subject:
In this scenario, you have a running On-Demand Instance (T2) in your account, for which you're currently paying On-Demand rates. You purchase a Reserved Instance that matches the attributes of your running instance, and the billing benefit is immediately applied. Next, you purchase a Reserved Instance for a C4 instance. You do not have any running instances in your account that match the attributes of this Reserved Instance. In the final step, you launch an instance that matches the attributes of the C4 Reserved Instance, and the billing benefit is immediately applied.
From here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html
I am a little bit confused with the way EC2 pricing works with reserved instances. It is my understanding that EC2 reserved instances are just a way to price instances.
For my application I need to randomly create a new instance and terminate the current, but that has to happen with no major delays as sometimes happen with spot instances where you have to bid the right price or wait for the price to drop to your level.
In the case of purchasing a reserved instance that would mean there will always be an instance for me?
Any clarification on this will be appreciated.
Thanks
Unless there is some other system issue. On demand instances always launch. A reservation is simply a billing feature and will bill a matching on demand instance at the reservation price.
Reservations have two parts to them, a cost savings, and an capacity "guarantee." I'm putting that in quotes because there's no way to completely guarantee capacity.
So, for instance, if you have a reservation for a m3.xlarge running Linux in us-east-1a, and there's a run on that instance type in that AZ, you'll be given priority over someone requesting that instance without a reservation.
I'm planning to start using Amazon EC2, and, as everyone, I want to use Spot instances.
Will be for a minigames server, so Spot instances are perfect for this. Players enter, play the match and leave, so when a Spot instance finishes because of spot instance price volatility only current match will be finished, barely any data loss and perfectly acceptable when you save a lot of money.
Now, altough players are going to be disconnected and connected to an ondemand server when volatility reaches maximum bid, I would like to know if when a Spot instance is force-terminated is called the normal shutdown command or simply is "unplugged" and I don't have a chance to disconnect players safely and save their data to the database (this will take just a few milliseconds).
As of 2015, Amazon now provides a 2-minute termination notice in the instance metadata.
A custom script can be written to poll for the termination notice and call web server graceful shutdown and associated cleanup scripts to ensure zero impact to end-users.
Source: https://aws.amazon.com/blogs/aws/new-ec2-spot-instance-termination-notices/
I wanted to make sure there is no better way to do what I am doing without having to register a new AMI each time I make a change to my instance.
My current workflow is the following:
Create an AMI with my default settings and all my cronjobs (lets call it A1)
Create a cronjob on another instance wich buys a spot request for instance A1 every X hours
A1 runs its jobs and automatically shutdown itself
Terminate the spot request for the A1 instance
Edit the files in A1 if there are changes that need to be done
The problem I have is that many times I need to make changes to my A1 instance and then I have to edit my other instance in order to make changes to the file which buys the spot request to reflect the new AMI. As this is done with tons of instances it gets a little messy.
Is it possible to only change the "content" of instances without having to register a new instance ID? In that way spot requests can keep calling the same ID?
Any tip much appreciated. Thanks!
I can see from billing that we purchased 4 reserved EC2 instances in 2 batches of 2 earlier this year.
We are currently using 2 EC2 instances.
In the list of purchased reserved instances, I can see 2 listed as active, and 2 listed as retired. Can you tell me what "retired" means and if they are still usable?
Thanks
"Retired" means that a reserved instance purchase is no longer in effect.
Usually this would be because the term expired (1 year, 3 years, etc). However, according to this thread, it looks like it could also mean that there was a problem processing payment.
Either way, retired instances are no longer usable.
To add, since I think this point is important enough to put as an answer, Amazon WILL NOT notify you by email or whatever that your reserved instances are about to expire (at least they didn't me).
So if you suddenly get a huge bill then chances are your terms have run out. At this point Amazon will put your reserved instances to retired and put your active instances, which were previously using the reserved policy, to normal rate pay per hour instances.
So it is important to monitor exactly when your term expires to avoid retiring of reserved instances.
We have a different situation with the same symptom -- instances we're using, which happen to be of a type we reserved are described in "Events" on the console as "The instances is running on degraded hardware". We did get an email and stopping (in my case, I had to try a second time to force), then starting got us back on shiny new hardware.
In addition to the previously mentioned term expiration or billing issue, one other reason for a retired reservation is when you modify your reservation. This is when you convert an instance size to another. For example, 1x m1.xlarge instances into 8x m1.small instances.