IOPS isn't important for glacier. You just upload to some buffer and the eventually move it to the slow storage.
Reading is pretty slow from glacier.
Reading is pretty slow from glacier.
If Amazon has that problem with EBS, then selling that storage capacity as Glacier and using just the idle IOPS (or leaving a small bit reserved) allows them to sell capacity that would otherwise just be useless.
So if you use a lot of IO with Glacier, they are going to charge you like crazy, since you're potentially impacting EBS customers.
With exchange, we had all of this expensive, reliable SAN storage that would be perfect for a low requirement glacier like solution. Unfortunately, we lacked the ops mojo to pull it off.
for example I used to look after a quantum iScaler 24 drive robot, each drive was capable of kicking out ~100 megabytes a second. It was more than capable of saturating a 40 gig pipe.
However random IO was shite, it could take up to 20 minutes to get to random file. (Each tape is stored in a caddy of (from memory) 10 tapes, There is contention on the drives, and then spooling to the right place on the tape.)
Email is essentially random IO on a long tale. So, unless your users want a 20 minute delay in accessing last year's emails, I doubt its the right fit.
The same applies to Optical disk packs (although the spool time is much less.)