我pipe理的网站基本上只是一个由WordPress驱动的新闻/博客。 网站上的平均用户数在8-15之间。 但是我们偶尔会在1.5-5,000人的任何地方突破新闻。 直到今天，我们通过Dreamhost在VPS上托pipe网站。 我们转移到了AWS / EC2，因为我认为可扩展性会很好。
我备份了我们的整个服务器，启动了一个EC2实例（ 由Bitnami为AWS运行WordPress的 t2.micro），为它创build了一个存储驱动器，给它一个弹性IP，迁移并恢复了所有数据（使用UpdraftPlus）。 当时我很高兴服务器正常运行，取下了我们以前的服务器，并创build了一个指向AWS实例的IP的DNSlogging。
但是，今天我们遇到了一个问题，即CPU的利用率达到100％，而CPU Credits仍然可用。 我认为可用的CPU信用会扩大服务器，以便它不被100％的使用挂钩。 我想我误解了。 所以我想我需要设置一个自动缩放组。 所以我从我已经安装的实例创build了一个AMI，创build了一个启动configuration，并创build了一个负载平衡器。 然后，我将自动缩放组设置为1个Desired，1个最小和5个最大实例，以在CPU => 85％时启动实例，如果CPU = <35％则设置为1。
我认为这样会很好，但是我遇到了一个问题，就是我曾经设置过这个问题。 它终止了我之前设置的实例，并把整个网站closures。 然后我惊慌失措地跑来跑去，直到我意识到它并没有删除存储空间，我又启动了另一个存储空间，并附加了这个驱动器。
我在这里错过了什么？ 我如何设置AWS / EC2来处理几千个用户使用完全相同的数据/网站，并始终拥有它，而不是终止我的原始实例？
任何帮助将不胜感激。
AWS上更多的阅读和在生产之外进行练习将是一个好主意。 有很多指南，AWS本身提供了很好的信息，并不难。 在生产站点上工作之前，您应该在另一个VPC或区域进行testing。
t2.micro仅限于一个核心，无论CPU信用如何。 根据警报/监视间隔，自动缩放需要一定时间。 您可以将现有的实例添加到elb中，但是我倾向于将其设置，添加它们，然后添加它自己的实例并停止原始实例。
一个自动缩放组，“黄金”AMI和RDS将是最简单的select。 但是，你可能会得到不同的WordPress版本，所以这需要更多的思考。 您可以在Web服务器级别设置caching，Nginx非常优秀，可以极大地降低您的负载 – 至less降低一个数量级。
我有一个教程，可能在这里有一些用处。 它并没有进入自动缩放，因为我自己并不需要它，但设置很简单 – 我已经做了很多次了。
当您开始使用Auto Scaling时，您需要习惯于一个事实：EC2实例将启动，EC2实例将终止。 即使Min = Max = 1，您的实例也可能随时终止并被replace。 不要把这看成是一件坏事，只要习惯了，就一起玩吧。 从长远来看，这是一件非常好的事情。
要开始Auto Scaling，您需要将您的数据库移出Auto Scaled实例。 数据可以在另一个EC2实例上，也可以在RDS实例上。 不要紧。 但是它不应该在启动和终止的EC2实例上。 这有两个主要原因：
一旦你的数据离开EC2实例，你将设置一个“主”EC2实例。 这个“主”将是您从SSH（或RDP）从代码/版本angular度更新您的WordPress网站的EC2实例。 它将会终止99％的使用寿命。 当您更新WordPress网站的版本或代码时，唯一的目的是生成一个新的AMI图像。 您：
如果可以，我会build议如下：
这样，您就没有一个EC2实例，如果发生故障，整个站点都将停止运行。
还有其他一些处理Auto Scaling，更新等的方法。但是对于初学者来说，上面的框架很容易包装你的头脑。