Sizing EC2 Servers to get more Bang for the Buck

To launch an app there was a tried and true process. The process in the past was to rent a server in a managed hosting facility. Get a few more as you grow, then build a model showing that it would be cheaper to get your own cage and finance servers. If the app continues to grow, build a model showing it would cost cheaper and allow for more rapid growth if you built your own datacenter after multiple requests for more power, space and moving to larger spaces with more power.  Now we have a new Step. If Step 1 is managed hosting then Step 0 is putting your application in the cloud i.e. Amazon's EC2.

When an app grows cost grows at a multiple in EC2. To offset these costs, take periodic looks at your architecture to see if there is anything you can do to reduce overall cost. Let's look at a tier that is easy to scale. Let's look at application memory caching on Memcache as an example to illustrate reducing cost.

To scale network caches, add more memory. Make sure that the throughput of data going through the system doesn't exceed your instance network bandwidth capacity and generally, you are good. (There are CPU concerns at high concurrency and pulling many bits at a huge rate). Simplifying things the cost to scale Memcache is really the cost per GB of memory in EC2.

Sizing your Memcache pool is based on a number of factors. What is being cached? How is the cache used? How many distinct items and how large is each item on average. For a dynamic app that caches database rows let’s base the cache on reducing repetitive queries to the database for users hitting the site. So the size should be based on how many daily active users the application has. The model is a function of daily active users (DAU) cacheable data size.  If the database is 200GB from 1 million users and 10K users use the site per day, cache 10K users worth of data instead of 200GB.  

Northern California DC prices us-west1 - has the best uptime and costs the most:

m1.large Amazon's Large Instance Server has 7.5 GB of memory and costs $0.36 per hour per server. There are 744 hours in a 31-day month so this m1.large costs roughly $268 per month.

m1.xlarge is 15GB but has eight Compute Cores - you don't need eight so lets skip that and look at the High memory plan.

m2.xlarge has 17.1 GB of memory and 6.5 Compute Cores and costs roughly $376 per month.

m2.2xlarge has  34.2 GB of memory and costs  $752

m2.4xlarge has  68.4 GB of memory and costs $1505

So the impulse might be lets get a bunch of m1.large since they are the cheapest at $268, but in actuality the price is not the cheapest for the scale needs.

m1.large costs roughly 5 cents per hour per GB while the high memory family costs 3 cents per hour per GB. Since the other scale condition is to not saturate your network bandwidth, having more points of access solves this with the additional benefit of loosing smaller sections of cache when a server goes down. (This is handwaving assuming the instances are not on the same server/rackswitch etc).

Therefore, the best bang for the buck is m2.xlarge (m2 family) at 3 cents per GB per hour for a monthly cost of $376. This is only 40% more then m1.large cost per month for 2.26 times the memory of m1.large. Now if the application doesn't require 2.26 times the memory and its not being utilized then its not worth spending more money.