Amazon DOP-C02: 高可用性、弹性和灾难恢复 — 学习指南

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

属于 AWS DevOps Engineer Professional DOP-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

AWS 上的高可用性与灾难恢复专注于在组件、可用区 (AZ) 或区域性故障下，减少停机时间 (RTO) 和数据丢失 (RPO)。多可用区设计可以在无数据丢失和最小化服务影响的情况下吸收可用区故障；多区域设计则用于应对区域性中断和大规模事件。选择主动/主动、主动/被动（热备）和引导点（pilot-light）等策略的依据是业务的 RTO/RPO 目标、一致性要求和成本。实现这些目标需要在 DNS 路由、计算弹性、负载均衡、数据库复制/故障转移、带复制/版本控制的持久对象存储、集中式备份以及通过故障注入进行的持续弹性验证等多个方面进行统一的设计。

针对 RTO/RPO 和智能路由的架构

多可用区与多区域：

• 多可用区：将冗余实例部署在不同可用区的至少两个子网中，并置于负载均衡器之后。使用支持同步复制的托管数据库（RDS Multi-AZ、Aurora 多可用区/集群）。对于同步存储，RPO 通常为零；RTO 目标范围从亚分钟级（Aurora）到几分钟（RDS 单实例 Multi-AZ 故障转移）。
• 多区域：选择主动/主动模式以获得最低的 RTO、区域隔离和低延迟，或选择热备/引导点模式以实现成本优化的灾备。数据复制必须满足 RPO 要求：异步数据库副本、Aurora Global Database（典型 RPO <1 秒）、DynamoDB global tables（多区域、多活），以及 S3 跨区域复制 (CRR) 并可选配复制时间控制 (RTC) 以获得有 SLA 支持的复制。

Route 53 路由策略和运行状况检查：

• 故障转移路由：为同一名称创建两条记录：主记录 (Primary) 和辅助记录 (Secondary)。为主记录关联一个运行状况检查（或对指向 ALB/NLB 的别名记录使用“Evaluate Target Health”）。发生故障时，流量会切换到辅助记录。保持较低的 TTL（例如 60 秒）以减少 DNS 缓存延迟，并使用 CloudWatch Alarms 监控运行状况检查的状态。
• 基于延迟的路由：将用户路由到延迟最低的区域。为每条记录关联运行状况检查，以确保只有健康的终端节点接收流量。与多区域堆栈和支持所需最终/强一致性的区域性数据存储配合使用。
• 加权路由：按百分比拆分流量，以支持金丝雀发布、A/B 测试或“涓流式”灾备就绪性验证（例如，持续将 1% 的流量发送到备用区域）。与运行状况检查结合使用，以便排除不健康的权重。在区域性疏散期间，通过逐步调整权重来迁移流量。
• 运行状况检查：探测 HTTP(S)/TCP 终端节点或 CloudWatch Alarms。对于 ALB/NLB 别名记录，启用“Evaluate Target Health”以继承目标组的运行状况。设计的运行状况检查终端节点应能反映真实的就绪状态（依赖项可达、迁移已应用）。对于有状态的应用，应包括依赖项检查（数据库、缓存），以避免将流量路由到部分健康的实例。

按目标划分的弹性模式：

• 低 RPO、全球亚分钟级 RTO：采用主动/主动模式，结合 Route 53 基于延迟的路由和运行状况检查、区域本地的无状态计算、DynamoDB global tables 或 Aurora Global Database，以及为关键对象启用 RTC 的 S3 CRR。
• 中等 RPO (≤15 分钟)，RTO ≤4 小时：采用热备模式，配备缩减规模的备用环境、异步数据库副本（RDS 跨区域只读副本或 Aurora Global）、Route 53 故障转移路由，以及用于在故障转移时进行扩展和提升的运行手册或自动化。
• 成本优化的灾备：采用引导点模式，仅保留核心数据服务，通过基础设施即代码在调用时扩展应用层，RPO 由复制频率决定，RTO 由预置时间和数据追赶时间决定。

