Regarding the storage: In addition to SSDs, you should probably consider IOPs and the effect of Local disks too, if your frequency of reads/writes is high.

Persistent Storage

Normally, one would use persistent storage. These drives are network-attached, and not connected to the physical hardware of your server. On AWS, this is called EBS and on Google Compute Engine, this is called Persistent Disks. If you terminate the server or the server fails, the drive remains and data is not lost.

But since it is network-attached, the performance is bad. For example, a 100GB disk on EBS can give only upto 300 IOPs on AWS, with similar numbers on Google Compute Engine. That's the price you pay for a more reliable storage.

In AWS, you can use something called Provisioned IOPs to increase performance, but the cost is prohibitive. In GCE, the only way to get better IOPs is to increase the disk size, so, even if you need only 100GB, you'll have to create a server with 1000GB to get a decent 3000 IOPs.

Local Storage

In contrast, local storage gives 10 to 20 times the performance (I have gotten upto 10,000 IOPs). These are SSDs attached to the hardware where your VM runs, so accessing it doesn't need the network. That's why they're fast. That's also why they're not persistent, but why do we care? We anyway are going to run MongoDB in a Replica Set, thus managing the reliability of storage ourselves.

A MongoDB cluster doesn't need persistent storage. Local storage is ideal.

In AWS, this kind of storage is called Ephemeral storage, but it's not available or of limited size on most modern instance types. No good. In GCE, it's called Local SSD, but it comes only in increments of 375GB, costing $80 per month. Too expensive for me.

That's why I like Digital Ocean to run my MongoDB cluster. Storage is always local and it's inexpensive!

And we come to this topic again! :P I swear, I love this!