首先，我对 AWS 还很陌生，所以请耐心等待。
我已经运行了一个实例几个月了，现在我需要自动扩展它，因为我的流量峰值越来越大，有时它会超载。
所以，让我回顾一下我到目前为止所做的事情，你们可以告诉我哪里做错了，以及我应该做些什么不同的事情。
- 首先，我创建了一个负载均衡器，上面有一个主实例，称之为“实例 A”
- 接下来，我在“实例 A”上创建了两个 CloudWatch 警报，用于监控 CPU 负载。接下来，我创建了“实例 A”的映像
- 接下来我创建了一个启动配置链接到我新创建的 AMI。
- 接下来我创建了一个自动缩放组并将其链接到我的负载均衡器，同时设置了我之前设置的两个缩放警报。
- 我将 AutoScaling 组最小值设置为 0，最大值设置为 3，因为我只希望它在我的原始实例（实例 A）超出容量时开始启动实例。
因此，基本上我希望我的原始实例始终处于运行状态。然后，当它开始超出容量时，我希望 Auto Scaling 组开始启动实例，并让负载均衡器在它们之间分配负载。我的想法合理吗？
其他重要问题。
当我对原始实例进行代码和数据更改时，是否必须重新制作启动配置使用的图像？
DNS 名称和 IP 需要做什么？我目前正在使用 Route 53，我是否应该将其指向我的负载均衡器，仅此而已？
多谢你们！
答案1
让我们来回顾一下您的问题。
因此，基本上我希望我的原始实例始终处于运行状态。然后，当它开始超出容量时，我希望 Auto Scaling 组开始启动实例，并让负载均衡器在它们之间分配负载。我的想法合理吗？
我会说是的，但我有几个保留意见。如果我理解正确的话，您已将“主”实例放在自动缩放组之外。从理论上讲，这将确保自动缩放不会杀死您的原始实例。我想提几件事：
- 您没有充分利用 Auto Scaling 的可能性。Auto Scaling 不仅使您的设置能够扩展，还可以确保限制。如果出于某种原因，您的“主”实例死亡，您的自动扩展策略将不会生效。如果您将实例保留在具有
min-size1 的自动扩展组中，Auto Scaling 会自动替换失败的实例。 - 在自动扩展时，最佳做法通常是将实例视为“一次性的”，因为这是构建弹性系统的方法。不要依赖于一个实例始终可用。
- 您可以为自动扩展组设置终止策略，以便它始终首先终止最新的实例。这将确保您的“主”实例得以保留（只要它运行正常）。不过，我之前的评论仍然适用。
当我对原始实例进行代码和数据更改时，是否必须重新制作启动配置使用的图像？
我会说不，但这更多的是一个设计问题。您的图片应该描述状态但它不应该负责代码分发。考虑这样一种情况，由于紧急错误，您必须更新应用程序，但您的服务器负载很高。更新主服务器、创建 AMI、更新启动配置并关闭自动扩展服务器，以便它们可以使用最新的 AMI 重新生成，这听起来像是一个有吸引力的解决方案吗？我的答案是不（再次）。查看源代码版本控制和部署策略（例如，我 60% 的时间都是 Rails 开发人员，并使用git和）。capistrano
在某些情况下，您的方法同样有效，并且这里有很多折衷方案（我建议也研究Chef和userdata脚本）。我自己实际上很少使用自定义 AMI，这要归功于Chef。
DNS 名称和 IP 需要做什么？我目前正在使用 Route 53，我是否应该将其指向我的负载均衡器，仅此而已？
基本上，是的。您可以在创建自动缩放组时选择应附加到新实例的负载均衡器。我还没有使用 GUI 进行自动缩放，但我很确定它在那里的某个地方。如果没有，CLI 仍然支持它。将您的 Route53 记录指向您的 ELB alias，基本上就是这样。
补充问题回复（2014/02/23）：
如果你使用 Rails 进行开发，我强烈推荐卡皮斯特拉诺用于部署，可以使用您首选的版本控制系统（如 git）中的特定版本的应用程序，并将其部署到特定环境中的多个服务器。有很多教程，但 Ryan Bates 修订的（和专业的）Railscasts 关于这个主题非常简洁，尽管您需要订阅他的网站才能观看这两个教程。不过，大多数其他教程也可以让您入门。使用您的 AMI 和启动脚本启动一个新服务器，该脚本会提取您的 git repo 的临时克隆并运行本地 Capistrano 命令以启动您的应用程序。这确保了，稍后，您也可以使用 Capistrano 向所有正在运行的服务器部署应用程序的新版本，只需一个命令即可。
Capistrano 还提供其他一些好处，包括使您能够在所有或仅一台服务器上执行特定任务并回滚部署，而这仅使用 git 很难实现。