AWS Auto Scaling Groups 实战入门：用 devops-exercises 从零搭建弹性 Web 集群

• 文档
• 教程
• DevOps
• 运维

Auto Scaling Groups（ASG）是 AWS 实现弹性伸缩的核心服务，它把一组 EC2 实例当作一个逻辑单元进行统一管理，自动维持实例数量、替换不健康实例，并配合伸缩策略应对流量波动。本文以 devops-exercises 仓库中的 Auto Scaling Groups Basics 练习 为骨架，结合 官方题解 与仓库内 AWS 知识库 的问答部分，带你走完「创建启动模板 → 创建 ASG → 验证期望容量变化 → 配置动态伸缩策略」的完整链路，读完后你将能独立在 AWS 控制台搭建一个具备自愈与自动扩缩容能力的 Web 服务器集群。

练习目标与前置条件

该练习（topics/aws/exercises/auto_scaling_groups_basics/exercise.md）设定的前置条件是环境中零 EC2 实例运行，以保证观察结果不受历史实例干扰。目标分为四步：

• A：创建一个面向 Web 服务器的伸缩组，使用 Amazon Linux 2 AMI、t2.micro实例类型，并通过 user data 完成 httpd 的安装与自启：

yum install -y httpd systemctl start httpd systemctl enable httpd

• B：观察创建 ASG 后是否自动产生了新实例？有几个？为什么？
• C：把 desired capacity（期望容量）改为 2，观察是否会启动更多实例。
• D：再把 desired capacity 改回 1，观察这一操作的结果。

这套目标精准地围绕 ASG 最核心的三个容量参数展开：minimum（最小容量）、desired（期望容量）、maximum（最大容量）。ASG 会持续把运行中的实例数拉回到 desired 值：当实际数量少于 desired 时扩容，多于 desired 时缩容。

提示：仓库 AWS 目录的 README 明确建议，练习虽以控制台操作给出题解，但生产环境推荐使用 IaC（如 Terraform、Pulumi）来落地。本文先讲清控制台全流程，再给出基础设施即代码的补充思路。

第一步：创建启动模板（Launch Template）

ASG 本身不包含实例的任何配置信息，它依赖**启动模板（Launch Template）**或已废弃的 Launch Configuration 来定义「新实例长什么样」。启动模板保存了 AMI、实例类型、密钥对、安全组、user data 等启动参数，这样每次扩容时不必重新指定。

题解中的控制台路径（见solution.md）如下：

1. 进入 EC2 服务，在左侧菜单Auto Scaling → Auto Scaling Groups，点击Create Auto Scaling Group。
2. 填入伸缩组名称后，选择Create a launch template：
   • 给模板命名并指定版本号；
   • 选择Amazon Linux 2AMI；
   • 实例类型选t2.micro；
   • 选择密钥对（Key pair）用于 SSH 登录排障；
   • 附加一个安全组（需放行 HTTP/80 入站流量，方便后续验证 Web 服务）；
   • 在Advanced区域的 User data 中粘贴如下脚本：

yum install -y httpd systemctl start httpd systemctl enable httpd

• 点击Create完成模板创建。

关于 User data 脚本，仓库中 launch_ec2_web_instance 练习 给出了更完整的变体，可以作为对照理解：

yum update -y yum install -y httpd systemctl start httpd systemctl enable httpd echo "<h1>I made it! This is awesome!</h1>" > /var/www/html/index.html

三条核心命令各司其职：yum install -y httpd安装 Apache Web 服务器；systemctl start httpd立即启动服务；systemctl enable httpd让服务在实例每次开机后自动拉起——这一点对 ASG 尤其重要，因为扩容产生的实例是全新机器，若服务未配置自启，新实例进入服务后不会真正对外提供服务。User data 只在实例首次启动时执行，这就是 AWS 语境下的「Bootstrapping（引导启动）」：用脚本在机器首次启动时完成软件安装与系统配置。

