I can see from billing that we purchased 4 reserved EC2 instances in 2 batches of 2 earlier this year.
We are currently using 2 EC2 instances.
In the list of purchased reserved instances, I can see 2 listed as active, and 2 listed as retired. Can you tell me what "retired" means and if they are still usable?
Thanks
"Retired" means that a reserved instance purchase is no longer in effect.
Usually this would be because the term expired (1 year, 3 years, etc). However, according to this thread, it looks like it could also mean that there was a problem processing payment.
Either way, retired instances are no longer usable.
To add, since I think this point is important enough to put as an answer, Amazon WILL NOT notify you by email or whatever that your reserved instances are about to expire (at least they didn't me).
So if you suddenly get a huge bill then chances are your terms have run out. At this point Amazon will put your reserved instances to retired and put your active instances, which were previously using the reserved policy, to normal rate pay per hour instances.
So it is important to monitor exactly when your term expires to avoid retiring of reserved instances.
We have a different situation with the same symptom -- instances we're using, which happen to be of a type we reserved are described in "Events" on the console as "The instances is running on degraded hardware". We did get an email and stopping (in my case, I had to try a second time to force), then starting got us back on shiny new hardware.
In addition to the previously mentioned term expiration or billing issue, one other reason for a retired reservation is when you modify your reservation. This is when you convert an instance size to another. For example, 1x m1.xlarge instances into 8x m1.small instances.
Related
I am running an Elastic Beanstalk load-balanced application for a year now. I'm looking for ways to cut back on costs and have discovered I could potentially use reserved ec2 instances instead of the On-Demand instances we are currently using. Currently, my load balancer uses two instances.
I want to make the switch but am unsure about how the process is actually done. I want everything to be crystal clear before doing anything.
From my understanding, if I reserve two of the same type of instance as used in my App, (t2.large with Linux) for the same availability zones (1 in eu-west1b, another in eu-west1c) I could use these instances for the load balancer. Will the same-type instances I currently have deployed immediately fall under rates of a reserved instance? Will I have to rebuild my environment and and build two new instances that match the reserved ones?
A Reserved Instance a method of pre-paying for Amazon EC2 capacity.
If you were to buy two Reserved Instances (in your case, 2 x t2.large Linux), then for every hour of the year while the Reserved Instance is valid you will be entitled to run the matching instance types (2xt2.large Linux) at no hourly charged.
There is no need to identify which instance is a Reserved Instance. Rather, the billing system will pick a matching instance that is running each hour and will not bill any hourly charges.
Therefore, if these are the only matching instances you are running, then they will (by default) be identified as Reserved Instances and will not receive hourly charges. If you run other instances, however, there is no way to control which instance(s) receive the pricing benefit.
It is possible to purchase a Reserved Instance with, or without, identifying the Availability Zone. If an AZ is selected, then the pricing benefit of the Reserved Instance only matches an instance running in that AZ, and there is also a capacity reservation to give you priority when running instances that match the Reserved Instance. If no AZ is selected, then the pricing benefit applies across any instances running in that region, but there is no capacity reservation.
Bottom line: Yes, it will apply immediately (for the number of instances for which you have purchased Reserved Instances). There is no need to start/stop/rebuild anything.
For anyone looking for a bit more certainty than John's (correct) answer, here's the official AWS docs on the subject:
In this scenario, you have a running On-Demand Instance (T2) in your account, for which you're currently paying On-Demand rates. You purchase a Reserved Instance that matches the attributes of your running instance, and the billing benefit is immediately applied. Next, you purchase a Reserved Instance for a C4 instance. You do not have any running instances in your account that match the attributes of this Reserved Instance. In the final step, you launch an instance that matches the attributes of the C4 Reserved Instance, and the billing benefit is immediately applied.
From here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html
I am a little bit confused with the way EC2 pricing works with reserved instances. It is my understanding that EC2 reserved instances are just a way to price instances.
For my application I need to randomly create a new instance and terminate the current, but that has to happen with no major delays as sometimes happen with spot instances where you have to bid the right price or wait for the price to drop to your level.
In the case of purchasing a reserved instance that would mean there will always be an instance for me?
Any clarification on this will be appreciated.
Thanks
Unless there is some other system issue. On demand instances always launch. A reservation is simply a billing feature and will bill a matching on demand instance at the reservation price.
Reservations have two parts to them, a cost savings, and an capacity "guarantee." I'm putting that in quotes because there's no way to completely guarantee capacity.
So, for instance, if you have a reservation for a m3.xlarge running Linux in us-east-1a, and there's a run on that instance type in that AZ, you'll be given priority over someone requesting that instance without a reservation.
I'm planning to start using Amazon EC2, and, as everyone, I want to use Spot instances.
Will be for a minigames server, so Spot instances are perfect for this. Players enter, play the match and leave, so when a Spot instance finishes because of spot instance price volatility only current match will be finished, barely any data loss and perfectly acceptable when you save a lot of money.
Now, altough players are going to be disconnected and connected to an ondemand server when volatility reaches maximum bid, I would like to know if when a Spot instance is force-terminated is called the normal shutdown command or simply is "unplugged" and I don't have a chance to disconnect players safely and save their data to the database (this will take just a few milliseconds).
As of 2015, Amazon now provides a 2-minute termination notice in the instance metadata.
A custom script can be written to poll for the termination notice and call web server graceful shutdown and associated cleanup scripts to ensure zero impact to end-users.
Source: https://aws.amazon.com/blogs/aws/new-ec2-spot-instance-termination-notices/
I use 1 spot instance and would like to be emailed when prices for my instance size and region are above a threshold. I can then take appropriate action and shut down and move instance to another region if needed. Any ideas on how to be alerted to the prices?
There's two ways to go about this that I can think of:
1) Since you only have one instance, you could set a CloudWatch alarm for your instance in a region that will notify you when the spot price rises above what you're willing to pay hourly.
If you create an Alarm, and tell it to use the EstimatedCharges metric for the AmazonEC2 service, and choose a period of an hour, then you are basically telling CloudWatch to send you an email whenever the hourly spot price for your instance in the region it's running in is above your threshold for wanting to pay.
Once you get the email, you can then shut the instance down and start one up in another region, and leave it running with its own alarm.
2) You could automate the whole process with a client program that polls for changes in the spot price for your instance size in your desired regions.
This has the advantage that you could go one step further and use the same program to trigger instance shutdowns when the price rises and start another instance in a different region.
Amazon recently released a sample program to detect changes in spot prices by region and instance type: How to Track Spot Instance Activity with the Spot-Notifications Sample Application.
Simply combine that with the ec2 command-line tools to stop and start instances and you don't need to manually do it yourself.
I'm working on my enterprise SaaS application and some of my users would like to be charged on a per-seat approach.
I was wondering how to make sure that the access will indeed be limited. I can see right now that people with the same login/password are logging from different IP addresses, different user agents at the same time, even though the company have paid only for one seat.
What would be the best way to implement the limitation from business and technical perspectives? I don't want to be too strict, at the same time I want companies to pay for the number of seats they actually need.
Don't filter by user agent, I think that would be too strict, some people may have a variety of browsers installed. Filtering by IP could also be tricky, some users may have a dynamic IP that changes at regular intervals.
One idea I have would be to force users to install a browser extension, the browser extension could generate a unique ID from something on the operating system. Maybe use a HDD volume number or Windows serial key, anything that will be unique to that computer.
Once you have this unique ID, use it in the back end tracking every time the user logs in. If the user exceeds a certain number of seats you can either block the user account or contact them first.
It would also be a good idea to allow the user a certain amount of freedom, so that if they have one seat then the back end will allow maybe 2 seats for a month (rolling period), this would be in-case the user buys a new pc or installs a new HDD.
Using IP seems a bad idea - people in a LAN will (usually) all have the same IP.
Assuming PHP has no API to access inspect sessions different than the current one - one idea is:
if you're not already doing it, for each login cookie you issue, also issue an unique id (an UUID will serve your purpose)
store those ids somewhere (in java you could store them in the application context, maybe in php you'll need a db table for that - I'm no php expert), together with two timestamps: "session start" and "last activity"
at each request, record the current timestamp in "last activity"
Then, when you get a new request, count how many other active have
last activity >= current session start
last activity >= now - session TTL (only needed if can't prune expired sessions in a timely fashion)
That should give you the number of occupied seats.
Note you will not notice a violation of the number of seats until after the surplus user has logged in and precisely until you see activity in some other session – I don't see any way around this issue since you don't know exactly when a seat becomes vacant (well, you might say it's vacant only when its session has expired, but that seems unfair).