多 Region 灾备方案真正难的地方，不是把基础设施复制到另一个 Region，而是证明故障发生时，Terraform Enterprise 能否在可接受的时间内恢复，并且不会丢失关键状态。AWS、HashiCorp 与 Athenahealth 通过 AWS Fault Injection Service（AWS FIS）设计并执行了分阶段的故障注入实验，覆盖 Amazon EC2、Amazon Aurora 和 Amazon S3，最终实现了约 12 到 14 分钟的恢复时间。
这类实验给平台团队的启发是：灾备不能只停留在架构图和备份策略上，必须在受控范围内主动制造故障，验证依赖关系、恢复流程和实际 RTO。
从架构假设走向故障实验
Terraform Enterprise 的灾备流程通常依赖多个 AWS 服务：
- Amazon EC2 承载应用节点和相关组件。
- Amazon Aurora 保存平台运行所需的数据库数据。
- Amazon S3 保存对象数据，其中可能包括 Terraform state 文件或备份。
- 主 Region 与备用 Region 之间需要保持数据复制、网络连通和访问权限一致。
单独测试某一个服务，往往只能证明局部恢复能力。真实故障可能同时影响应用、数据库访问和对象存储依赖，因此实验需要覆盖从基础设施到数据层的完整路径。
AWS FIS 的价值在于，它可以把故障注入变成可审计、可限制范围的实验。实验前可以指定目标资源、持续时间和停止条件；实验中观察监控、告警和自动化流程；实验后则根据恢复时间和数据一致性判断方案是否满足目标。
三阶段实验设计
一个可操作的实验可以拆成三个阶段，每个阶段只扩大一次故障范围。
第一阶段：验证 EC2 故障恢复
先让应用节点或承载 Terraform Enterprise 的 EC2 实例进入不可用状态，观察备用 Region 是否能够接管，以及 DNS、负载均衡、网络路由和权限是否都已准备就绪。
这一阶段重点检查：
- 备用节点能否按预期启动。
- 应用配置和密钥是否完整。
- 健康检查是否能识别主 Region 故障。
- 运维人员能否在没有手工猜测的情况下执行切换。
第二阶段：验证 Aurora 故障恢复
接着测试数据库层。应用节点恢复并不代表 Terraform Enterprise 已经可用，因为数据库中的组织、工作区、运行记录和配置仍然是关键依赖。
实验应确认数据库复制或恢复流程的延迟、备用数据库的提升操作、连接字符串切换，以及应用重新建立数据库连接后的行为。这里要同时观察恢复时间和数据完整性，不能只看实例是否显示为 available。
第三阶段：验证 S3 依赖与状态文件访问
最后测试对象存储。S3 可能承载备份、上传对象以及 Terraform state 文件。即使 EC2 和 Aurora 都已恢复，只要应用无法读取正确的 state，工作区就可能无法继续运行。
这一阶段需要重点验证：
- 备用 Region 是否拥有可读的对象数据。
- 跨 Region 复制是否已完成。
- IAM policy、bucket policy 和 KMS 权限是否同时覆盖备用路径。
- 应用使用的 bucket 配置是否会随切换更新。
- state 文件版本是否一致，是否可能读取旧副本。
一个可改造的 AWS FIS 实验示例
下面是一个最小化的实验模板示例。它假设已经在备用环境准备好恢复自动化，并且使用标签 tfe-dr-test=true 标识允许被测试的 EC2 实例。运行前请将资源 ARN、角色 ARN 和 Region 替换为实际值，并先在非生产环境验证。
cat > fis-ec2-stop-experiment.json <<'JSON'
{
"description": "Stop tagged Terraform Enterprise test instances",
"targets": {
"tfeInstances": {
"resourceType": "aws:ec2:instance",
"resourceTags": {
"tfe-dr-test": "true"
},
"selectionMode": "COUNT(1)"
}
},
"actions": {
"stopInstances": {
"actionId": "aws:ec2:stop-instances",
"parameters": {
"duration": "PT5M"
},
"targets": {
"Instances": "tfeInstances"
}
}
},
"stopConditions": [
{
"source": "aws:cloudwatch:alarm",
"value": "arn:aws:cloudwatch:us-east-1:111122223333:alarm:tfe-dr-stop"
}
],
"roleArn": "arn:aws:iam::111122223333:role/AWSFISExperimentRole",
"logConfiguration": {
"logSchemaVersion": 2,
"cloudWatchLogsConfiguration": {
"logGroupArn": "arn:aws:logs:us-east-1:111122223333:log-group:/aws/fis/tfe-dr"
}
}
}
JSON
aws fis create-experiment-template \
--cli-input-json file://fis-ec2-stop-experiment.json \
--region us-east-1
这个示例只演示 EC2 层面的故障注入。Aurora、S3 以及跨 Region 切换需要根据实际复制方式和 AWS FIS 支持的动作单独建模。不要把停止实例的实验模板直接扩展到生产资源；应使用精确标签、资源 ARN、CloudWatch 停止条件和明确的实验窗口限制爆炸半径。
在每个阶段记录至少以下指标：
- 故障注入开始时间。
- 监控发现故障的时间。
- 自动化切换开始和完成时间。
- Terraform Enterprise 恢复健康检查的时间。
- 第一个成功运行或状态读取完成的时间。
- 数据复制延迟和恢复后的数据一致性结果。
实验结果显示，经过分阶段验证和自动化切换，整体恢复时间可以达到约 12 到 14 分钟。这个数字不是架构的固有属性，而是特定环境、自动化程度、数据复制状态和操作流程共同产生的结果，因此每个团队都应该通过自己的实验重新测量。
最容易被忽略的状态文件依赖
灾备设计中最危险的误区之一，是把 Terraform state 当成普通备份文件。state 不是只在恢复时读取一次的归档，它参与 Terraform plan、apply、锁定和漂移检测。应用已经启动，并不表示工作区已经具备可用的灾备能力。
需要特别检查以下问题：
- 主 Region 和备用 Region 是否可能同时写入同一个工作区。
- S3 复制是否存在延迟，切换时读取到的是否是旧版本。
- 状态锁的实现是否能够跨 Region 工作。
- KMS key、bucket policy 和 IAM role 是否允许备用环境读取和写入。
- 恢复流程是否明确规定了旧 Region 重新上线后的写入策略。
- 是否有办法确认恢复后的 state 与数据库中的工作区元数据相匹配。
比较稳妥的做法是把“应用可访问”和“工作区可执行”定义成两个不同的恢复检查点。只有当平台能够读取正确的 state、完成锁定，并成功执行一个经过批准的验证工作流时，才把服务标记为真正恢复。
落地时的检查清单
在把实验推进到生产前，可以按下面的顺序收敛风险：
- 为测试资源添加专用标签，并确认 FIS 角色只能访问这些资源。
- 在备用 Region 单独演练 EC2、Aurora 和 S3 的恢复动作。
- 将 DNS、密钥、KMS、IAM、网络和应用配置纳入切换脚本，而不是依赖临时手工操作。
- 使用 CloudWatch 告警作为实验停止条件，避免故障范围超过预期。
- 为每次实验记录 RTO、数据复制延迟、state 版本和人工操作步骤。
- 在主 Region 恢复后明确回切策略，避免两个 Region 同时成为写入端。
多 Region 灾备的完成标志不是“备用资源已经存在”，而是故障注入后，平台能够在目标时间内恢复，数据依赖保持一致，团队也能按文档稳定执行切换。AWS FIS 提供了验证这件事的工具，而 EC2、Aurora、S3 与 Terraform state 之间的依赖关系，决定了实验必须覆盖完整业务链路。