Amazon SAA-C03: 高可用性、容错与灾难恢复 — 学习指南

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

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

多可用区部署与复制

多可用区 (Multi-AZ) 架构旨在解决单个数据中心或可用区发生故障的问题——仅此而已。这一区别是高可用性设计中最容易被误解的一点。多可用区部署可以容忍一个区域内单个可用区的丢失；但它不能容忍区域范围的中断、区域性服务受损，或因意外删除资源而立即将删除操作复制到备用实例的情况。复制会忠实地传播坏数据——逻辑损坏、模式错误、勒索软件写入——这就是为什么复制和备份是互补的，而不是替代关系。

对于 Amazon RDS，多可用区会在不同的可用区中预置一个同步备用副本。写入操作在两个实例上都提交后才会返回确认，这使得 RPO (恢复点目标) 基本上为零，而自动故障转移期间的 RTO (恢复时间目标) 通常为 60-120 秒。在经典的多可用区实例部署中，备用实例是不可读的——它纯粹是为了持久性和故障转移而存在。多可用区集群部署（拥有两个可读的备用实例）能进一步缩短故障转移时间并提供一定的读取扩展能力，但仍局限于单个区域内。

要实现读取扩展，请添加只读副本。只读副本使用异步复制，其目的是分载报告、分析和仪表盘查询。将只读副本视为高可用性 (HA) 故障转移机制是错误的，原因有三：复制是异步的（提升为主实例时会丢失数据），提升操作是手动的或通过脚本执行的（不是自动的），并且主节点终端节点不会被保留。当不断增长的工作负载需要更多读取容量而又不想增加新的复杂性时，应添加只读副本；当需求是零数据丢失的自动故障转移时，应使用多可用区。当关系型引擎的 RPO/RTO 必须在区域故障中幸存时，Aurora Global Database 可提供亚秒级的跨区域复制延迟和亚分钟级的托管故障转移 RTO。

Amazon ElastiCache 遵循同样的模式，使用复制组。启用了多可用区的 Redis 复制组会在多个可用区中维护一个主节点和一个或多个副本；如果主节点发生故障，ElastiCache 会将一个副本提升为新的主节点并更新主节点终端节点。为了实现水平扩展，Redis (启用集群模式) 会将数据分区到多个分片上，每个分片本身就是一个复制组。相比之下，Memcached 不会复制——节点丢失意味着该分区的数据丢失。

Amazon FSx 为 FSx for Windows File Server 和 FSx for ONTAP 提供了多可用区部署类型，在首选文件服务器和备用文件服务器之间使用同步复制。FSx for Lustre 通常是单可用区的（暂存或持久化）；Lustre 的持久性来自于与 S3 数据存储库的关联，而非可用区之间的复制。

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

RDS 自动备份和时间点恢复

RDS 自动备份结合了每日快照和持续的 5 分钟事务日志上传至 S3 的功能，从而在 1-35 天的保留窗口内，提供任意秒级的时间点恢复 (PITR)。如果你的 RPO 是 2 小时，RDS 的原生备份已经能满足要求——无需额外的快照调度，在此之上再叠加 AWS Backup 是多余的，除非你需要跨区域副本、跨账户隔离或超出 RDS 快照复制所提供的 Vault Lock 语义。对于适中的 RPO 要求，默认的自动备份通常是成本最低的正确答案。

AWS Backup 作为集中式控制平面

AWS Backup 是一个策略驱动的控制平面，用于对 EBS、EC2 (作为 AMI)、RDS、Aurora、DynamoDB、EFS、FSx、Storage Gateway、S3 等服务进行备份。你无需为特定服务编写快照逻辑脚本，而是定义备份计划，将描述频率、备份窗口、开始/完成窗口、到冷存储的生命周期转换、保留期和目标备份库的规则分组。资源通过标签或 ARN 进行资源分配来纳入备份计划，因此像 Backup=Daily 这样的标签约定就成为了管理覆盖范围的操作契约。对于拥有数百个 EC2 实例的集群，基于标签的选择是工作量最小的方法——只需应用标签，让 AWS Backup 来枚举资源，而不是为每个实例编写计划。

备份库是存储恢复点的 KMS 加密容器。访问权限由备份库上的资源策略控制。

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

跨区域和跨账户副本

