ECS (EC2 Container Service) works with Auto Scaling Groups. But is it possible to use ECS with Reserved Instances? I ask this because Reserved Instances are cheaper.
When you reserve an instance, you get billed for all possible hours of use for the reservation period at the beginning of the period, whether you use the hours or not. At the end of the billing period, AWS will reconcile your usage hours vs. reserved hours.
This means that regardless of whether you stopped or started the instance automatically, you're still paying for it, albeit at the lower reserved price. Reserved instances do make sense for the 'non-elastic' portion of your ASG, like instance 1 of 3 that always needs to be up. If you have a lot of the same instance type, you can also 'float' reserved instance hours by estimating capacity and making your best guess as to how many auto-scaled hours you will end up needing.
This approach is good if you have an established track record of use, like peak load between 7AM and 5PM PST. You can do the math from there.
My preference for elasticity in ECS is to use the spot market. You will pay much much much less for them and autoscaling works great.
Related
Our organization has many EC2 on-demand instances. We never looked at the reserved instance pricing because we thought we had to pay up-front. But I see that now there are reserved instance with no up-front costs, but monthly.
This looks like what we need to keep costs down, but I am unclear as to how the reserved instance pricing is applied.
For example, we have 10 t3.medium ec2 instance. Let's say that there are 6 always running 24/7, but the other 4 are not running 24/7, they are turned off when not in use.
If I buy a reserved instance for t3.medium, how does AWS know to apply it to the instances running 24/7 and not part time?
For example, we have 10 t3.medium ec2 instance. Let's say that there
are 6 always running 24/7, but the other 4 are not running 24/7, they
are turned off when not in use.
If I buy a reserved instance for t3.medium, how does AWS know to apply
it to the instances running 24/7 and not part time?
Amazon doesn't apply reserved pricing to a specific instance at all. It basically just applies reserved pricing to your bill. It's like a discount at the time your bill is processed. If you have reserved pricing for N instances, and you have at least N instances running 24/7 reflected in your bill, then the reserved pricing gets applied to those N instances.
Amazon doesn't really care if you are running a single specific instance 24/7, or deleting and recreating instances once a minute. In the end it's just the total number of seconds you have a specific type of instance running each month that they care about, and bill you for.
Be aware that when you setup instance reservations it is actually a capacity reservation. You are telling Amazon you are committing to running this type of instance 24/7 for either 1 year or 3 years. By letting Amazon know this, it helps with their capacity planning, and in return they give you a cost discount. But it also means that they are going to charge you for that reserved capacity even if you don't actually have that instance running 24/7.
I have a multi-day analysis problem that I am running on a 72 cpu c5n EC2 instance. To get spot pricing, I made my code interruption-resilient and am launching a spot request of one instance. It works great, but this seems like overkill given that Spot can handle thousands of instances. Is this the correct way to solve my problem or am I using a sledgehammer to squash a fly?
I've tried normal EC2 launching, which works great, except that it is four times the price. I don't know of any other way to approach this except for these two ways. I thought about Fargate or containers or something, but I am running a 72 cpu c5n node, and those other options won't let me use that kind of horsepower (that I know of, hence my question).
Thanks!
Amazon EC2 Spot Instances are an excellent way to get cheaper compute (up to 90% discount). The only downside is that the instances might be stopped/terminated (your choice) if there is insufficient capacity.
Some strategies to improve your chance of obtaining spot instances:
Use instances across different Instance Types and Availability Zones because they each have different availability pools (EC2 Spot Fleet can assist with this)
Use resources on weekends and in evenings (even in different regions!) because these tend to be times of lower usage
Use Spot Instances with a specified duration (also known as Spot blocks), but this is at a higher price and a maximum duration of 6 hours
If your software permits it, you could split your load between multiple instances to get the job done faster and to be more resilient against any stoppages of your Spot instances.
Hopefully your application is taking advantage of all the CPUs, otherwise you'd be better-off with smaller instances.
I have a regular AWS EC2 m3.large instance that I use for a few days a month, when I'm not using it I stop it, and just start it when I need it. I have the understanding that I only pay for it when it is actually running, is that correct ?
I've just recently noticed reserved instances, I'm happy to commit to a term of a few years, however I don't need to use it every day. So assuming my first assumption is correct does that also apply to reserved instances or do i have to pay every day whether or not Im using.
If is a good idea can I convert my existing instance to a reserved instance or do I have to setup a new machine from scratch ?
You have to pay for reserved instance even if you are not using it. The capacity is already reserved for it and you may have already paid a partial payment upfront for you or you can choose no upfront. Reserved instance is use it or lose it.
You can use a calculator and see if reserved instance can save you $$.
You can convert your on-demand to reserved instance just by reserving an instance of same type in the same availability zone. AWS has made the instance reservation more flexible recently but if you are running a single instance, just reserve an instance of same type in the same availability zone. You can choose partial/no upfront, one or three year terms.
In us-east-1, on-demand cost for m4.large is $0.10/hour.
Monthly on-demand cost is: $72/month
Approximate reserved instance (one year) cost with no upfront: $50/month
Number of on-demand hours for $50: 500 hours (20 days)
If you plan to run for less than 500 hours/month, then you should go for on-demand. Remember, with reserved instances you are guaranteed an instance by AWS. Sometimes, on-demand may run out of capacity and you have to choose a different instance type. It is very rare but happens sometimes.
If you "reserve" an instance you have to pay for it.
m3.large instances that you stop you do not have to pay for, but keep in mind you might have to pay for other things like the EBS volume attached.
Judging by what you've said, its sounds like it's cheaper to start/stop the instance when you need it.
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 new AWS ELB feature, connection draining, was recently announced.
http://aws.amazon.com/about-aws/whats-new/2014/03/20/elastic-load-balancing-supports-connection-draining/
Apparently this works with Auto Scaling Groups - instances are drained before being removed, but does that also apply to spot instances that are being terminated by AWS due to a rising spot price?
Nothing definitive I could find, but from my reading on this, I think the answer is almost definitely no. Spot instances are different animals than regular instances, and the way the connection draining works you can specify upto 60 minute delay before your connection-drained enabled instance gets terminated when it becomes unhealthy - if AWS was to allow this added layer of safety to spot instances, it would completely up-end the way spot instances are used and how they are positioned.
The trade-off for using spot instances has always been, "you can pay a fraction of the cost, but you risk being terminated at any instant without warning"...if they added an up to 60 minute 'warning' to spot instances, while it would be fantastic from the end-users point of view, I think it would severely eat into AWS's on-demand and reserved instance pricing model and thus they probably won't support this anytime soon (unless forced to by competitive pressure).
EDIT 1/6/2015: now, almost a year later, AWS has indeed added a 'two minute warning' for EC2 spot instance termination. https://aws.amazon.com/blogs/aws/new-ec2-spot-instance-termination-notices/