This is a filesystem. You mount it directly inside your EC2 boxes and work with it as if it's local (or really NFS-mounted). It's going to be a couple of orders of magnitude faster, but not directly web-connected, so you can't use it to serve content directly as if it was a CDN.

I can see this being useful for a few cases. For one, I can immediately use it for one of the projects I have where I have multiple worker servers and one of them needs to periodically process a few GB's of data, yet I don't want to give that much storage to every sever, and I don't want to make any one server special.

Another use case: you don't know how big your data will grow, yet you want to access it in a random fashion. S3 isn't great for this, but NFS is, and unlimited mounted storage is nice.

Edit: Third use case is logs. You can collect all the logs from all of your servers in one place and access them from any server.

Okay, thanks for the explanation!

I think they're meant to solve different problems. On one hand S3 is designed for (among other things) serving files over the web. EFS sounds like it's designed to be used as a filesystem multiple instances can write to (say for a high-availability setup).

this is the only real use-case IMO. Multiple instances being able to read/write to a single FS. Anything less would be a disappointment.

EFS which appears to be similar to NFS is built into the kernel. Read, write, stat and etc do not need to be wrapped into http calls.

One nice thing would be hosting wordpress on multiple EC2 servers. All local copies of your wordpress directory would be kept in sync automatically with no other configuration.

Yeah, I have a WP Multisite cluster that's a real pain to manage for this reason. Probably will be my first use of EFS.

How do you manage it now? Plugin? S3?

Our uploads folder is an s3fs mountpoint with a custom plugin to rewrite URLs to a CloudFront distribution in front of it.

The rest gets updated on a dev server then deployed to the auto-scaling group via an AMI.