Hacker News new | comments | show | ask | jobs | submit login

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.

What's wrong with EBS? And for what usage?

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.

Only use EBS when you absolutely have to, and fail gracefully when EBS fails.

From what I've seen/heard/experienced, Provisioned IOPS largely addressed the issues with inconsistent performance.

Yes but it is very expensive.


TLDR: it's okay for backups, but in critical path it's a world of sadness. Failure modes are too painful.

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.

How do you even do anything without using EBS?

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.

And you do what for loadbalancing?

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.

IIRC, Amazon has been working on removing the ELB dependence on EBS. I haven't seen an announcement of them being done, though.

Exactly - how can I run a database server without EBS?

By having good replication, either hand rolled or built in.

At Netflix we use Cassandra and store all data on local instance storage. We don't use EBS for databases.

Jedberg... this single post blew my mind. :)

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.

Run multiple replicas with synchronous replication. For Postgres see:


This way you should be able to tolerate failure of a single instance without losing data.

we do async replication with good monitoring of the slaves to make sure the slaves don't get too far behind. couple that with wal-e.

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.

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.

If you're eschewing EBS because of past problems (like the Oct 2012 outage), you should be aware that RDS is EBS-backed [1].

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...

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.

Sure - but I'm assuming RDS uses EBS under the covers...

I meant rather that is there any other option for persistent data on AWS?

As others pointed out, you use EBS then.

I think Cassandra is what all the big guys use. Apple, Netflix, etc.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact