使用 ARC Zonal Shift 进行多日可用区疏散演练
内容提要
本文介绍使用 ARC Zonal Shift 进行多日可用区疏散演练。传统故障转移测试仅持续几分钟，无法暴露长时间 N-1 运行下的问题，如自动扩缩容、DNS 缓存、数据库连接等。演练将流量移出单个可用区 48 至 72 小时，覆盖 ECS、EKS、RDS 及 Aurora，并给出 CLI 步骤、监控指标与恢复流程。金融机构借此提供可审计的韧性证据。
延伸解读
多日演练与短时故障转移的本质区别
传统故障转移测试通常在几分钟内完成，只能验证切换机制是否生效。而多日可用区疏散演练将流量移出单个可用区48至72小时，迫使自动扩缩容策略、DNS缓存、数据库连接池等时间依赖行为充分暴露。文章指出，短时测试无法发现未针对持续N-1运行调优的扩缩容策略、部署流水线未验证可用区健康、陈旧的DNS或缓存数据库端点等问题。因此，多日演练的核心价值在于验证系统在持续降级状态下仍能维持生产负载。
ARC Zonal Shift 的数据平面特性与操作顺序
ARC Zonal Shift 是一种数据平面操作，独立于AWS控制平面，因此在可用区实际受损时仍可用。文章强调，在真实故障中应优先启动zonal shift以立即停止流量，然后再执行控制平面操作（如ECS服务更新、RDS手动故障转移）。对于计划内演练，控制平面健康，顺序影响不大。但这一区分对生产环境应急响应至关重要，读者需理解数据平面与控制平面操作的优先级差异。
多日演练中的关键运维挑战
文章指出，多日演练的机制与短时相同，但操作面显著扩大。需要管理zonal shift的过期时间，避免流量意外返回；监控扩缩容漂移，防止恢复时过载；验证客户端DNS TTL合规性；并让团队在减少一个可用区的环境中正常部署、修补和排障。恢复过程也需谨慎：先验证健康，再逐步缩容，最后增量引入流量，而非一次性全部恢复。这些挑战是短时测试无法覆盖的。
不同数据库引擎的疏散策略差异
文章对比了RDS for PostgreSQL与Aurora PostgreSQL在可用区疏散中的不同处理。RDS Multi-AZ需要手动触发故障转移，备用实例会在原可用区自动重建，若需完全移除该可用区，需通过修改子网组实现。Aurora的存储层跨三个可用区同步复制，与计算实例无关，因此只需故障转移写入器或读取器实例。Aurora还支持通过故障转移优先级选择提升哪个读取器，预置健康可用区的读取器可将故障转移时间从约10分钟缩短至30秒以内。
Q&A
什么是多日可用区疏散演练？它和传统的故障转移测试有什么区别？
多日可用区疏散演练是指使用 ARC Zonal Shift 将流量移出单个可用区，持续 48 至 72 小时，以验证应用在长时间 N-1 运行下的韧性。传统故障转移测试通常只持续几分钟，仅验证故障转移机制，无法暴露自动扩缩容、DNS 缓存、数据库连接等随时间出现的问题。
为什么金融机构需要进行多日可用区疏散演练？
金融机构面临监管压力，需要证明而非仅仅记录灾难恢复能力。监管要求从“展示运行手册”转向“展示证据”，推动金融机构在真实条件下进行实时灾难恢复测试，并产生可审计的恢复证明。一些银行和保险公司已将定期可用区疏散演练纳入运营韧性计划。
ARC Zonal Shift 的工作原理是什么？它如何影响流量和 EKS 集群？
ARC Zonal Shift 会协调执行两项操作：从 DNS 中移除受影响可用区的负载均衡器 IP 地址，并阻止其他可用区的负载均衡器节点向被移出的可用区路由请求。对于启用了 zonal shift 的 EKS 集群，ARC 还会封锁受影响可用区的节点、从 EndpointSlice 中移除 Pod 端点、暂停可用区再平衡，并保留节点和 Pod 不终止。
进行多日可用区疏散演练前需要哪些先决条件？
先决条件包括：多可用区部署的应用（ALB/NLB、ECS/EKS、RDS/Aurora）、IAM 权限、AWS CLI v2、CloudWatch 仪表板（按可用区细分指标）、验证过的自动扩缩容策略。ELB 需设置取消注册延迟为 60 秒并配置最小健康目标数；EKS 需启用拓扑感知路由和 zonal shift；ECS 需设置 stopTimeout 为 55 秒；RDS 需确保主备在不同可用区。
多日可用区疏散演练中，ECS 和 EKS 的疏散步骤有何不同？
ECS 疏散需要：在负载均衡器上启动 zonal shift，更新 ECS 服务的网络配置以排除被疏散可用区的子网，必要时调整任务数量，并监控任务分布。EKS 疏散则需：启用集群的 zonal shift，在负载均衡器和 EKS 集群上分别启动 zonal shift，ARC 会自动封锁节点、更新 EndpointSlice 并暂停可用区再平衡，无需手动调整网络配置。
在演练期间应该监控哪些关键指标？
需要按层监控：负载均衡器关注 HealthyHostCount、RequestCount、TargetResponseTime 和 5XX 错误；ECS 关注 CPU/内存利用率和任务数量；EKS 关注节点和 Pod 的 CPU 利用率、节点状态和容器重启次数；RDS 关注 CPU、连接数、IOPS 和 ReplicaLag；Aurora 关注 AuroraReplicaLag、CommitLatency、BufferCacheHitRatio 和连接数。
多日可用区疏散演练结束后，如何安全地恢复服务？
恢复步骤：首先验证被疏散可用区健康；先取消 EKS 集群的 zonal shift（恢复东西向流量），再取消负载均衡器的 zonal shift（恢复南北向流量）；如果自动扩缩容增加了容量，在 15 到 30 分钟内逐步缩减；如果禁用了跨区负载均衡，确保配置了最小健康目标数；恢复后监控每可用区指标 30 分钟，确认均匀分布且无错误峰值。