从源码结构看，Launch Template 相比旧式 Launch Configuration 的优势在仓库问答中也有总结（topics/aws/README.md的 Launch Template 章节）：LC 每次更新配置都必须重建，而模板支持多版本管理、可同时供给 On-Demand 与 Spot 实例、支持创建参数子集用于复用与继承。

第二步：创建 Auto Scaling Group

回到创建向导，继续完成伸缩组的配置：

3. 选择刚创建的启动模板，点击Next。
4. 选择Adhere to launch template（严格遵守启动模板），即不覆盖模板中的任何配置。
5. 选择要在哪些**可用区（AZ）**中启动实例，点击Next。跨多 AZ 部署是 ASG 高可用的关键：单 AZ 故障时，其余 AZ 中的实例仍可继续服务。
6. 将 ASG 关联到ALB（Application Load Balancer）（如果没有，先创建一个）。关联后，ASG 会把新实例自动注册为目标组中的健康目标，流量才能被分发到扩容出的实例上。
7. 在健康检查类型中，勾选ELB 健康检查（在 EC2 健康检查之外叠加）。这是生产环境的标准配置：EC2 层面的健康检查只关心实例「活着没有」，而 ELB 健康检查会实际探测应用端口/路径，能发现「实例活着但应用已挂」的情况，触发 ASG 替换不健康实例。
8. 一路点击Next直到 Review 页面，点击Create auto scaling group。

关于 ALB 的细节，仓库 Application Load Balancer 练习 演示了如何创建目标组并配置健康阈值（如 healthy/unhealthy threshold = 3、interval = 10 秒），可作为关联 ALB 时的配置参考。

第三步：验证期望容量机制（练习 B/C/D）

创建完成后，用最直观的「改容量、数实例」方式验证 ASG 的工作原理：

练习 B：创建后立即有几个实例？为什么？答：一个。创建 ASG 时默认把 desired capacity 设为 1，ASG 为了达到期望容量，立刻启动了一个实例。这正是「期望容量 = 1」的直观体现——ASG 的使命就是让运行实例数无限趋近 desired 值。

练习 C：把 desired 改为 2，会扩容吗？会。操作路径：进入你的 Auto Scaling Group →Details → Edit→ 将 Desired capacity 改为 2。当前只有 1 个实例在运行，ASG 检测到实际数（1）小于期望数（2），于是再启动一个实例，使总数达到 2。

练习 D：把 desired 改回 1，结果是什么？答：ASG 会终止其中一个实例（假设当前有 2 个在运行）。因为实际数（2）大于期望数（1），缩容逻辑被触发。仓库问答中也有一道完全对应的考题：「You have two instances running as part of ASG. You change the desired capacity to 1. What will be the outcome?」——答案正是「One of the instances will be terminated」。

这里值得注意的是：终止的是哪个实例由 ASG 的默认终止策略决定。仓库问答（topics/aws/README.md的 ASG 章节）总结了两条默认规则：

1. 找到拥有最多实例的那个 AZ；
2. 若该 AZ 实例数 > 1，选择最旧（基于启动配置/模板）的实例终止。

同时，默认情况下 ASG 会尽力在多个 AZ 间均衡实例数量，这也是它在缩容时优先选「实例最多的 AZ」的原因。

进阶：动态伸缩策略与压力验证

基础练习验证的是「手动改容量」的静态扩缩容，而 ASG 真正的价值在于根据负载自动伸缩。仓库配套的 Dynamic Scaling Policy 练习 完整演示了这一能力，可直接作为本文练习的下一步：

前置条件：一个最大容量 ≥ 3 的 ASG；一台最多 4 核 CPU 的运行中实例。

配置目标跟踪策略（Target Tracking Scaling）：

