DO's "internal" networking/security group support is still immature. I use DO for personal stuff, but at work we use AWS.
Just never EBS. Ever.
Just never EBS. Ever.
I wouldn't take it that far! There is conflicting information on which between Standard EBS and Instance store performs better but there have been benchmarks to support that EBS does perform more consistently than instance store (example: http://serverfault.com/questions/111594/which-is-faster-for-...). Also, you can now launch EBS optimized instances which use a network stack intended to separate EBS I/O giving better throughput. iops is expensive but is great to have when you need it.
Sure, if EBS goes down in your zone, you're hosed. But unless you're completely independent as a service, chances are you do depend on something which uses EBS so you might be hosed anyways.
Instance store is great free storage to use. Since it needs to be mounted explicitly, I'm guessing that most people don't end up using it. Thats a shame too; so use that free storage but EBS isn't evil either.
The performance of EBS is pretty bad, and getting decent performance is expensive. Having said that, if your application runs in memory and disk usage is infrequent then it is probably fine to use EBS. EBS is also much more expensive than the instance storage, but it is also durable unlike instance storage.
On the whole, "never ever EBS" is too strong language making it incorrect. As usual, it depends.
TLDR: it's okay for backups, but in critical path it's a world of sadness. Failure modes are too painful.
Most databases have replication but you need to make sure that the characteristics of how the database handles a node failure are well understood. Worst case you use EBS, put your state on it, snapshot it regularly, and ship those snapshots to another region because when EBS fails it fails hard.
Also, logs make every machine stateful. Use something like logstash to centralize that state.
That or sidestep ELB in your region to a team of stateless load balancers that terminate SSL.
At Netflix we use Cassandra and store all data on local instance storage. We don't use EBS for databases.
It's one of those "huh, never ever thought of it from that angle" sort of ideas. The very idea of putting your absolutely valuable data on ephemeral storage and just duplicating it.
Thanks for that.
https://wiki.postgresql.org/wiki/Synchronous_replication
This way you should be able to tolerate failure of a single instance without losing data.
of course, if a comet hits the master db server, you might lose a tiny bit data (typically 0.1 seconds) if not using sync replication.
you can use sync replication for the important things that you absolutely can't lose, and async replication for everything else.
The pricing seems reasonable for the performance (I've not done benchmarks if I'm being honest), and you get to treat all your EC2 instances as expendable.
Also, on EC2, EBS-backed instances boot faster [2]. Of course, you can (and should) still treat EBS-backed instances as expendable.
[1] http://aws.amazon.com/rds/faqs/#hardware-scaling
[2] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Component...
To be honest, I didn't know RDS was backed by EBS but it makes little real difference to me as long as the backup procedures are rock-solid and the performance is acceptable.
I meant rather that is there any other option for persistent data on AWS?