4 ms·

The only time it makes sense to use EFS is when you want to have multiple servers with concurrent, consistent read+write access to a shared network filesystem.

by re 3y ago

The only time it makes sense to use EFS is when you want to have multiple servers with concurrent, consistent read+write access to a shared network filesystem. That's an expensive architectural decision that's best avoided if at all possible, to be sure; personally, I would prefer not to build a service that takes a dependency on EFS. But comparing it to "just" using an SSD with some sort of replication is kind of silly. https://aws.amazon.com/efs/when-to-choose-efs/ https://aws.amazon.com/efs/when-to-choose-efs/ If thought-experimenting a cheaper alternative to EFS, remember to include: - Continuous availability to the filesystem without data loss if you lose a data center - Close-to-open consistency semantics https://docs.aws.amazon.com/efs/latest/ug/how-it-works.html#consistency https://docs.aws.amazon.com/efs/latest/ug/how-it-works.html#...

solatic 3y ago
> concurrent, consistent read+write access to a shared network filesystem I don't think this is an "architectural decision", more a hold-over from legacy systems that had NFS dependencies. Main (public) example that comes to mind is Jira Data Center: https://confluence.atlassian.com/adminjiraserver/running-jira-data-center-in-a-cluster-993929598.html https://confluence.atlassian.com/adminjiraserver/running-jir... If the business made a decision to buy it, then you need NFS, and EFS can fill that. In this sense, I think of EFS as being in the class of AWS products like Amazon MQ for RabbitMQ - the architectural decision was made outside of the context of your company's stack, but AWS still has a managed offering to support it. Modern systems will typically pick S3 instead, as it's much cheaper. I'd be hard-pressed to imagine a need for which NFS is a reasonable modern decision in greenfield development.
pat2man 3y ago
You could compare a 5 node ceph cluster for instance. That’s 5 servers and 3 nvme drives minimum just to store your first byte. Then you have to deal with support, etc. pricing probably comes out about the same in the end.

by re 3y ago

solatic 3y ago

> concurrent, consistent read+write access to a shared network filesystem I don't think this is an "architectural decision", more a hold-over from legacy systems that had NFS dependencies. Main (public) example that comes to mind is Jira Data Center: https://confluence.atlassian.com/adminjiraserver/running-jira-data-center-in-a-cluster-993929598.html https://confluence.atlassian.com/adminjiraserver/running-jir... If the business made a decision to buy it, then you need NFS, and EFS can fill that. In this sense, I think of EFS as being in the class of AWS products like Amazon MQ for RabbitMQ - the architectural decision was made outside of the context of your company's stack, but AWS still has a managed offering to support it. Modern systems will typically pick S3 instead, as it's much cheaper. I'd be hard-pressed to imagine a need for which NFS is a reasonable modern decision in greenfield development.

pat2man 3y ago

You could compare a 5 node ceph cluster for instance. That’s 5 servers and 3 nvme drives minimum just to store your first byte. Then you have to deal with support, etc. pricing probably comes out about the same in the end.