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.
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.
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.
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 right now AWS free tier instance. I purchased a m3.large reserved instance. Now how can i run and use this as i was using free tier instance .
I cant see any start/stop option for reserved instance.
Reserved instances are purely an accounting/billing thing. There is not a special way to "run" a reserved instance. Simply run an instance that matches the specifications of your reserved instance purchase and it will run at the reserved instance rate rather than the on-demand rate.
Basically AWS billing sees that you're running an instance for the hour. They check to see if there is a reserved instance purchased that matches the specifications of the running instance. If one is found, that hour is billed at the reserved rate. If one is not found, then you're charged at the on-demand rate.
We’ve purchased an Amazon Web Services (AWS) reserved instance for an Amazon Elastic Compute Cloud (EC2) instance that is critical to our infrastructure. This instance starts and stops every day at certain time interval.
I see that purchasing a reserved instance 'guarantees' that this instance will reliably start even when AWS is under heavy load, but is there any way to specifically tie this reserved instance to the instance we want to associate with it?
What happens if we add another instance that matches the exact criteria of the reserved instance we’ve purchased?
You don't need to worry or do anything in associating the instance and the purchased Reserved Instance; all those are done automatically by AWS.
The reserved Instance is purely a billing and cost related and it doesn't relate to the technology aspect of an EC2 instance. If any of your running instance matches with any of your purchased Reserved Instance then you benefit from the reduced costing. There isn't any commitment on the SLA or changes at the Instance level which involves Reserved Instance. The same case works when you have 2 reserved instances; if there 2 instances running in your account which matches your reserved instance purchase they the reduced cost would be applied.
Analogy - Super Market Coupon Offer
If the Offer Says, buy 2 units of Product A and get one Product B
absolutely Free. So you look into the offer and take 2 units of
Product A and one Unit of Product B. During the billing as well, the
Point of Sales Person also doesn't look into each and every product
and try to check it offers; rather he or she directly keeps scaning
each and every product against the bar-code scanner and that't it -
when these 3 are scanned, the price for Free-Product is automatically
reversed.
So similarly, you buy the Reserved Instance (Coupon) choosing the AMI,
Region, AZ, Duration etc. You would do all your tech stuff as usual
like deploying, patching, monitoring etc. During the billing, if the
instance(s) you launched matches the Reserved Instance, then the
Reserved pricing would be applied; if not that would be charged at
'On-Demand-Pricing'.
If there is a mismatch between what instance you are running and what instance you have reserved; you will not be using the benefit of Reserved-Instance pricing
and be charged with On-Demand-Pricing. Also you will be wasting the
investment done for the Reserved-Instance
As implied in Naveen's answer, there is no direct way to associate an instance with a reservation.
If you want the reliability, then you must launch instances with unique set of properties (instance type, az and AMI). There is no other way at the moment.
This is supposed to be a comment in Naveen's reply. But as I had no reputation yet to commen, I am adding it as an answer.