Elastic Load Balancing 与 Auto Scaling

Elastic Load Balancing：

• Application Load Balancer (ALB)：第 7 层，基于主机/路径的路由，支持 WebSocket/HTTP/2，集成了 WAF，通过目标组 Cookie 实现粘性会话，以及基于请求的健康检查。使用跨区域负载均衡和取消注册延迟（连接耗尽）在缩容或部署期间优雅地耗尽目标。为应对不均衡的后端预热，配置慢启动和异常值检测。
• Network Load Balancer (NLB)：第 4 层，超低延迟，支持静态 IP/弹性 IP，支持 TLS 穿透/终止，保留源 IP，并支持长连接。用于 TCP/UDP 协议、高吞吐量工作负载或必须获取客户端 IP 的场景。健康检查可根据配置在第 4/7 层进行 TCP/HTTP/HTTPS 检查。
• 连接耗尽（取消注册延迟）：设置适当的延迟（例如 60-300 秒），以允许处理中的请求完成。确保部署和 Auto Scaling 终止事件遵循此延迟，以避免用户中断。

Auto Scaling 组：

• 扩展策略：
  • 目标跟踪扩展：将某个指标（如 CPUUtilization、ALB RequestCountPerTarget）维持在目标值。这是适用于 Web/API 集群的最简单、适应性最强的策略。
  • 步进扩展：当指标超过阈值时，按定义的步长进行扩展。适用于具有可预测模式的突发流量。
  • 计划扩展：为已知事件（如促销、产品发布）预先扩展，以避免容量不足。
  • 预测性扩展：可选择使用机器学习来预测每日/每周的模式化需求。
• 生命周期挂钩：Launching:Wait 和 Terminating:Wait 允许您控制实例就绪和终止的过程。使用挂钩来：
  • 在实例进入服务状态前，对其进行引导（如 SSM Automation、用户数据完成、AMI 预热）。
  • 在终止前收集日志和工件，用于根本原因分析。
  • 协调蓝/绿部署或原地部署，这些部署必须确认就绪信号（例如 cfn-signal）。
• 温水池：将预先初始化的实例以 Stopped 或 Running 状态附加到 ASG，以大幅缩短横向扩展延迟。温水池与耗时较长的引导步骤（如安装大型软件包、下载模型）非常匹配。配置最小预热容量和重用策略。与生命周期挂钩 Launching:Wait 结合使用，仅当应用就绪检查通过时才完成挂钩，从而确保一致的切换时间。
• 弹性设置：为 Spot 实例启用容量重新平衡，使用多种实例类型/分配策略，将健康检查与目标组健康状况关联，并使用实例刷新功能进行带健康护栏的安全滚动更新。

数据层的弹性、复制与备份

关系型数据库：

• RDS Multi-AZ：同步复制到不同可用区 (AZ) 的备用实例；自动故障转移会将 DNS 端点更新到备用实例。这可以防范可用区和实例故障，对于带有多可用区备用实例的单可用区数据库实例，RPO ≈ 0，RTO 通常为几分钟。适用于 MySQL/PostgreSQL 的新型多可用区数据库集群提供更快的故障转移和多个可读备用实例。
• 只读副本：用于读取扩展和灾难恢复 (DR) 的异步复制。使用跨区域只读副本进行灾难恢复；提升为主实例是手动的（或通过运行手册/无服务器函数自动化），会产生 RPO > 0 的数据丢失。确保正确配置了 binlog 或逻辑复制，并监控复制延迟。
• Aurora：Aurora 多可用区（集群）使用共享存储，在多个可用区中拥有副本；故障转移通常在亚分钟级别完成。Aurora Global Database 提供基于存储的物理复制到次要区域，典型 RPO < 1 秒，RTO < 1 分钟。使用托管的计划内故障转移实现零数据丢失迁移，或使用非计划内故障转移应对灾难事件。写入器/读取器端点抽象了拓扑结构；应用程序应实现带退避的重试机制。