1. 进入 EC2 → Auto Scaling Groups，切换到Automating scaling标签页；
2. Policy Type 选择Target tracking scaling；
3. 指标类型选择Average CPU utilization（平均 CPU 利用率）；
4. 目标值设为70%，点击Create。

验证扩容：用 stress 工具压满 CPU（Amazon Linux 2 环境）：

sudo amazon-linux-extras install epel -y sudo yum install stress -y stress -c 4 # 假设实例有 4 个 CPU 核心

当 CPU 利用率持续高于 70% 目标值时，ASG 会自动扩容——会新增一台 EC2 实例。

验证缩容：停止 stress 命令后，CPU 利用率回落到 70% 以下，ASG 检测到容量过剩，会自动终止一台实例。

仓库问答对动态伸缩策略给出了更系统的分类（见topics/aws/README.md的 ASG 问答）：

1. Target Tracking Scaling（目标跟踪）：设定一个基准值（如 CPU > 60% 就扩容），ASG 自动维持在该值附近——本练习采用的就是这类；
2. Step Scaling（步进伸缩）：更细粒度，针对不同指标区间执行不同动作（如 CPU < 20% 时移除 1 台、CPU > 40% 时新增 3 台）；
3. Scheduled Actions（计划动作）：预先设定特定时间段的伸缩（如每周一 10:00–11:00 扩容）。

另外还有Predictive Scaling（预测伸缩）：通过分析历史负载预测未来流量并提前规划伸缩。这些策略可结合 CloudWatch 告警联动：告警监控某个指标，达到阈值后触发扩容/缩容动作。

关键机制：冷却时间、健康检查与生命周期钩子

为了让 ASG 在生产中稳定工作，还需要理解三个配套机制（均有仓库问答佐证）：

Scaling Cooldown（伸缩冷却期）：一次伸缩活动发生后，ASG 会进入冷却期，期间不会再次终止或启动实例。原因是需要时间收集并稳定指标，避免「刚扩容又缩容」的抖动。

健康检查替换：ASG 会持续监控实例健康状态。当实例未通过 EC2 或 ELB 健康检查时，ASG 自动终止该实例并启动新实例替换，实现自愈。这就是 ASG 被广泛用于 Web 集群的原因：即使某实例崩溃，集群容量也能自动恢复。

Lifecycle Hooks（生命周期钩子）：允许在实例进入服务前（pending 状态）或终止前（terminating 状态）执行额外的自定义步骤，比如在实例挂载数据卷、更新注册表、或在销毁前拉取日志。

补充：用基础设施即代码落地

题解全程基于控制台，但仓库 README 明确推荐用 Terraform / Pulumi 等 IaC 工具完成练习。仓库中已存在可参考的 Terraform 范例，例如 launch_ec2_web_instance 的 Terraform 版 展示了如何用aws_instance资源定义 AMI、实例类型、user data 脚本与安全组入站规则；new_vpc 练习 与 subnets 练习 则提供了 VPC/子网资源的写法，可作为把 ASG 练习迁移到 Terraform 时的骨架参考。

小结

通过 devops-exercises 的这个基础练习，你亲手验证了 ASG 的核心机制：

• 启动模板承载实例配置（AMI、实例类型、密钥、安全组、user data），是 ASG 的「实例图纸」；
• 期望容量是 ASG 的「稳态目标」，手动修改它即可触发扩缩容，验证了实例数量的增减逻辑；
• 动态伸缩策略让 ASG 依据 CPU 等指标自动伸缩，无需人工干预；
• 冷却期、健康检查、生命周期钩子等机制保障了伸缩过程的稳定性与可用性。

从「手动改 desired」到「目标跟踪自动伸缩」，这条练习链路覆盖了 ASG 从入门到实战的关键知识点。想继续深入，可以在本仓库中进一步完成 Dynamic Scaling Policy、Application Load Balancer 与 Network Load Balancer 等关联练习，逐步构建一套完整的弹性 Web 架构。

• 文档
• 教程
• DevOps
• 运维