
Understanding and using Amazon EBS - Elastic Block Store - mblakele
http://perfcap.blogspot.com/2011/03/understanding-and-using-amazon-ebs.html
======
spravin
I liked the tenant-rent analogy xlarge:large:small::house:room:couch.

tl;dr version: The author is insinuating that Reddit doesn't have enough money
to rent a house, so its renting a couch, and so it can't complain if the other
occupants have an all-night rave party.

------
a2tech
Long, but well reasoned article on EBS. Basically comes down to-know your
load, and be darned sure you have adequate metrics in place for tracking
latency.

------
noelwelsh
My take-away message from this: if you want predictable predictable
performance using AWS you need to use largest instances and EBS block sizes.
This suggests Amazon scales up but not down. As in, if you're using the
smaller instances (because you're a startup, say, and don't have a great deal
of traffic) you're hosed. On the other hand, a lot of the calculations I've
seen suggest maintaining your own server infrastructure is cheaper than AWS
and you get more predictable performance, so I wonder why anyone who has a lot
of traffic would use AWS (except for handing traffic spikes or batch jobs). So
to me it seems that AWS doesn't have a great use case. I'm interested in other
viewpoints.

~~~
jollojou
It depends on the application(s) you wish to run on AWS. If your EC2 instance
runs an HTTP server that is backed by an external database like RDS, your I/O
bottlenecks is not the EC2 instance's disk.

The article points out rather successfully that once you know at least
something about the internals of each AWS service, you can fit them into your
particular needs.

