I had to cover this topic before moving onto the promised topic "Zero Downtime with Amazon Elastic Beanstalk". I hope you would agree once you finish reading this post.
Amazon Elastic Compute Cloud (EC2) offers three types of instances (machines / servers / computers).
- On Demand Instances
- Spot Instances
- Reserved Instances
Regarding billing, when you terminate an instance, its usage time is rounded up to the next hour. Thus the minimum billing time unit is hour. That means even if you run an instance for 10 minutes you would get billed for one hour. If you are under free usage tier then you do not have to worry as it is free, but it is important to be aware of how EC2 instances get billed.
On Demand Instances
In the first one "On Demand Instances" you select the required configuration and bring the machine up and the billing meter starts running from that instant. We use "On Demand Instances" to bring up our staging instance and test the application we are going to deploy. Once satisfied with its functioning we move the application to production and terminate the staging environment. Thus we make use of "On Demand Instances" intermittently and not continuously and pay for whatever time we had it running.
Spot Instances
In my opinion "Spot Instances" are not for everybody, conveniently ignore it for now and read its full details at your leisure. If you have a long running job which is capable of getting interrupted and continue on a new machine from where it left off and if you are not particular about the exact time when such a job runs then you could make use of Spot Instances. As I said earlier it is not for everybody and I do not want to dwell any more on "Spot Instances".
Reserved Instances
The third one in my list "Reserved Instances" is the subject of this blog post. It is quite embarrassing to state what actually happened with me two years back when I tried to understand "Reserved Instances".
I am used to "reserving" a movie ticket if I intend to watch that movie some time in future. If I want to watch the movie right away then I DO NOT "reserve", but just buy the ticket if it is available and watch it right away.
Same is my understanding about "reserving" when it comes to train ticket, bus ticket or reserving a table at a restaurant. Reserving is always for using it sometime in future.
With that understanding of mine no matter how much I tried to study Amazon's documentation, I could not understand why I had to "reserve" an instance when I am looking for an immediate hiring and usage of a machine. I was wondering how much ahead I had to reserve, whether I would get enrolled in some kind of waiting list, when my reservation would come into effect, is there any f***in problem with my understanding of the word "reservation", have I become an alcoholic, have I unknowingly consumed any drugs - I was just going nuts :-)
Getting documentation right is always quite tricky. You want some more examples of understanding or misunderstanding click here.
Should I be watching my language as I am aware that my children would be reading this blog?
They are in their late and mid teens and I feel they need to be treated as my friends and students of software rather than kids. I have been patiently waiting for this moment for all these years to communicate freely with them without any inhibition to discuss all the topics under the sun and particularly software in depth.
In 2011 we were working frenetically to launch our website and I could not afford to fool around wasting time or trying to improve my English knowledge on some silly word called "reservation". So I ignored "Reserved Instances" completely, did my calculation with "On Demand Instances" using Amazon Simple Monthly Calculator and obviously it was costlier when compared to the costs of dedicated servers that were available from various hosting companies and hence went with a dedicated server.
That actually turned out to be a great blessing in disguise for us as we could get our website up quickly, use good old Linux that required no learning curve, setup zero downtime deployment and concentrate on other priority features that had to be implemented. We always knew that we had to take time in understanding EC2 and that's our way forward. After running with the dedicated server for one and a half year we have now moved to EC2. But during that period AWS services improved tremendously, prices were reduced quite a few times, many new services were added by Amazon and more importantly for us, AWS facilities in Asia Pacific region became available. So at that time going with a dedicated server was the best conscious and calculated decision we could have made. But for a little embarrassment if it actually turned out to be that way should we be regretting?
Finally, what the heck is EC2 "Reserved Instance"?
Without understanding this I felt it is improper to be moving on to the topic "Zero Downtime with Amazon Elastic Beanstalk". Don't you agree?
You reserve an instance for a period of one year or three years. Depending on one year or three years and the type of the instance, you pay some upfront costs. From that moment the time period starts whether you actually use an instance or not. But the moment you actually bring up an instance then it gets considered as "Reserved Instance". The instance type you reserve and the AWS region in which you reserve MUST match the instance type and the region when you start an EC2 instance.
Reserved Instance costs are considerably low when compared to On Demand Instance. If you run an On Demand Instance for one year and the same instance type as Reserved Instance for one year the difference in costs are quite significant.
To put in yet another different way for the sake of better understanding, we had hired a dedicated server for the period of one year and had paid the entire cost up front. The equivalent of doing the same in EC2 is to reserve an instance for one year, pay immediately the specified upfront cost, start an instance, start accumulating hourly running costs for that instance and pay the running costs at once at the end of every month.
In our experience when we compare the cost we had paid for the dedicated server and the costs we would be paying for EC2 with equivalent configuration, EC2 is definitely cheaper, easily by 20%. The savings could be even higher but I am being highly conservative and guarded in mentioning that percentage because it is very difficult to compare that way and in this blog post, definitely we are not into comparison but more into understanding different EC2 instances and particularly "Reserved Instances". But moving to EC2 definitely guarantees a better infrastructure and the availability and integration with other world class services provided by AWS.
Do you think instead of calling it as "Reserved Instances" if Amazon had called it as "Committed Instances" or "Dedicated Instances" and called it as "hiring" instead of "reserving" it would have been better? Would appreciate if you leave your opinion in the comments section.
I can't believe that I have openly publicized my embarrassment, but if it helps in understanding "Reserved Instances" little better, then why not? and also smiling or laughing does not hurt. Isn't it?
Please remember, only at Amazon EC2 you "Reserve" for "Immediate Use" :-)