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.)
Related
I'm considering using spot instances in an auto-scaling group. While I'm aware that I'll receive a 'Spot instance interruption notice' if my spot instances are going to get terminated, what is unclear from the documentation is if my auto-scaling group will spin up new on-demand instances to replace these when the notice occurs, or if they only get replaced on termination. I'm aware that I could listen for these notices manually, but it seems like something that an auto-scaling group should be able to handle automatically.
I've tried testing this out on an existing auto-scaling group that had spot instances by changing the launch configurations 'spot price' to be lower than the current price. This did not work as it would only effect new instances and not currently running ones. I'm unsure of how to change an existing spot request's price.
What I'm hoping will happen is that on-demand instances will be spun up in the two minutes I have from the interruption notice till the time of termination.
If the Launch Configuration in your Auto Scaling Group is configured to use Spot instances then the new instance will indeed be a Spot instance.
The situation you describe is one of the challenges of using Spot instances; although the cost is very low, Spot instances can be terminated and the underlying resources used for a paying customer to fulfill an on-demand or Reserved Instance at anytime.
One way to avoid this is to use Reserved Instances. If you have a predictable long-term need for an instance, or are running a production workload, using Reserved instances is an effective way to lower your costs (albeit, not as low as a spot instance) without having to worry that you could lose your instance(s) at anytime.
Regarding changing the price, updates to pricing are applied to new instances only. After updating pricing simply terminate your existing instances and they’ll be replaced by your ASG with instances at the new price.
My AWS reserved instance t2.micro is going to expire. I decided to upgrade to t2.small, and have just bought a new reserved instance t2.small, as shown below.
Now, how do I switch from t2.micro to t2.small?
As I didn't change the instance type (T2), here is what I do.
Purchase a new reserved instance, t2.small
Stop instance (t2.micro)：Instances --> Actions --> Instance State --> Stop
Change Instance Type：Instances --> Instance Settings --> Change Instance Type --> t2.small
Start instance (t2.small)：Actions --> Instance State --> Start
Please note that a Reserved Instance is a pricing discount. It does not apply to a specific instance.
By purchasing a t1.micro reserved instance (RI), one instance matching the specification (Instance Type + Operating system + optional AZ) can run every hour during the RI period at no charge (because you have paid for it up-front, either annual or monthly).
The only 'danger' of going past your RI expiry is that the instance will be charged the standard hourly On-Demand rate (about 1.2c/hour for Linux instances). Similarly, the only 'danger' of using a t2.small prior is being charged the hourly rate of 3.2c/hour.
Therefore, if you can survive the instance being offline for a few minutes, simply:
Stop the instance
Change the instance type
Start it again
It doesn't matter if you don't do it at the perfect time... you'll just be charged a few cents.
Further, if your new Reserved Instance is regional (meaning that no Availability Zone has been selected), then you can take advantage of Instance Size Flexibility. This is best understood by example:
You have an RI for a t1.micro
You are running a t1.small
The micro is half the size of the small (in terms of CPU & RAM)
Therefore, the RI covers half the cost of the instance, and you only pay the other half
So, if your new RI is regional, it doesn't matter if you change the instance size late. Your t2.small RI will actually cover the cost of the t2.micro instance (and could actually cover the cost of 2 x t2.micro instances).
Bottom line: Change your instance type whenever you want. The cost of getting the timing wrong is negligible.
One strategy would be to take an image snapshot of your micro instance and use it for the small instance.
First, make a backup.
Open the context menu (right click) on your running instance in your Instances pane.
Choose Image -> Create Image.
You'll eventually have a new AMI in the AMIs pane.
When you are making the switch, use this new AMI to launch the instance (select the AMI and Launch).
You'll need to stop one instance and start the other at the appropriate time. Either write a script that uses the AWS SDK in the language of your choice, or do it manually.
Don't forget about DNS and IP addresses with respect to making the switch, and that you'll have downtime unless you have some overlap. I would recommend you leave micro running while you start the small and change your routing etc.
This solution will work, but it will reset the Public IP. Which will then need to be updated on Route 53, in order to make the site work again. And any other place the public IP has been used.
Stop the instance: Instances --> Actions --> Instance State --> Stop
Change Instance Type: Instances --> Instance Settings --> Change Instance Type
Start the instance again: Actions --> Instance State --> Start
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.
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.