CopyActions 块是实现跨区域灾难恢复 (DR) 副本的机制。AWS Backup 负责处理快照复制，使用目标区域的 KMS 密钥重新加密（目标备份库必须引用该区域的密钥），并应用独立的生命周期。EBS 和 RDS 快照默认位于源区域——如果整个区域受损，快照也会受损。任何提及区域弹性的法规或业务要求都必须包含一个明确的跨区域复制步骤，无论是通过 AWS Backup 的复制操作、RDS 自动快照跨区域复制，还是具有跨区域目标的 DLM 策略。

对于跨账户副本，AWS Organizations 会委派一个管理员账户给 AWS Backup；源备份库的策略允许目标账户访问，而目标备份库则允许来自源的复制。这是集中管理灾难恢复 (DR) 的高性价比方式：一个管理账户持有来自多个工作负载账户的恢复点，并能将它们恢复到任一区域。对于 EC2，将 AMI 复制到第二个区域并共享快照，可以让你无需暖备基础设施即可在彼处启动实例。加密快照需要共享 CMK——目标账户或区域需要 kms:CreateGrant 权限和对该密钥的访问权限。忽略这一点是跨账户恢复会静默失败的原因。

24 小时的 RPO 可以通过每日自动快照并跨区域复制来廉价地满足——其成本远低于跨区域只读副本或暖备集群。只有当 RPO 要求低于快照频率所能达到的水平时，才需要收紧到连续复制。

AMI 生命周期与 EC2 备份

有两种机制可以自动化 EC2 备份：Data Lifecycle Manager (DLM) 和 AWS Backup。DLM 早于 AWS Backup 出现，它能根据策略按计划创建 EBS 快照或 AMI，并支持跨区域和跨账户复制操作。AWS Backup 涵盖了 DLM 的功能，并增加了集中式策略、保管库锁定 (Vault Lock) 和多服务范围。当您已经为其他服务运行 AWS Backup 时，应优先选择它；对于不需要保管库功能、纯粹的 EBS/AMI 场景，则使用 DLM。

对于 Auto Scaling 组后方没有持久化本地数据的无状态 Web 层，备份正在运行的 EC2 实例是一种浪费。正确的做法是（通过 EC2 Image Builder 或 CI 管道）制作一个加固的 AMI，在启动模板中引用它，然后让 ASG 处理实例替换。备份工作应集中在有状态层，确保其原生的自动备份能满足恢复点目标 (RPO)。

不可变性：Vault Lock 与 Object Lock

您账户中的普通快照可以被任何拥有相应 IAM 权限的人删除——仅靠快照本身并不满足不可变性要求。监管制度（如 SEC 17a-4、FINRA、HIPAA、GDPR）通常要求采用“一次写入，多次读取”(WORM) 的保留策略，即使是管理员也无法规避。AWS 的两种机制可以实现这一点。

AWS Backup Vault Lock 对备份保管库强制执行 WORM 策略：

在合规模式下，一旦冷却期结束，任何用户——包括 root 账户——都无法缩短保留期、在到期前删除恢复点或移除锁定本身。这既能抵御内部人员的删除行为，也能防范已完全入侵账户的勒索软件攻击者。

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

S3 Object Lock 在对象级别提供 WORM 功能，支持监管模式（拥有 s3:BypassGovernanceRetention 权限的特权用户可以覆盖）或合规模式（任何人都无法删除或缩短保留期，包括 root 用户）。合法保留 (Legal Hold) 独立于保留期。Object Lock 要求启用版本控制，并且必须在存储桶创建时启用才能获得全面保护。

为故障转移区域预留容量

一个假设在发生大规模事件当天，故障转移区域仍有可用 EC2 容量的灾难恢复 (DR) 计划，根本算不上一个计划。当一个区域发生故障时，所有人都会同时进行故障转移，实例类型——特别是大型、GPU 或专用实例——的容量可能会耗尽。在目标区域使用按需容量预留 (On-Demand Capacity Reservations, ODCRs) 可以保证特定实例类型、平台和可用区的容量，并且无论是否使用都会计费。可以搭配 Savings Plan 来抵消成本。对于长期的 GPU/ML 承诺，可应用 Capacity Blocks；若需实例系列的灵活性，Capacity Reservation Fleet 可覆盖多个实例系列。原则是：如果业务要求在 DR 区域有确定的计算能力，就必须预留它——不要依赖尽力而为的按需可用性。

