4 ms·

We're contemplating moving our static image files (JPG/PNG) from an EBS volume to serving them from an S3 bucket (so we can deploy a HA setup). It sounds like i

We're contemplating moving our static image files (JPG/PNG) from an EBS volume to serving them from an S3 bucket (so we can deploy a HA setup). It sounds like it would be a lot less code if we used EFS instead. Would you guys recommend S3 or EFS for this scenario?

ceejayoz 12y ago
I don't think anyone can really recommend EFS for anything yet until it's in the wild for testing. I'd probably still store static files like that on S3 - with EFS you'd still need a server to handle the requests.
skuhn 12y ago
One thing to consider is that EFS is priced at 10x the cost of the most expensive tier of S3 storage ($0.30/Gbyte vs $0.03/Gbyte). If they are just static assets, you would do better to put them in an S3 bucket, set appropriate Cache-Control headers and serve them via Cloudfront. This reduces your outbound bandwidth cost to the Internet versus EC2/S3, and yields better performance.
ekimekim 12y ago
While there's alot of unknowns at this point, my money would be to stick with S3. Serving static files quickly is a large part of what it is designed to do. From what I'm reading here, EFS seems more geared towards shared volumes where it being a filesystem is a critical part of the interface. If you can get away with not needing a posix filesystem layer over your datastore, you should.
jdub 12y ago
If your architecture is amenable to storing files in S3, do. (And if it's a web app, ideally you'd serve them directly, via CloudFront.) EFS first and foremost will take away a huge amount of pain when trying to make filesystem-dependent legacy applications more reliable.
b1twise 12y ago
S3 is going to be a lot cheaper. It isn't perfect, but it's pretty reliable. Then you can look at cloudfront. And they did recently release cross-region S3 replication. Then you can be really safe and keep a backup copy at a whole other location.
mikey_p 12y ago
Depends, I work with a number of HA Drupal sites, and Drupal 7 can do most files in S3 but it still likes to put generated CSS/JS files and tmp files on local disk. In most of these cases (or for already existing sites) it's usually easier to just use NFS or Gluster instead of trying to force everything to S3. upstream issue: https://www.drupal.org/node/2044509 https://www.drupal.org/node/2044509

ceejayoz 12y ago

I don't think anyone can really recommend EFS for anything yet until it's in the wild for testing. I'd probably still store static files like that on S3 - with EFS you'd still need a server to handle the requests.

skuhn 12y ago

One thing to consider is that EFS is priced at 10x the cost of the most expensive tier of S3 storage ($0.30/Gbyte vs $0.03/Gbyte). If they are just static assets, you would do better to put them in an S3 bucket, set appropriate Cache-Control headers and serve them via Cloudfront. This reduces your outbound bandwidth cost to the Internet versus EC2/S3, and yields better performance.

ekimekim 12y ago

While there's alot of unknowns at this point, my money would be to stick with S3. Serving static files quickly is a large part of what it is designed to do. From what I'm reading here, EFS seems more geared towards shared volumes where it being a filesystem is a critical part of the interface. If you can get away with not needing a posix filesystem layer over your datastore, you should.

jdub 12y ago

If your architecture is amenable to storing files in S3, do. (And if it's a web app, ideally you'd serve them directly, via CloudFront.) EFS first and foremost will take away a huge amount of pain when trying to make filesystem-dependent legacy applications more reliable.

b1twise 12y ago

S3 is going to be a lot cheaper. It isn't perfect, but it's pretty reliable. Then you can look at cloudfront. And they did recently release cross-region S3 replication. Then you can be really safe and keep a backup copy at a whole other location.

mikey_p 12y ago

Depends, I work with a number of HA Drupal sites, and Drupal 7 can do most files in S3 but it still likes to put generated CSS/JS files and tmp files on local disk. In most of these cases (or for already existing sites) it's usually easier to just use NFS or Gluster instead of trying to force everything to S3. upstream issue: https://www.drupal.org/node/2044509 https://www.drupal.org/node/2044509