亚马逊云账号批发 AWS高可用计算架构实战教程：ALB负载均衡、Auto Scaling自动伸缩与故障恢复配置指南

用户搜索这个主题，通常不是为了了解AWS产品名词，而是准备解决三个实际问题：一是业务上线后如何避免单台EC2宕机导致网站不可用；二是流量波动时如何自动扩容，避免高峰时响应变慢；三是实例、可用区或应用进程异常时，如何让流量自动切走并快速恢复。本文按照真实上线流程展开，重点放在控制台配置、关键参数、常见错误和恢复方法。

部署前先确认：你现在最可能卡在哪一步

从用户决策路径看，最常见的疑问不是“要不要高可用”，而是“该怎么搭、花多少钱、哪里最容易出错”。如果你正在做网站、API接口、后台管理系统或轻量业务中台，通常会在以下环节犹豫：

• 负载均衡要选ALB还是NLB，监听器和目标组怎么配
• Auto Scaling Group最小、最大、期望实例数怎么填才不浪费
• 实例放一个可用区还是多个可用区，跨区会不会带来额外复杂度
• 健康检查路径填什么，为什么实例明明启动了却一直Unhealthy
• 扩容后新实例为什么不能自动接流量，应用代码和环境如何同步
• 实例异常后如何自动替换，是否需要快照、AMI或用户数据脚本

如果你想快速落地，一个可执行的基础方案是：在同一地域的2个可用区内创建私网EC2实例，前面放一个公网ALB，后面由Auto Scaling Group管理实例数量，使用Launch Template统一镜像与启动脚本，配合CloudWatch告警实现扩缩容。这个方案适合80%的Web和API业务。

准备工作：账号、权限、网络和镜像一次配齐

账号与权限

建议使用具备以下权限的IAM用户，而不是长期使用Root账号：

前置资源

• 一个已创建好的VPC
• 至少2个不同可用区的子网，建议一个地域内的AZ-a和AZ-b
• 一个SSH密钥对，用于Linux登录；如果是Windows，准备管理员密码解密方式
• 已经测试通过的应用启动脚本，或打包好的AMI
• 域名和证书（如果要部署HTTPS）

网络建议

生产环境推荐：ALB放公网子网，EC2放私网子网，通过NAT访问外网安装依赖。这样可以减少直接暴露公网IP的风险。如果是测试环境，也可以让EC2临时分配公网IP，但正式环境不建议这样做。

实战配置流程：从0搭建ALB + Auto Scaling + 故障恢复

步骤1：创建EC2启动模板，先把实例标准化

进入AWS控制台，打开 EC2 控制台，在左侧选择 Launch Templates，点击 Create launch template。

建议参数如下：

在 User data 中写入启动脚本，让新实例启动后自动部署应用。例如Linux环境常见做法：

注意：很多实例无法加入目标组，不是因为ALB有问题，而是User data执行时间过长，健康检查在应用尚未启动前就失败。解决方法是：给目标组设置合理的健康检查宽限时间，或者让应用在依赖初始化完成前先返回一个简单200页面。

步骤2：创建Application Load Balancer并绑定目标组

进入 EC2 控制台，选择 Load Balancers，点击 Create Load Balancer，选择 Application Load Balancer。

关键配置如下：

接着创建 Target Group，类型选择 Instances，协议按应用选 HTTP:80 或 HTTPS:443。健康检查是这里最容易填错的地方：

如果你的应用首页会跳转登录、依赖数据库、或者首次启动慢，不要把“/”直接拿来做健康检查。最佳做法是单独提供一个不依赖外部服务的健康检查接口，例如返回静态JSON。

步骤3：创建Auto Scaling Group，让扩缩容和替换自动化

进入 EC2 控制台左侧 Auto Scaling Groups，点击 Create Auto Scaling group，选择刚才的启动模板。

核心参数建议：

在 Load balancing 页面中，选择 Attach to an existing load balancer，并绑定前面创建的 Target Group。

扩容策略建议先用 Target tracking policy，指标可选 Average CPU utilization，目标值可先设 50% 或 60%。如果是Java应用或者请求主要受内存影响，不要只盯CPU，可以改为 ALB Request Count per Target 或自定义内存指标。

