In terms of IO, it has little to do with the instance size except for the bandwidth available to you. To explain, when you are using EC2/AWS that means you will be using EBS for storage, and so using the network to persist your data. As such the recommendation is to use RAID 10 across multiple volumes to allow you to stripe (performance), mirror (redundancy) and fail out a bad volume (otherwise your array is as slow as whatever the slowest disk is) if one of the EBS volumes has a bad day (it happens, trust me).
Per this whitepaper (which will be updated with new info soon), an EBS volume can provide
approximately 100 IOPS, and single instances with arrays of 10
or more attached EBS disks can often reach 1,000 IOPS sustained
If you use a provisioned IOPS instance then that all changes, of course, and it also means that you get a dedicated network interface for IO, removing any contention with your normal traffic on the host.
The final remaining option are the SSD based instances, which far outstrip even the provisioned IOPs capabilities, but there is quite a price difference to go along with them.
Generally with MongoDB you will end up sizing based on RAM (keeping your working set in RAM is usually considered paramount, if possible), but if you can't and you need to hit disk regularly, then the amount you can squeeze out of EBS will be important.
I recently presented an overview of all this, with an AWS focus at the recent Sydney/Melbourne MongoDB events. You can find the slides here:
http://www.10gen.com/presentations/mongodb-sydney-november-2012/operating-mongodb-cloud