DR 策略选择

AWS 将 DR 策略规范为四个层级，每个层级在成本和恢复能力之间都有不同的权衡：

正确的层级由业务的 RPO 和 RTO 决定——而不是架构偏好。24 小时的 RPO 可以容忍每日的跨区域快照复制（备份与恢复策略）。秒级的 RPO 则要求持续复制——例如跨区域只读副本、Aurora Global Database、DynamoDB Global Tables 或 S3 跨区域复制。无论预算多少，试图用夜间快照实现 5 分钟的 RPO 在架构上是不可能的。反之，为每个工作负载都默认采用双活是一种成本上的反模式：它要求全局一致的数据（DynamoDB Global Tables 或带有写入转发的 Aurora Global Database）、全规模的重复计算资源，以及通过 Route 53 或 Global Accelerator 进行复杂的流量引导。应选择能满足既定 RPO/RTO 的最经济的模式——对于 2 小时的 RPO，备份与恢复或指示灯策略通常就足够了，而温备则属于过度设计。

删除保护与分层防护

弹性不仅仅是“我们有备份吗”——而是“任何单一行为者、错误或攻击能否将它们抹去”。分层控制可以防止“一键误操作”带来的灾难：

• RDS：启用 DeletionProtection 并在删除时要求创建最终快照。
• EC2：在关键实例上启用 DisableApiTermination 和 DisableApiStop。
• DynamoDB：启用删除保护和时间点恢复 (point-in-time recovery)。
• S3：版本控制 + MFA Delete + Object Lock 以实现不可变性。
• CloudFormation：在有状态资源上设置 DeletionPolicy: Retain 并启用堆栈终止保护。
• IAM SCPs：拒绝 backup:DeleteRecoveryPoint、backup:DeleteBackupVault、rds:DeleteDBInstance 和 ec2:DeleteSnapshot 等操作，除非通过紧急访问角色执行。

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

将这些措施与合规模式下的 Vault Lock 相结合，可以形成纵深防御：即使管理员凭证被盗用，也无法销毁作为最后一道防线的恢复点。

常见陷阱

将 Multi-AZ 视为灾难恢复（DR）。 RDS Multi-AZ、ElastiCache Multi-AZ 和 FSx Multi-AZ 都位于单个区域内。区域性的 API 中断、意外的表删除或错误的 schema 迁移会同时影响两个节点。任何提及“另一个区域”、“区域性故障”或“跨区域 RPO”的要求都强制要求进行跨区域复制或拷贝——仅靠 Multi-AZ 无法满足此要求。

将只读副本与高可用性（HA）混淆。 只读副本是异步的，需要手动提升，并且会更改端点。它们解决的是读取扩展问题，而不是自动故障转移。

假设快照等同于合规性。 没有 Vault Lock（合规模式）或 Object Lock 的快照可以被任何具有正确 IAM 权限的主体以及根账户删除。WORM 法规保留要求明确的不可变性配置，并且锁定的冷却期已过。

为区域性 RPO 使用仅限本地的快照。 EBS 和 RDS 快照默认保存在源区域。区域弹性需要明确的跨区域复制操作。

备份未经恢复测试或没有预留容量。 从未恢复过的快照只是一个假设，而不是备份。恢复演练会揭示缺失的 IAM 角色、目标区域和账户中的 KMS 密钥访问问题以及不可用的实例类型。如果没有为关键工作负载预留容量（Capacity Reservations），当所有人同时进行故障转移时，灾备区域可能根本没有您需要的实例规格——RTO 将变得无法估量。

对 active-active 架构进行过度设计。 重复的全局计算、全局一致的数据复制和复杂的流量路由成本高昂。如果 RPO/RTO 的要求并不需要如此，那么 pilot light（引导灯）或 warm standby（温备）才是正确的架构。

备份无状态层。 为 ASG 后面的临时 Web 服务器创建快照会浪费资金并使恢复复杂化。应该制作 AMI，在启动模板中引用它们，并将备份投入集中在有状态数据上。

← 管理、运维、可观测性与成本 · 所有领域

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

浏览 Amazon →