Wednesday, February 6, 2013

Amazon EC2 Cost and Storage Considerations

I started off paying for a 32bit Amazon Linux EC2 Micro Instance, and I chose to switch from on demand pricing to a heavy utilization 3yr reserved term. That's fine for your own little website, but there is a lot to consider when using these for demo or more demanding purposes.

Reserved Instances

First off, recognize that while heavy utilization gives the best price, it means you'll be charged the hourly fee even when the machine is not in use. So if there is any possibility you won't need the box in the near term it's better to just stick with on-demand. Even compaired to light and medium utilization reserved prices, on-demand prices aren't that bad. The lost cost of sticking with on-demand for a couple of months until it's obvious you'll need the machine for the long term is relative insignificant.

Instance Storage

Another important consideration is the cost and type of storage. EC2 instances can use EBS backed storage or instance aka local storage. The difference is significant (,

  • EBS is automatically replicated thus preventing data loss due to hardware failure
  • EBS can be snapshoted to S3 from which new EBS clones can be created
  • EBS costs $0.10/gb/month of provisioned storage
  • EBS costs $0.10 per 1 million I/O
  • EBS exists independant of an EC2 instance and persists after instance shutdown
  • Local instance storage is created from an S3 backed AMI at time of EC2 instance launch and is destroyed at instance shutdown.
  • Local instance storage costs nothing.
  • t1.micro only supports EBS, it has no local instance storage.

A rough estimate is that 10 people using a website costs about $1/month for EBS I/Os, so 10,000 people costs $1000/month when it could cost nothing.

Also, once you get into loadbalancing and autoscaling it makes a lot more sense to keep all your stateful data (config files, db, etc) elsewhere. Then you can create an AMI, automatically launch a bunch of machines from it and not worry if they die. When you need software upgrades, you can manually launch an instance from the AMI, create a new AMI and launch future instances from the new AMI.


When you're setting up an instance from which you will create an AMI, always choose 64bit unless you're sure you're never going to scale. The reason is that it's trivial to switch from a micro to a small, but you're stuck with your 32bit/64bit choice. So if you ever want to scale upt to a macine with more than 4gb of RAM, you'll want to start with 64bit.

{ "loggedin": false, "owner": false, "avatar": "", "render": "nothing", "trackingID": "UA-36983794-1", "description": "", "page": { "blogIds": [ 398 ] }, "domain": "", "base": "\/michael", "url": "https:\/\/\/michael\/", "frameworkFiles": "https:\/\/\/michael\/_framework\/_files.4\/", "commonFiles": "https:\/\/\/michael\/_common\/_files.3\/", "mediaFiles": "https:\/\/\/michael\/media\/_files.3\/", "tmdbUrl": "http:\/\/\/", "tmdbPoster": "http:\/\/\/t\/p\/w342" }