I have a WordPress site that, as of now, I am running completely on an Amazon Lightsail instance. It gets properly backed up; availability is okay; security is good; it's a simple setup to maintain. It's fine.

I want to improve availability and load times by moving the site to Amazon Elastic Beanstalk and doing some other major changes to the site's backend (making the site database independent from the PHP server, moving to nginx, etc.). This would be good for a multitude of reasons, chief among them: EBS is just a more robust server setup than Lightsail.

The Amazon-provided tutorial for creating a WordPress site on Beanstalk advises to mount only /wp-content/uploads/ on an Amazon Elastic File System, and the default configuration script does so for the customer. The downside to doing this is that core WordPress files do not get shared between EC2 instances; they are instead replicated on each instance, so running the WordPress update process on your site means that some instances don't actually get updated, yielding undesirable behaviors.

The tutorial advises to update WordPress (and plugins) by going through an awful process of exporting all site content with WordPress' (beta) export tool and re-importing it with the (beta) import tool on a new Beanstalk environment that is running the updated WordPress.

I am not strictly opposed to automating this process so that updating WordPress is easier for me, but I value staying current on updates, so I want to optimize for doing that, and I am skeptical that the best solution for me (or any customer) is to use beta import and export tools for WordPress in the process of updating the system or a plugin.

For example, sometimes these updates are security updates for which WordPress offers an automated patching system, which is highly desirable for maximizing site security. However, that automated patching wouldn't work as expected if core WordPress files are not shared between EC2 instances because of the updating challenge I already outlined.

With all of this said:

What architectural or systems issues might I encounter if I put all of my WordPress files — not just the /wp-content/uploads/ directory — on shared EFS storage?

I will, of course, do my own testing to see how things go, but I want to know what to look out for, if anything, and where to set my expectations as I attempt to do this.

  • I would be wary of EFS latency. I would want the instances to cache the EFS file system. What happens if multiple instances decide to upgrade WordPress at the same time? Probably bad things. It would be interesting to try.
    – Tim
    Nov 20, 2019 at 21:07
  • Same question as @Tim above, I am extremely curious if WordPress is designed to share state of the core PHP files like that. Is this maybe a case of where the AWS solution involves updating a golden image and then relaunching your instances? Nov 26, 2019 at 17:47
  • I suspect update collisions could be avoided by disabling wp-cron updates and instead triggering them (on one server) using an external cron service like easycron. WordPress is supposed to have a built-in locking mechanism to prevent this, but because of object caching it doesn't always perform as it should.
    – Typel
    Dec 6, 2019 at 20:56
  • I was also investigating AWS for Wordpress and I found this discussion that says that EFS is not performant for this use case (which was my fear).
    – collimarco
    Apr 29, 2020 at 17:23
  • OP so what did you decide to do regarding this? I'm storing the entire /var/ww/html folder on EFS and share them between a few instances, and the performance isn't great. I couldnt pin point the issue to EFS or anything within this stack.
    – Casper
    Oct 16, 2020 at 18:17

1 Answer 1


(Beware: I'm no expert, but was looking for an unanswered question so I could give back to serverfault.com)

I would first pursue scaling Lightsail. The docs (https://aws.amazon.com/lightsail/features/) discuss having multiple instances with a load balancer. Have you tried that? Check out the CloudWatch monitoring to see how busy your instances are. Horizontal scaling may buy you faster response times. Also, you can expand Lightsail to use stand-alone database instance(s).

In my mind, Word Press is a beast when it comes to computational efficiency. It can load a hundred scripts to execute a single request. Trimming down can help. Any un-needed plugins? Can code be combined into a fewer number of modules? There are probably optimization/profiling tools for it that could help you speed up your site.

Also, consider how much of your site is static file serving vs computational. Offloading static files to AWS S3 is a great solution. Also, implementing a CDN cache (AWS CDN, for example) can give you faster response times on non-computational page loads, as well as potentially moving the content closer to where your users are located. And, lastly, but often overlooked is just how many HTTP requests your users need to make to load a given page. Do you have many JS libraries that need to get loaded? Consider consolidating them into one file that can be loaded in a single transaction. Using the browser Dev tools in Chrome or Firefox can really help you pin-point where the delay is coming from.

If you want to go with the manage your servers approach, then updating WP can be done in simpler ways. I would suggest you start using Docker containers. You can then simply have one image you run on N servers and keep each one up to date. Use AWS ECR for your image. When you want to update WP or plug-ins, you build a new container image version. Then use AWS EKS or Fargate to allow you to roll out the new version in a rolling fashion. This is all part of the pets vs. cattle topic. You don't do maintenance on individual servers (containers), but if there is a change, you throw away the old and deploy new ones.

But, after all this, if you still want to go the route of common storage, I would not suggest you use EFS. You don't get security with that. Instead, I would run an S3 file cache on each server. It will pull files locally whenever they are changed in S3, so everyone gets the changes. Example cache is https://github.com/s3fs-fuse/s3fs-fuse/wiki/Fuse-Over-Amazon .

I would do testing to see if there are any writes to the WP files when in operation. If there is and what is written is instance dependent, you are going to have to keep those directories as local on the server.

  • 1
    I am interested to know where the idea that EFS does not provide any security comes from. Do you have specific experience to suggest that these systems (specifically AWS EFS) do not provide an adequate level of security? Given that "Security and compliance" (including encrypted store and transit) is one of its touted selling points, and that it ties in with AWS' IAM policies, I wonder if this statement has merit or is more a matter of opinion?
    – Typel
    Jan 15, 2020 at 21:20
  • EFS is NFS storage. It can be secured to only support in-VPC access. However, that would be useless for a website to serve outside traffic. So, NFS would have no secuirty - anyone could mount the NFS file system. Jan 16, 2020 at 1:13
  • 1
    If you set up EFS inside a VPC, why couldn't you then set up an EC2 web server in the same VPC to mount the EFS into a public web directory (with proper file permissions) in order to serve the contents? I don't see how else you could share runtime-generated configuration and cache files between multiple servers.
    – Typel
    Jan 16, 2020 at 19:57
  • Yeah, you are right. I was thinking in terms of serving static files. Jan 17, 2020 at 15:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.