对象存储与灾难恢复：

• S3 Versioning：启用版本控制以防止覆盖/删除，并支持 CRR。配置生命周期策略，将旧版本转换到更便宜的存储层，并设置适当的保留期。
• S3 Cross-Region Replication (CRR)：要求源和目标存储桶都启用版本控制。使用一个复制 IAM 角色；如果存储桶是跨账户的，则在目标存储桶策略中添加权限，允许源角色执行 s3:ObjectOwnerOverrideToBucketOwner 和放置对象的权限。对于 KMS 加密的对象，授予该角色对源密钥的 kms:Decrypt 权限和对目标密钥的 kms:Encrypt 权限。考虑以下几点：
  • Replication Time Control (RTC)，可在 15 分钟内复制 99.9% 的对象，并提供指标/警报。
  • 根据需要复制删除标记和所有权控制。
  • S3 Batch Replication，用于处理现有对象。
  • 用于 SLA 的复制指标和通知。
• DynamoDB：使用全局表实现多区域/多主写入的低延迟和高可用性 (HA)。或者，启用时间点恢复 (PITR) 和按需备份以进行恢复。

使用 AWS Backup 进行集中备份：

• 备份计划：定义计划（CRON）、备份窗口、生命周期（转换到冷存储、保留期）以及到其他区域/账户的复制操作。通过标签或 ARN 分配资源，以实现策略驱动的覆盖。
• 备份文件库：带有独立 KMS 加密密钥和访问策略的逻辑容器。启用 AWS Backup Vault Lock 以实现 WORM（一次写入，多次读取）不变性和抗勒索软件的能力。使用跨账户文件库副本以减小爆炸半径。
• 跨账户备份：在 Organizations 中，将备份策略应用于成员账户以实现一致的治理。配置保管库访问策略，以允许从中央备份账户进行复制/恢复。定期执行自动化恢复演练，以衡量 RTO 并验证运行手册。
• 集成：保护 EBS、EC2、RDS/Aurora、DynamoDB、EFS、FSx 等服务。使计划和保留期与法规要求的 RPO/RTO 对齐，并在需要时与应用程序一致性静默（通过 SSM 前/后脚本）进行协调。

混沌工程与 AWS Fault Injection Simulator (FIS)

混沌实验用于验证 HA 和 DR 机制是否按设计运行。AWS FIS 通过护栏来编排受控的故障注入：

• 实验模板定义了操作（例如，停止或重启 ASG 中一定百分比的 EC2 实例，通过 SSM 注入 CPU 或内存压力，在实例上增加网络延迟/丢包，终止 EKS Pod，停止 ECS 任务，触发 RDS/Aurora 故障转移）和目标（资源标签、ARN）。
• 安全控制：指定 CloudWatch 警报作为停止条件、时间限制、通过标签/筛选器限制爆炸半径，以及执行预检查。首先在非生产环境中运行，然后在有严格护栏和业务批准的情况下在生产环境中运行。
• 可观测性：检测 KPIs（错误率、尾部延迟、队列龄期、副本延迟），并验证自动化响应，包括 Auto Scaling 反应、负载均衡器健康状况收敛、Route 53 故障转移、数据库提升以及断路器行为。
• 持续的韧性：将实验集成到管道/演练日中，以防止配置漂移侵蚀韧性。使用 Parameter Store 或 AppConfig 进行功能切换和协调安全部署。

实践问题场景

Expedia Group 运营一个全球旅行搜索 API，该 API 必须为关键预订数据提供低于 60 秒的 RTO 和接近于零的 RPO，同时为北美和欧洲的用户保持低延迟。该团队偶尔会遇到区域性服务降级和因部署引发的不稳定问题，并且审计人员要求提供跨账户的不可变备份和有文档记录的 DR 演练。

分步方法：

1. 建立多区域、双活架构堆栈

