want to use spot instance reliable(without termination because of spot market price) for some duration, have following question for the same:
is spot-instance with block duration run without interruption for given duration, and can we rely on that to not terminate instance because of market price of that instance?
is the pricing for --block-duration is same as other spot instance?
is spot-instance with block duration run without interruption for
given duration, and can we rely on that to not terminate instance
because of market price of that instance?
Yes. You can run your spot instances for a maximum allowed block duration period of 6 hours without any interruption or termination even if there is any hike in market price.
is the pricing for --block-duration is same as other spot instance?
No. The pricing is different(greater) than the Spot Instances without defined duration. Refer this link for EC2 Spot Pricing.
Related
I was created an instance in Google Cloud Platform. I use this instance 2 to 4 days in a week. So, I want to close my instance for rest of the days to save my billing charges. So, what is best option for me. Stop the instance or Suspend the instance? What is the difference between them?
Please have a look at the documentation Suspending and resuming an instance:
Suspending an instance differs from stopping an instance in the following ways:
Suspended instances preserve the guest OS memory, device state, and application state.
Google charges for the storage necessary to save instance memory.
You can only suspend an instance for up to 60 days. After 60 days, the instance is automatically moved to the TERMINATED state.
and at the article Stopping and starting an instance:
Instances that are in a TERMINATED state are not charged for
per-second usage and do not count toward your regional CPU quota, so
you can choose to stop instances that you are not using, saving you
from being charged for instances that aren't active. After you are
ready, you can come back and start the same instances again, with the
same instance properties, metadata, and resources.
Your instances are not charged for per-second usage while in the
TERMINATED state but any resources attached to the virtual machine,
such as static IPs and persistent disks, are charged until they are
deleted.
As a result, it's better to stop your VM instance, to avoid extra changes for keeping instance's memory.
In addition, please have a look at the article Save money by stopping and starting Compute Engine instances on schedule.
i want to the difference between spot and on demand instances. I know there is a price difference between these two but other than this i want to know the differences. Please help me
Actually there are three allocation types:
on demand - kind of "default" mode. You request an instance, if there is free capacity, you will get the instance. No long term commitment, but once you get an instance, it's yours. It may happen that you will get a message that there is no free capacity for the specific instance type and AZ (so far it happened to me only once with AWS).
reserved - AWS reserves the capacity for you. You have guarantee that you will get the instance type in the selected region or AZ.
spot instance - it's kind of auction / bidding of unused capacity. You ask for an instance, you provide your maximum price and if there is free capacity and your price is at the current price or higher, you will get an instance. The difference is - if the free capacity is exhausted, or the current price is higher than your maximum bid price, your spot instance is terminated . You can get a termination warning event upfront.
The resources for both are the same, spot instances utilise the spare compute capacity within the AWS availability zone (those that are not reserved or launched on-demand).
Depending on the demand for that instance class in the availability zone the spot price will increase or decrease (even surpassing the on-demand price).
When you use a spot instance you are taking a risk that if demand increases you will lose access to the spot instance (you are given a 2 minute warning before termination). For his reason it is common to use a mixture of on-demand/reserved instances and spot instances so that you can withstand instance terminations.
Commonly in EC2 applications you would use an autoscaling group with a configured proportion between on-demand/reserved nodes and spot instances.
For more information take a look at the Requesting Spot Instances for fault-tolerant and flexible applications documentation.
I am trying to launch a AWS spot instance for a duration. Before that I checked price history graph.
However, when I launch an instance, I get below message:
"minimum required Spot request fulfillment price of 0.477. "
Is spot instance price for fixed duration different from just spot instance?
How does prices for spot instance price for fixed duration are determined?
You are correct.
Introducing Amazon EC2 Spot Instances for Specific Duration Workloads says:
You can now request Amazon EC2 Spot instances to run continuously, for up to six hours, at a flat rate that saves you up to 50% compared to On-Demand prices.
The price will be higher than the normal Spot Instance price because there is a duration guarantee. A normal spot instance can be terminated at any time (with 2 minutes notice).
There is no information available about how the price is determined, but presumably it involves a prediction of having sufficient capacity over that time period possibly forcing normal spot instances to terminate in order to provide sufficient capacity for the defined duration.
I have a small query on AWS Auto Scaling.
For auto scaling group, we need to set minimum (1 server) and maximum no of instances to scale.
Question:
Lets assume, I already have a reserved instance running 24x7.
I will create an AMI of the reserved instance and use this AMI for auto scaling.
I want to make this reserved instance as part of auto scaling group (this become my minimum 1 server in the auto scaling group).
But I don't want this reserved instance to terminate at all (as I have my elastic IP taken for this) when I scale down, but other instances can terminate as the load comes down.
How can I achieve this?
Kindly suggest.
Thanks in advance.
Instances reservations are not tied to a specific EC2 instance. As long as you have an instance running that matches your reservation, you will be charged the reservation's hourly rate.
This reserved instance should not be in the auto-scaling group. You only want it to be in the instances used under the Elastic Load Balancer. The auto-scaling group should only contain instances that are dynamic.
You can set this instance under the load balancer and it will never be terminated.
Remember to set the auto-scaling group minimum to zero, so when the load is low on the reserved instance, the auto-scaling group would call the decrease instance policy, and you would lessen the charges.
The concept of a Reserved Instance is always confusing.
A Reserved Instance is a pre-payment for a certain capacity (Instance Type, OS, optional AZ). For example, let's say you purchase a 1-year Reserved Instance for an m4.large Linux instance. This means that, for every hour of the year, you can run an m4.large Linux instance at no hourly charge, because you have pre-paid it annually or monthly.
Please note that you do not choose which instance receives this billing benefit. Rather, each hour of the year, if an instance is running that matches the Reserved Instance purchased, it is not charged for that hour.
Therefore, you can't really say things like "I want to make this reserved instance as part of auto scaling group" or "create an AMI of the reserved instance" because you have no knowledge nor control over which instance receives the billing benefit. Simply be happy in the knowledge that an instance running that matches the Reserved Instance will receive the benefit.
So, if you have one Reserved Instance and you are running at least one EC2 instance of the matching Instance Type and OS in a given hour, then one of those instances will not receive an hourly charge. It doesn't have to be a specific instance that you nominate.
Side-note: Stopping and Starting an instance triggers a new billing hour. Only one hour is not charged each hour per Reserved Instance purchased. So, if Auto Scaling launching an instance, terminates it, then launches another within the same hour, there will be a charge. Only the first billable hour per Reserved Instance owned will be "not charged".
(I recall seeing something that said that the Reserved Instance benefit is typically applied to the instance with the earliest Launch Time and that if it is stopped/terminated, the benefit goes to the instance with the next earliest Launch Time -- but that might not be accurate.)
I have reservation of type t2.micro and us-ease-1d availability zone, also I have multiple instances running, including the one with mentioned type and zone.
As a result I expect billing for this one instance will take into account the reservation. The problem is that I haven't found any link between reservation and actual instances.
I've used aws ec2 describe-instances and aws ec2 describe-reserved-instances CLI commands but I wasn't able to find any link.
Is it possible to realise which billing approach will be used for each instance using Amazon SDK?
So f.e. I will see that some instance is linked to some reserved instance (reservation)
Is it possible to realise which billing approach will be used for each instance using Amazon SDK?
No, it isn't.
The "link" between reserved instances and running instances is not something the EC2 operational infrastructure knows about. It's all done after the fact, in billing.
Each hour, for a given instance type and availability zone placement, you're billed for your reserved instances (depending on the terms of the reservation, this happens whether you have this many instances running or not, though in some cases, the amount billed here is $0 since you've already paid). Then, if the number of running on-demand instances for that type and placement exceeds exceeds the number of reserved instances for that type and placement, the difference for that hour is billed at the on-demand rate.
So if you had purchased one reserved instance matching a certain spec and during a given hour you had two such instances running, it's not really the case that one of your instances "is the reserved instance" and the other one isn't. If you stop either one, then the next hour, the reserved instance pricing applies to the one that remains running... but EC2 can't tell you which is which and, in fact, the billing logic is such that it doesn't matter.
There isn't really a link between reservations and specific instances. Think of it more like a discount that gets applied to your bill, after you have incurred some instance charges.
You can use the Reserved Instance Utilization Report to see how your reservations have been applied to the instance hours you have been charged for.