AWS 多可用区怎么部署？ALB、EC2 与数据层边界

AWS 多可用区部署不是在两个可用区各放一台 EC2 就结束。入口、计算、会话、文件、数据库、队列和发布系统都要消除单可用区依赖，并通过真实故障演练验证。

各层设计

层级	设计重点	验证
网络	每个可用区独立子网与地址空间	路由、NAT 与剩余 IP
入口	ALB 启用多个可用区	DNS、健康检查与证书
计算	Auto Scaling 跨区分布	容量、替代规格与启动时间
状态	Session、文件和缓存外置	摘除一组实例后仍可用
数据	选择明确支持 Multi-AZ 的方案	切换时间、RPO、RTO

应用必须先去单机状态

• Session 不只放进程内存；
• 上传文件不只写实例磁盘；
• 定时任务具备分布式锁和幂等；
• 配置、证书和依赖可以自动重建；
• 数据库连接能在端点切换后恢复。

容量与网络边界

另一个可用区必须具备承接故障流量的容量。NAT、数据库、缓存和第三方白名单也可能形成单区依赖。跨可用区流量还可能产生费用，应结合架构与定价核算。

故障演练

1. 确认监控、回滚和业务观察窗口；
2. 从目标组摘除一个可用区的测试目标；
3. 观察错误率、延迟、会话和队列；
4. 验证 Auto Scaling 能在健康区域补充容量；
5. 验证数据库与缓存切换；
6. 恢复目标并等待健康检查后再接流。

边界条件

Multi-AZ 降低单个数据中心故障风险，不替代跨区域灾备、备份、权限隔离和错误发布防护，也不能承诺零数据丢失。

从两套独立子网开始，而不是复制实例

VPC 是区域级资源，子网属于单个可用区。生产入口至少在两个可用区各准备一个子网，并为 ALB 启用这些可用区。计算层使用 Auto Scaling Group 跨区分布，最小容量要保证任一可用区退出后，剩余区域仍能承接必要流量。若正常时两区各只有一台且单台已接近满载，架构虽然“跨区”，故障时仍会容量不足。

每个子网还要预留足够 IP。扩容失败不一定是 EC2 配额，也可能是子网可用地址耗尽。NAT Gateway 是可用区级资源；私有子网若全部依赖另一区的单个 NAT，会形成跨区依赖并增加跨区流量。需要出网连续性的场景，应评估每区 NAT 与对应路由。

ALB 和计算层怎样配合

ALB 需要把流量导向不同可用区中的健康目标。目标组健康路径必须能反映实例是否准备好接流，Auto Scaling 的健康策略、启动预热和 ALB 注册状态要一致。新实例启动不等于应用完成数据库迁移、缓存预热和配置加载。

部署时先让新目标通过健康检查，再逐步移除旧目标。不要在同一时间替换所有可用区实例。静态上传文件、Session 和本地计划任务若仍依赖单机磁盘或内存，用户切换到另一实例后会出现登录丢失、图片缺失或任务重复。

数据层才是常见单点

RDS Multi-AZ 的目标是提高数据库可用性，不等于读扩展，也不等于跨区域灾备。应用必须使用数据库端点而不是缓存某个实例 IP，并配置合理的连接超时、重试和连接池恢复。自建数据库需要自行解决复制、一致性、选主、脑裂和备份恢复，不能因为两台 EC2 分属不同可用区就称为高可用。

Redis、队列、对象存储、搜索和文件系统同样要检查故障域。WordPress 或 CMS 的上传目录应外置到共享或对象存储方案，或者有明确同步机制；只把 Web 层跨区并不能保护持续变化的数据。

怎样做一次可控演练

1. 记录基线错误率、延迟、健康目标数、队列和数据库连接；
2. 确认剩余可用区容量与扩容配额；
3. 从 ALB 目标组摘除一个可用区的测试目标，而不是直接关停全部资源；
4. 验证登录会话、上传、支付回调、后台任务和缓存；
5. 观察 Auto Scaling 是否在健康区域补足容量；
6. 恢复目标，等待健康检查稳定后再结束演练。

演练要有停止条件和回退负责人。Multi-AZ 主要降低单可用区基础设施故障风险，无法防止错误发布、错误删除、共享凭据泄露和区域级故障。

相关阅读

• AWS ALB 健康检查配置与排障
• 单可用区、多可用区与多区域怎么选

监控必须能看出哪个可用区出问题

只看区域总请求和平均延迟，会掩盖单个可用区的灰色故障。监控应按目标、可用区和服务层拆分 ALB 健康状态、5xx、响应时间、Auto Scaling 容量、数据库连接和队列积压。告警还要区分“单区退化但业务可用”和“剩余容量不足”。

多可用区会增加资源、跨区流量和运维复杂度。正式采用前应写明目标 RTO/RPO、可接受故障范围和演练频率；低流量博客可以先把数据库备份、对象存储和可重建部署做好，再判断是否值得承担完整双区架构成本。

官方资料

• AWS：区域与可用区
• AWS：ALB 子网与可用区