• 在 us-east-1 和 eu-west-1 的多个 AZ 中，于 ALB 之后部署无状态 API 堆栈。使用 Route 53 基于延迟的路由，并结合健康检查和别名记录上的“评估目标运行状况”(Evaluate Target Health)。这可提供低延迟路由，并在端点不健康时自动进行区域规避。

2. 全球性的、低 RPO 的数据存储

• 将预订和会话数据迁移到 Amazon Aurora Global Database (兼容 MySQL)，以 us-east-1 为主区域，eu-west-1 为备用区域。典型的 RPO <1 秒和 RTO <1 分钟满足中断目标。在应用程序配置中使用集群和读取器端点，并配合重试/退避机制以容忍故障转移。

3. 弹性的扩展和优雅的转换

• 在 ALB 的 RequestCountPerTarget 上配置 Auto Scaling 目标跟踪，并在两个区域都设置最小容量。添加预热池，其大小足以吸收重大事件期间 10 倍的流量激增，并使用生命周期挂钩 Launching:Wait 来延迟实例注册，直到应用就绪检查通过。启用 120 秒的 ALB 注销延迟，以在缩容和部署期间保留传输中的请求。

4. 持久对象的 DR

• 为行程单文档启用 S3 版本控制和带有 RTC 的 CRR，从 us-east-1 复制到 eu-west-1。使用专用的复制 IAM 角色以及两个区域中的 KMS 密钥，在源端授予 kms:Decrypt 权限，在目标端授予 kms:Encrypt 权限。RTC 指标和警报为复制 SLA 提供了信心。

5. 用于金丝雀发布和故障转移的 DNS 控制

• 添加加权的 Route 53 记录（将 1% 的恒定流量引到 eu-west-1），以持续演练备用路径。结合健康检查，这能确保备用环境处于生产就绪状态，并在危机发生前捕获配置漂移。

6. 集中化的、不可变的备份

• 在一个由安全团队拥有的备份账户中，使用 Vault Lock 和 KMS CMK 创建 AWS Backup 保管库。定义组织级别的备份策略，以安排每日备份和针对 RDS、DynamoDB、EFS 和 EBS 的跨账户副本。通过 Backup_Frequency 标签分配资源。这实现了勒索软件抵御能力和职责分离。

7. 自动化的故障转移编排

• 实施一个 EventBridge 规则来检测 Aurora 主数据库故障信号，并调用一个 Lambda 函数来提升备用区域并更新存储在 Parameter Store 中的应用程序端点。应用程序在启动时加载该端点，并在连接错误时刷新，从而最大限度地减少手动步骤。

8. 使用 AWS FIS 进行混沌验证

• 创建 FIS 实验模板以：终止 10% 的 ASG 实例，通过 SSM 在 EC2 上注入 150 毫秒的延迟和 1% 的丢包，以及触发 Aurora 故障转移。通过针对 p95 延迟和错误率的 CloudWatch 警报停止条件来设置护栏。每月进行演练日活动，以验证 Route 53 故障转移速度、ASG 恢复能力、ALB 健康状况收敛以及 Aurora 提升的 RTO。

为什么选择这些服务：

• Route 53 基于延迟和加权的路由既能提供最佳用户延迟，又能为 DR 准备工作提供受控的流量整形。
• ALB 加上带有预热池和生命周期挂钩的 ASG，可确保快速、优雅的扩展，而不会产生冷启动惩罚或用户中断。
• Aurora Global Database 以最少的应用更改，独特地满足了跨区域近乎为零的 RPO 和亚分钟级的 RTO。
• S3 版本控制和带有 RTC 的 CRR 为关键工件提供了可审计的、有 SLA 支持的复制。
• AWS Backup 及其跨账户保管库和 Vault Lock 功能，创建了符合合规需求的、不可变的、集中管理的备份。
• AWS FIS 提供安全的、自动化的故障注入，以持续证明韧性状况，并防止配置漂移破坏 DR 计划。

← 容器和 Serverless 运维 · 所有领域 · 事件驱动架构和自动化 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Amazon →