Q:

I/O intensive MySql server on Amazon AWS

We recently moved from a traditional Data Center to cloud computing on AWS. We are developing a product in partnership with another company, and we need to create a database server for the product we'll release.
I have been using Amazon Web Services for the past 3 years, but this is the first time I received a spec with this very specific hardware configuration.
I know there are trade-offs and that real hardware will always be faster than virtual machines, and knowing that fact forehand, what would you recommend?
1) Amazon EC2? 
2) Amazon RDS?
3) Something else?
4) Forget it baby, stick to the real hardware 
Here is the hardware requirements
This server will be focused on I/O and MySQL for the statistics, memory size and disk space for the images hosting.
Server 1
I/O
The very main part on this server will be I/O processing, FusionIO cards have proven themselves extremely efficient, this is currently the best you can have in this domain.
o Fusion ioDrive2 MLC 365GB (http://www.fusionio.com/load/-media-/1m66wu/docsLibrary/FIO_ioDrive2_Datasheet.pdf)
CPU
MySQL will use less CPU cores than Apache but it will use them very hard, the E7 family has 30M Cache L3 wichi provide boost performance :
o 1x Intel E7-2870 will be ok.
Storage
SAS will be good enough in terms of performance, especially considering the space required.
o RAID 10 of 4 x SAS 10k or 15k for a total available space of 512 GB.
Memory
o 64 GB minimum is required on this server considering the size of the statistics database.
Warning: the statistics database will grow quickly, if possible consider starting with 128 GB directly, it will help.
This server will be focused on I/O and MySQL for the statistics, memory size and disk space for the images hosting.
Server 2
I/O
The very main part on this server will be I/O processing, FusionIO cards have proven themselves extremely efficient, this is currently the best you can have in this domain.
o Fusion ioDrive2 MLC 365GB (http://www.fusionio.com/load/-media-/1m66wu/docsLibrary/FIO_ioDrive2_Datasheet.pdf)
CPU
MySQL will use less CPU cores than Apache but it will use them very hard, the E7 family has 30M Cache L3 wichi provide boost performance :
o 1x Intel E7-2870 will be ok.
Storage
SAS will be good enough in terms of performance, especially considering the space required.
o RAID 10 of 4 x SAS 10k or 15k for a total available space of 512 GB.
Memory
o 64 GB minimum is required on this server considering the size of the statistics database.
Warning: the statistics database will grow quickly, if possible consider starting with 128 GB directly, it will help.
Thanks in advance.
Best,

A:

In order to get maximum performance from a cloud solution you need to architect for a cloud.  If you are worried about how many IOPS you can get from a service that's designed to be fully scalable (both up and down) You are thinking about virtual machines not cloud computing.  As far as the amount of IOPS available, I think this article on EBS explains the issues to consider

A:

The problems:

The two servers you have listed above are absolutely identical.
You talk about FusionIO but you also talk about running MySQL and Apache on the same box.
You don't mention whether the Apache files or the MySQL database (or parts of it such as the ib_logfile) will be on the FusionIO drives.

The misconception:
It's not necessarily true that "real hardware will always be faster than virtual machines".  It is true that on the same hardware the same application will perform better for not being in a virtual machine but since you don't have access to Amazon's hardware, that comparison is moot.
The point about the cloud is that it scales horizontally, so if you can serve 100 simultaneous visitors with one server, you can serve 1000 simultaneous visitors with 10 servers and each visitor receives the same speed of response, no matter how many of them you have.
The cloud:
There are a few key differences with cloud providers compared to colocation.  If you are able to take advantage of them, they will make hosting in the cloud a clear winner.

You can spin up and down instances very quickly.  If your traffic is very bursty (say, you run a ticket sales website) then you can very easily clone your web tier, database tier and/or storage tier out to hundreds of virtual machines an hour before the Justin Bieber tickets go on sale and shut them all down an hour after to save on money.  Hardware based solutions will usually take weeks to increase your capacity and they continue costing money when they aren't being fully utilised.
The up-front cost can be much lower.  The hardware you mention probably costs tens of thousands of dollars in addition to your other hosting costs.  My Amazon server costs me about $15 per month and yet I could easily scale it up to a much more beefy virtual machine and scale it out to dozens of load-balanced instances with an hours notice.
They do a lot of the work for you.  Amazon have other services such as DynamoDB which automatically scale out or in to the workload or storage requirements you give it.  They run in SSDs for speed and are replicated to multiple places giving you redundancy and availability.

That said, your application has to be capable of scaling horizontally.  You can't simply throw it into the cloud and expect it to scale forever.  For instance, default PHP sessions have two problems:

They are stored on a local disk meaning you either need to use sticky sessions or a shared disk which will be a bottleneck.
They are opened with flock() which is an exclusive, blocking file lock.  Only one PHP process can be using a session file at a time.  This can be a serious problem when you start firing off lots of AJAX calls.

This is only a single example but applications that have not been written with horizontal scaling in mind are usually full of exclusive resources like that one.
If you are running a distributed database (which Amazon's database services are) then your app also needs to be able to deal with the trade-offs inherent in the CAP theorem.  This states that you can get two of the three aspects: Consistency, Availability, Partition tolerance.  You will need to know which of the three you don't have and have your app compensate for it.
If your application suits hardware, go for hardware.  If it suits the cloud, go for the cloud.
Note: I have used Amazon as an example here but there are other cloud hosting providers with similar capabilities of spinning up and down instances very quickly and only charging you for what you actually use.

