在设计云上架构时，多可用区弹性伸缩是平衡高可用与成本的关键。本文直接给出判断路径：先明确业务对可用性的容忍度，再决定跨可用区部署的粒度，最后配置伸缩策略与容灾机制。以下展开具体细节。
为什么多可用区是弹性伸缩的高可用基石
可用区（AZ）是云厂商提供独立故障域的物理区域。将实例分散在多个可用区，可避免单一可用区故障导致整个业务中断。AWS 官方文档指出，EC2 提供按需、可扩展的计算容量，您可以根据流量高峰增加或减少容量。多可用区部署是满足高可用要求的首要前提，也是容灾设计的基础。
判断路径：从业务需求到架构决策
第一步，量化可用性目标。例如，SLA 要求 99.99% 可用性，意味着全年停机时间不超过 52.6 分钟，这通常需要跨可用区部署。第二步，评估故障影响。如果单个实例故障可接受短暂影响，可先采用单可用区；否则，必须使用多可用区。第三步，考虑成本。AWS 成本优化支柱强调，成本优化的负载应充分利用资源并满足功能需求，多可用区会增加网络和实例成本，需权衡。
操作步骤：构建多可用区弹性伸缩
以 AWS Auto Scaling 为例，核心步骤如下：
- 创建启动模板，指定 AMI、实例类型、安全组等。
- 在创建 Auto Scaling 组时，选择至少两个可用区，并设置实例分布策略（如平衡或成本优先）。
- 配置动态伸缩策略，如基于 CPU 利用率的 target tracking，或基于请求数的步进策略。
- 设置实例保护，防止伸缩过程中终止关键实例。
- 结合负载均衡器，将流量分发到多个可用区的实例。
关键点：确保子网覆盖所选可用区，且每个子网有足够的 IP 容量，避免扩容失败。
高可用与容灾的取舍
多可用区部署提高了可用性，但带来额外成本。取舍包括：
- 实例分布：平衡分布最大化可用性，但可能增加跨可用区数据传输费用；成本优先分布可降低费用，但故障恢复时间更长。
- 伸缩策略：快速扩容可减少故障影响，但可能过度配置；保守策略节省成本，但可能在流量峰值时资源不足。
- 容灾级别：同区域多可用区可应对可用区故障；跨区域容灾则需更复杂的设计和更高成本。
AWS Well-Architected 框架强调理解设计权衡，多可用区弹性伸缩正是权衡可用性与成本的最佳实践。
常见误区与失败条件
以下是常见错误：
- 忽略子网容量：子网 IP 耗尽导致扩容失败，可用性受损。
- 伸缩策略过于激进：频繁扩容缩容导致抖动，影响稳定性。
- 未设置冷却时间：导致伸缩活动重叠，资源浪费。
- 不监控伸缩活动：无法及时发现故障，容灾失效。
失败条件包括：启动模板配置错误、IAM 权限不足、负载均衡健康检查设置不当等。务必通过演练验证故障转移。
成本优化与多可用区的平衡
AWS 成本优化支柱建议采用按需和 Spot 实例混合，可降低成本，但 Spot 实例可能被回收，需结合伸缩策略。多可用区下，可结合 弹性伸缩与 Spot 降级 的实践，在保证可用性的同时优化成本。同时，参考 Auto Scaling 策略配置实战 和 从手动到自动扩缩容 的详细指南。
验证与持续改进
部署后，定期进行故障演练，模拟可用区故障，验证伸缩组是否自动移除故障实例并启动新实例。同时，监控伸缩活动历史，调整策略参数。安全方面，AWS 安全性支柱强调最小权限原则，确保伸缩组使用的 IAM 角色仅具备必要权限。
参考资料
延伸阅读