Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a server under production that is currently only used by the 4 employees that are working with it. Using the monitoring-tool from the amazon console I see we get about 2500 requests per day which seems about right.

However when I check the bill under Account Activity I see that EC2 EBS has a total of 471,376 IOs during these six days of december.

Is there an error abound, or is there a fundamental difference between requests and I/O that I have not understood?

share|improve this question
up vote 5 down vote accepted

An I/O operation is anything that hits the disk. A single Apache request may have many I/O operations, as it may have to access many files at the same time.

You can reduce I/O costs by:

  • Caching as much as possible in RAM (if you're using PHP, installing APC will help dramatically here)
  • Storing temporary / unimportant data on the instance's instance storage rather than EBS
  • Offloading static assets (images, JavaScript, CSS, etc.) to a CDN
share|improve this answer

Everything that goes into servering those 2500 requests/day (~15000+ to date) is set as an IO op that is, If it's an Apache host, or has a service of sorts, every time a process is launched or a log is rotated, the various libraries being loaded, files being written to are IO operations.

The cost is fairly minimal at your pace, rounding up for 3mil IO for the entire month. Charge is based on IO per second for AWS EBS - which is ~2.6million seconds in a month.

3,000,000 / 2,600,000 = 1.154 IO/s average.

This means your EBS will cost $0.26/mo at your current rate.

It's hard to project how much IO your projected number of users will be, but you can mulitply that $0.26 times X, where X is your estimated IO/s to the disk.

As mentioned in another response, you'll want to cache !

share|improve this answer
What Im afraid of is what will happen when we launch the server, we are expecting ~100-200k users. If the increase is linear I will be broke within a week. – pgsandstrom Dec 6 '11 at 16:25
There are some huge downsides to using non-EBS instances though. – ceejayoz Dec 6 '11 at 17:05
ceejayoz, that sounds worrysome. Could you elaborate or give me a good link? – pgsandstrom Dec 6 '11 at 17:15
I wouldn't call them 'huge', they just behave like a traditional server; you can't snapshot and create an AMI from them. Unfortunately you kind of lock yourself into one or the other (EBS or non-EBS) for the lifecycle of the architecture, meaning you can't make an AMI on a non-EBS and launch an EBS instance of it. EBS gives your overall architecture more flexibility (e.g.: Change instance type while retaining the EBS drive - scale up/down easier) - at any level there's some form of monetization and expenses may not look so bad as you hit that level. Ok... maybe the differences are huge >.> – thinice Dec 6 '11 at 17:17
@sandis I suggest you experiment with some low cost instance launching, AMI and EBS creation to get a feel for why EBS enables easier scaling and 'cloning'. The EC2 offerings are surely not laid out well for people to grasp upfront, but experience is the best teacher. In my opinion (and many others) EBS is the superior way. – thinice Dec 6 '11 at 17:18

If there is a database on the server, and you don't have the tables indexed properly or there isn't enough RAM to get the database loaded into memory you'll see a lot of IO traffic.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.