一个实用配置是：

• CPU平均超过60%，持续5分钟，自动扩容1台
• CPU平均低于25%，持续15分钟，缩容1台
• 设置实例预热时间300秒，防止刚启动实例还未接流量就被误判

步骤4：设置HTTPS、证书和DNS切换

如果业务需要正式上线，建议在ALB层终止HTTPS。进入 ALB 监听器设置，新增 443 监听器，证书从 ACM 中选择。然后在 Route 53 或第三方DNS中，将域名CNAME或Alias到ALB DNS名称。

这里最常见的错误有两个：一是证书区域不一致，ACM证书必须在同一地域；二是安全组只开放了80，没有放行443，导致HTTPS超时。

步骤5：验证故障恢复是否真的可用

高可用不是“资源创建成功”就结束，必须模拟故障。建议至少做以下验证：

亚马逊云账号批发 如果停止实例后没有自动补齐，重点检查：ASG是否启用了ELB健康检查、是否误将实例设置为Standby、启动模板是否可正常拉起应用。

亚马逊云账号批发 故障排查：负载均衡和自动伸缩最容易出的问题

健康检查一直失败

常见原因通常集中在4类：

• 安全组未放通：EC2安全组没有允许来自ALB安全组的80或443访问
• 健康检查路径错误：例如填了/login，但实际返回302或401
• 应用启动慢：Java或容器初始化超过默认等待时间
• 系统防火墙拦截：Linux启用了firewalld或iptables，但未开放应用端口

亚马逊云账号批发 Linux排查命令可直接执行：

扩容了实例，但新实例不接流量

优先检查启动模板里的User data是否执行成功。很多用户更新应用时只改了现有实例，忘了同步到AMI或启动脚本，导致扩出来的新机器还是旧版本，甚至根本没有应用进程。建议固定流程：应用发布完成后，更新启动模板版本，而不是只手工改在线实例。

ALB返回502或504

这类问题一般不是ALB本身故障，而是后端响应异常：

• 502：后端进程未监听、返回格式异常、连接被重置
• 504：应用响应太慢、数据库卡住、上游接口超时

可从ALB访问日志、应用日志和CloudWatch指标一起看，重点看 TargetResponseTime、HTTPCode_Target_5XX_Count。

不同业务怎么选配置，不要一套参数套所有场景

跨境业务尤其要注意地域选择。不要只看实例价格，应先用CloudPing或实际客户端测试目标地域延迟。面对中国香港、东京、新加坡、法兰克福等区域，延迟差异会直接影响是否需要更激进的扩容策略。

亚马逊云账号批发 上线后继续做的优化，不然高可用只是表面可用

安全优化

• EC2实例不要直接暴露公网IP，优先通过SSM连接运维
• 安全组按来源收敛，EC2仅允许ALB安全组访问业务端口
• 管理端口22和3389不要对全网开放，至少限制办公IP
• HTTPS证书放ALB统一管理，减少实例证书维护成本

性能优化

• 开启ALB跨可用区负载分发，避免单区流量堆积
• 静态资源走S3或CloudFront，不要全部压到EC2
• 扩容指标尽量贴近业务瓶颈，不要只用CPU
• 启动模板中预装依赖，减少新实例冷启动时间

成本优化

• 测试环境设置定时缩容，非工作时段降到最小实例数
• 稳定业务可考虑Savings Plans或预留实例降低长期成本
• 扩容上限不要无脑拉高，否则异常流量会直接放大账单

稳定性优化

• 应用保持无状态，会话放Redis或数据库，不保存在本地磁盘
• 发布新版本时使用启动模板新版本配合逐步替换，避免整组重建
• 亚马逊云账号批发 定期做故障演练，包括实例宕机、健康检查失败、证书过期和DNS切换测试

如果你现在正准备上线，最先落地的不是复杂的多地域容灾，而是先把“单地域双可用区 + ALB + ASG + 健康检查 + 启动模板版本化”做好。这个组合已经能解决大多数中小业务的单点问题、扩容问题和实例故障自动恢复问题，而且后续扩展到RDS、ElastiCache、CloudFront也比较顺畅。