Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amazon Elastic File System – Production-Ready in Three Regions

aws.amazon.com

Post reply on HN
Print view View original

51–60 of 122 posts

Re: Amazon Elastic File System – Production-Ready in Three Regions

#51

Post by lucaspiller »

Corrado wrote: post #46
jakozaur wrote: post #44

Price is a bit high $0.3 GB / month vs. $0.1 GB / month for SSD EBS and even less for local storage. S3 is even cheaper $0.03 GB / month. So EFS is 10 times more expensive than S3. On I/O front also EBS (gp2) and (st1) are several times cheaper. So most of EFS advantages are in flexibility and sharing same file system across many instances. This may be great e.g. for sharing readonly binaries, but large scale data pi…

I think EFS is meant for large read-heavy patterns, at least that's what we used it for. For example, I help run an e-commerce site that has a lot of content (JS, CSS, images, etc.) that we serve up from 10 dedicated servers as well as 30 general servers. When we release new content we have to update each of the servers and make sure that everything got installed properly everywhere. With EFS, we just have to update…

Why don't you use S3 and Cloudfront to serve all the assets?

Re: Amazon Elastic File System – Production-Ready in Three Regions

#52

Post by arqq »

objectivefs wrote: post #17

Cool! If you are looking at shared filesystems on EC2, you might also want to take a look at ObjectiveFS[1]. Works in all regions and on GCS, and you can mount your filesystem securely (end-to-end encryption) between regions. [1]: https://objectivefs.com

ObjectiveFS looks awesome and I've been wanting to use it, but using non-S3 storage is locked to "enterprise, I can't afford it". :(

But I also can't afford S3's bandwidth pricing.. I could, however afford to run an S3-API compatible service myself with bandwidth pricing I could afford.

But then you wouldn't let me use it because then I'd be "enterprise".

Re: Amazon Elastic File System – Production-Ready in Three Regions

#54

Post by sciurus »

oconnore wrote: post #16
jedberg wrote: post #10

This is really cool but also kind of a shame. I feel like it will encourage bad behavior. I can see people using this to deploy code by deploying onto the shared volume so that all their instances get an "instant update". Which is great when it works, but lord help you when EFS goes down and every app server you have is hung on a broken NFS connection.

Isn't the whole point of AWS that you can blame AWS engineers for downtime instead of your own (in this case) code deployment thingy?

http://www.whoownsmyavailability.com/

Re: Amazon Elastic File System – Production-Ready in Three Regions

#55

Post by saurik »

jakozaur wrote: post #44

Price is a bit high $0.3 GB / month vs. $0.1 GB / month for SSD EBS and even less for local storage. S3 is even cheaper $0.03 GB / month. So EFS is 10 times more expensive than S3. On I/O front also EBS (gp2) and (st1) are several times cheaper. So most of EFS advantages are in flexibility and sharing same file system across many instances. This may be great e.g. for sharing readonly binaries, but large scale data pi…

> On I/O front also EBS (gp2) and (st1) are several times cheaper.

Isn't I/O for EFS free?

Re: Amazon Elastic File System – Production-Ready in Three Regions

#57

Post by jakozaur »

saurik wrote: post #55
jakozaur wrote: post #44

Price is a bit high $0.3 GB / month vs. $0.1 GB / month for SSD EBS and even less for local storage. S3 is even cheaper $0.03 GB / month. So EFS is 10 times more expensive than S3. On I/O front also EBS (gp2) and (st1) are several times cheaper. So most of EFS advantages are in flexibility and sharing same file system across many instances. This may be great e.g. for sharing readonly binaries, but large scale data pi…

> On I/O front also EBS (gp2) and (st1) are several times cheaper. Isn't I/O for EFS free?

You don't pay extra for IO on EFS and some types of EBS (like mentioned here gp2). However, for some applications you optimize your storage to get most IO per $. In that terms EFS comes with some IO capacity as well as EBS. The point is that EBS is way cheaper in that use case.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#58

Post by peteretep »

jedberg wrote: post #23
oconnore wrote: post #16

Earlier quoted context omitted.

Isn't the whole point of AWS that you can blame AWS engineers for downtime instead of your own (in this case) code deployment thingy?

I'm not sure if you're being sarcastic or not, but no, it isn't. It's to provide building blocks for infrastructure. Down time is still on you. Only a lazy engineer blames their tools for their failures.

    > Down time is still on you
If you can say "It's not our fault, it's Amazon's", there are plenty of boards and customers who are fine with that, in my experience.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#59

Post by vacri »

sciurus wrote: post #54
oconnore wrote: post #16

Earlier quoted context omitted.

Isn't the whole point of AWS that you can blame AWS engineers for downtime instead of your own (in this case) code deployment thingy?

http://www.whoownsmyavailability.com/

Hrm, so for the site 'whoownsMYavailability', the answer is someone else?

Re: Amazon Elastic File System – Production-Ready in Three Regions

#60

Post by zeisss »

jedberg wrote: post #50
Corrado wrote: post #47

Earlier quoted context omitted.

I think that deploying onto a shared volume is exactly the workload that EFS encourages. That things will stop functioning can be said about any (AWS) technology. "Lord help you when (S3|RDS|SQS|etc.) goes down and every (thing) you have is hung up on a broken (thing) connection." The rational argument here is that if uptime is important to you, the solution is to utilize multiple regions, of which EFS is now in 4. Y…

The difference is that all of those services are accessed via an API, which means your client can do clever things when it fails, like timeout, give a fallback, find an equivalent resource in another zone or region, etc. With EFS, it's exposed as NFS, which hooks in much deeper. If it goes down, there isn't anything you can do to work around the problem, unless you start hacking your own file system kernel modules.

Can't you measure and timeout on the file-descriptor writes too?
Post reply on HN