My on-demand instance currently hosts a website, does a few computing, and serves as a light-load php server. To reduce the cost, I'm thinking about migrating it to a spot instance. I haven't found any clue on the web yet. Any pointers are greatly appreciated.
Spot instances and on-demand instances are two separate systems. While on-demand systems are available all of the time, you set a maximum bid for spot instances instead. If there are systems available for that price, they will be launched. However if there is a higher demand in your availability zone, these systems may be terminated without notice. So for hosting a website on AWS, I would not recommend using spot instances. If you want to reduce the price, you can have a look at reserved instances instead.
That said, you would probably have to stop your on-demand machine and set up a spot instance request for this machine instead.
Related
I'm trying to reduce my expenses and want to start using AWS's spot pricing service. I'm completely new to it, but as I understand I can have instances running for certain amounts of time based on the price that will eventually stop running based on certain conditions. That's fine, I'm also aware you can have spot fleets, and in these fleets you can have an On-Demand instance for when the spot instance is interrupted.
I currently have a an On-Demand instance that hosts an ElasticBeanStalk application (it's an API), is there a way to use this instance inside the spot fleet so that when there's an available spot-instance it's servicing my EBS application then when the spot-instance is interrupted it just goes back to using my current On-Demand instance until another spot-instance is available?
Sadly, spot fleets don't work like this. If your spot instance gets terminated, no on-demand replacement is going to be created for you automatically. If it worked like this, everyone would be using spot instances in my view.
The on-demand portion of your spot fleet is separate from spot portion. This way your application will always run at minimum capacity (without spot). When spot is available, your spot instances will run along side your on-demand. This way you will have more computational power for cheap, which is very beneficial for any heavy processing application (e.g. batch image processing).
Details of how spot fleet and spot instances work are in How Spot Fleet works and How Spot Instances work docs.
Nevertheless, if you would like to have such replacement provisioned you would have to develop a custom solution for that.
There's a third-party solution called Spot.io that not only replaces the spot instance for an on-demand instance in a scenario like the one you describe but it has an algorithm that anticipates the interruption event and stands up an On-demand instance and has it ready before the interruption occurs.
Edit: This question is NOT to ask about "Spot Instances"; this question is to ask regular "On Demand Instance". I think I need to clarify this, after reading comments below.
Basically, my question is about whether I should consider the risk that when I need to launch an EC2 instance, but that EC2 region has run out of capacity and can't fulfill my request.
I understand the chance for the above situation is extremely low, but I'd like to understand if AWS has any SLA to make sure that situation/risk won't happen.
There are protective controls in place to make the unavailability of a particular type of instance in a particular availability zone at a particular time unlikely... but it's possible, and there is no assurance provided by AWS that a given type of EC2 instance will be available for launch, on-demand, at any particular time, in any particular Availability Zone unless you purchased reserved instances of that type, specifically in that availability zone. In that case, there is supposed to always be sufficient hardware available so that you can have the number of paid reserved instances running, at minimum, including the ability to launch enough new instances to bring the total up to that minimum.
Reserved instances are commonly discussed in the context of their associated discount, but they have two purposes:
Reserved Instances are not physical instances, but rather a billing discount applied to the use of On-Demand Instances in your account. These On-Demand Instances must match certain attributes in order to benefit from the billing discount.
When you purchase Reserved Instances in a specific Availability Zone, they provide a capacity reservation. (emphasis added)
For example, if you purchased 4 reserved t2.2xlarge instances in us-east-2a, the assurance is that you will always be able to launch enough to bring the total running instances of that type in that zone to 4. If you already have 4, there's not an assurance of being able to start more, but there is an assurance that if you stop them, you will be able to start them again.
Pricing models for reserved instances has changed over the years, such that reserved instances are generally billed at the same rate whether they're running or not, so you can look at it one of two ways:
If you need the capacity all the time, you're getting a substantial discount... or, if you don't need the capacity all the time, you're technically paying all the time for capacity that is largely unneeded, but you are still paying less than you'd pay for on-demand instances without reservations, and you can either leave it running or launch it when you need it.
Should you consider the risk that an entire region has widespread capacity issues? You should consider it, but there are, historically speaking, other significant outage scenarios that are more likely... EBS and S3 have both had failures that impaired the ability to launch instances, even though the capacity was idle in EC2.
Yes. I've had API calls to create EC2 resources fail many times due to lack of available AWS resources. I most commonly see this when attempting to create a new EC2 instance with Dedicated Tenancy in a specific Availability Zone.
Yes. It is possible your instance request cannot be fulfilled. On-Demand instance does not guarantee you an instance. In particular,t2.small instances are more likely to be not fulfilled based on my experience. It is possible, AWS has only limited number of t2.small instances.
How can you make sure it is always fulfilled?
Reserve the instances for you so that it is not given to anyone else. But there is a cost associated with it. You have pay for the instance irrespective of whether you use it not. I am talking in general terms. Reserved instance is a complex topic, but that is the route you should take if you want AWS to guarantee you an instance.
The answer is yes, your launch request can fail because there is no available capacity in the relevant Availability Zone. I would say that it's a rare occurrence, but certainly possible.
You can mitigate by using multiple zones in the same region, other regions, or by using Reserved Instances.
Today it happened in an AWS account that I manage. If I am not wrong it was the family r4, exactly an r4.xlarge instance (4 hours ago) in Virgina Region. I had to choose a different AZ. That is why AWS always recommends working with more than one AZ.
But for that reason, I started to use Scheduled Reserved Instances
You always will have for a period of time a reserved capacity of a family type of instance(s).
Sure, it works if you have a defined schedule or workflow.
Hope it helps you.
A long time ago, there was the most useful spot price comparison graph that I have ever used, but it stopped working, as far as I know, because the creator ran out of time to maintain it. The website is still active ec2price.com and the code is on Github. Does anyone know if anyone has replicated this? or any way to do it myself? As I said it was really useful to decide which spot instance to choose.
You can see this information in the EC2 console by browsing to Spot Requests and selecting the Pricing History button.
If you want to select the cheapest ec2 instance type automatically you can create a spot fleet request; select all the instance types you might want to use and an allocation strategy of lowestPrice. Deploy this to a VPC with a subnet in all availability zones in your region to get the lowest price possible.
Besides codes, somebody must pay to maintain server that polling the information.
Check out How Spot Fleet Works. Spot fleet is way better than price monitoring. You can make request base on pricing for a fleet of instance type than limit yourself to specific instance type. You can kick start instances from a large fleet base on maximum instance price or vCPU price.
If you are using a SPOT ready batch application, after submit your bidding for fleet of different instance type and set the maximum per vCPU price, Spotfleet will automatically launch available instance with the best price. So you don't need to compete with limited popular instance(for example, c4.* SPOT instance is scarce for most region).
This is a win-win for both AWS and customer, as AWS able to spread the usage to underutilized instance type. IMHO, There is no point of keep raising the bid for particular type if those instance exhausted, while there is still many idle AWS instances in alternate zone that are not fully utilised for grab.
Our website is available throughout the year, and can handle traffic quite well with an AWS EC2 medium instance type. Every now and then (once a month), we get really heavy traffic though, and might need several extra large instances. We know when this will occur, and so we can start up instances in advance.
I have just noticed that we would save quite a bit of money when pre-purchasing a medium reserved instance, compared to our current on-demand instance. The problem is that such a reserved instance would mean that our master will be fixed at a medium instance type.
My question is this: Would there be any issues having such a small master, when we need to start-up new x-large slaves? What advantages would there be to keeping the master as an on-demand instance?
Reserved instances are there to save money for those instances you regularly run. I would suggest using reserved instances for your 'master'. The only advantage of keeping that one on-demand is the advantage that you could scale up or down as soon as your constant flow of traffic changes up or down. Make sure you choose the right use for your reserved instance; an 'always-on reserved instance' should have an heavy-use reserved purchase. Those 'peak instances' do best as an on-demand instance.
Just because you have a reservation does not mean you need to be running it all the time. The reservation will apply to any instance matching its parameters.
There are different reservation options as well depending how heavily you use a given instance type. You can take advantage of reserved instances and continue to do what you are doing, you don't need to switch anything.
We have a web application running on a single small instance. Most of the time this is fine. However, occassionally our application does intensive queries and utilizes more CPU than the small instance can handle.
What I am wondering is; is there a way to have a SPOT instance (C1 High CPU Medium) launch and run while the spot price is low? Ie, have it run always as the 'main server' unless the spot price goes up; and then just revert (seamlessly) back to our reserved small instance - for the rare times the spot price increases?
Basically - a way to get a high cpu instance on the cheap...and our small instance will suffice 'Most of the time' anyway, so a failsafe to it is okay.
You should take look at AWS Spot Labs. You can get access to some advanced features that will allow you to
explore new ways to optimize your Amazon EC2 costs...
In the meanwhile, you can use your reserved or on-demand instances in an auto-scaling group. Then while your Spot server is running, the load should be minimal and you will have a minimal number of on-demand instances. Once the spot instance is going down, you will start scaling up the on-demand (or reserved) instances to compensate for the lack of the main machine.
Actually you can even have your Spot Instances in a different (lower threshold) auto scaling group and launch several cheaper spot instances when they are available. See more details in: http://docs.amazonwebservices.com/AutoScaling/latest/DeveloperGuide/US-SpotInstances.html