Service ecosystem (S3, RDS, SQS, VPCs, Cloudsearch, Elastic Transcoder, to name a few), long-term stability, reliability, support, the ability to peer directly with AWS to name a few.
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.
Most of AWS's major outages have been related to EBS. Although outages can happen to any hosting provider, and I am sure they have fixed the previous issues. So EBS should get more stable over time and it is already quite stable.
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.
It went down in 2012 and somehow rather than get the correct idea from that (everything breaks) people took this bizarre notion that EBS is bad and everything else has perfect reliability. In reality, tons of other AWS services run on top of EBS, including load balancers. When EBS fails again, the people thinking they are avoiding it will still have outages.
Well, you break your services out onto stateless and stateful machines. After that, you make sure that each of your stateful services is resilient to individual node failure. I prefer to believe that if you can't roll your entire infrastructure over to new nodes monthly then you're unprepared for the eventual outage of a stateful service.
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.
If ELB is down in a given region then DNS failover to another region. Assuming you feel comfortable rolling your entire infrastructure monthly, have good images / configuration management, and have the state replicated in the backup region.
That or sidestep ELB in your region to a team of stateless load balancers that terminate SSL.
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.
But the thing people are needlessly concerned about with EBS is full datacenter failure. Which is just as much a problem for those EC2 instances. Synchronous replication to another data center is a massive performance killer.
We use RDS (they now support Postgres) and Elasticache.
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.
Just to clarify: I don't eschew RDS because of outage issues, I use RDS because it's much easier to set up and manage compared to doing it yourself.
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 find it bizarre that Amazon put so much effort into pushing the idea theat their killer feature is price. Plenty of people outflank them on price. What's best about Amazon it their tooling. They have hands-down better tooling than their competition.
I use gandi for my personal stuff (because I'm less bothered by the French government spying on me than the US one) and it's much cheaper than Amazon. But in terms of being able to easily mass-manage a complex environment? Not even close. DO? Don't make me laugh.
> I find it bizarre that Amazon put so much effort into pushing the idea theat their killer feature is price. Plenty of people outflank them on price.
This is the Southwest Airlines model. Tell everyone you're great on price often enough, even if it's not always true, and plenty of people will think you're good on price.
With Digital Ocean, you only get almost bare VPS hosting (which is not bad per-se, I use them for a couple of personal projects), as with AWS, I get 1-click solution for pretty much anything I need, from S3 and Cloudfront, to Elasticache, hosted PostgreSQL, Route 53, OpsWorks, and numberous others.
The EC2 C3 instance type is going to be about the same price as DO for 1 year reserve and less than DO for 3 year. Spot pricing will also be lower than DO for C3s. On top of that EC2 is far superior to DO in many ways: EBS off instance storage (DO is local storage only), volume snapshots, IPv6, load balancing, private IPs, multiple IPv4 addresses, 8 data centers globally, firewalls, VPN, VPC, PCI DSS compliance, companion services like S3/CloudFront/Route 53 and much higher default quotas just to mention a few. DO is essentially a VPS with utility pricing.
