我有一个 WordPress 网站，截至目前，我完全在Amazon Lightsail实例上运行。它得到了正确的备份；可用性还可以；安全性好；这是一个易于维护的简单设置。没关系。
我想通过将站点移至Amazon Elastic Beanstalk并对站点的后端进行一些其他重大更改（使站点数据库独立于 PHP 服务器、移至 nginx 等）来提高可用性和加载时间。这有很多好处，其中最主要的原因是：EBS 只是比 Lightsail 更强大的服务器设置。
在亚马逊提供的教程创建魔豆上一个WordPress站点只建议安装/wp-content/uploads/上的亚马逊弹性文件系统，默认的配置脚本这样做的客户。这样做的缺点是核心 WordPress 文件不会在 EC2 实例之间共享；相反，它们会在每个实例上复制，因此在您的站点上运行 WordPress 更新过程意味着某些实例实际上并未更新，从而产生不良行为。
本教程建议通过使用 WordPress 的（测试版）导出工具导出所有网站内容并在运行的新 Beanstalk 环境中使用（测试版）导入工具重新导入它的可怕过程来更新 WordPress（和插件）。更新了 WordPress。
我并不完全反对自动化这个过程，以便更新 WordPress 对我来说更容易，但我重视保持最新的更新，所以我想为此进行优化，我怀疑这对我（或任何客户）来说是最好的解决方案是在更新系统或插件的过程中使用 WordPress 的 beta 导入导出工具。
例如，有时这些更新是 WordPress 为其提供自动修补系统的安全更新，这对于最大限度地提高站点安全性非常理想。但是，如果由于我已经概述的更新挑战而未在 EC2 实例之间共享核心 WordPress 文件，则自动修补将无法按预期工作。
综上所述：
如果我将所有 WordPress 文件（而不仅仅是/wp-content/uploads/目录）放在共享 EFS 存储上，我可能会遇到哪些架构或系统问题？
当然，我会进行自己的测试以了解事情的进展情况，但我想知道要注意什么（如果有的话），以及在尝试这样做时应该在哪里设定我的期望。