I\'m just starting to explore amazon ec2. And I want to hear some explanations or may be some brief examples of how and why do you need \'reservations\' in amazon ec2. I\'m
This is an interesting thread and comments from Ryan Parman & Rose Perrone -- I may ask Mitch about the history at re:Invent later this year (2015), but if you do any normal sort of aws ec2 describe-instances
(or the equivalent from boto, sdks, etc.) you'll see all instances enumerate as "reservations" in some generic sense:
{
"Reservations": [
{
"OwnerId": "123456789012",
"ReservationId": "r-9aa12345",
"Groups": [],
"Instances": [
Within that data is a ReservationId
of a r-12345bc8
value type, but nowhere does that correspond to reservations that you pay for to lock in the lower rate (a billing convenience, not an actual type of instance that you spin up). So my hunch is this is an interesting little residue of when they first created the system -- every instance needed to "reserve" a slot in which to run. Only later did they come up with a pricing model that used the same term.
But again, that's just a guess.
It would appear there is clearly an overlap of two meanings of the word here, that do not appear to be related to one another.
From my understanding, a reservation is an act of launching instances. Basically, a reservation is what you do, while an instance is what you get. If you launch multiple instances from one image via run_instances()
you make one reservation, but get multiple instances.
run_instances
together with Reservation.stop_all()
allows you to run a bunch of instances, wait for them to complete the task and then stop them all at once.
From the boto docs:
A reservation corresponds to a command to start instances. You can see what instances are associated with a reservation:
>>> instances = reservations[0].instances
>>> instances
[Instance:i-00000000]