IMO the better way to run is with _no_ shared file system at all. Use CodeDeploy to ship the deploy files to all ec2 servers, and then use S3 to store all uploaded files. WordPress doesn't need to do any file writing outside of the `uploads` directory.

This allows you to sidestep a large amount of pain points with shared filesystems, and every ec2 server has local disk performance.

Do you have anything to say about EFS and WordPress (or other PHP CMS that are basically designed for a single instance?)

Latency on stat() - PHP is often a oop-monster these days with thousands of fs reads as it loads the code? (there are certainly ways to dodge that overhead though).

Have you seen the filesystem stall for any reason? Any caveats with concurrent writers (such as cache/ directories or generated images with deterministic paths etc).

You say without frustrating patches - are there any general limitations with using EFS?

Have you used self-managed NFS for the same purpose before? Any comparison with EFS?

We have some notes on small file performance for EFS and ObjectiveFS at https://objectivefs.com/howto//performance-amazon-efs-vs-obj... that you might find interesting. Scaling out PHP on AWS is definitively easier with a shared file system.

I have seen some users file system calls stall due to the EFS quotas.

This was on a workload much tougher than WordPress.

I haven't run my own NFS for comparison.

I recommend reading the NFS v4 spec. AWS has all the pieces to implement the protocol as well as anyone can.

I tried EFS and it seemed very slow for the wordpress site I tried to host. I didn't think EFS was meant for hosting a webserver but mainly for large files?