在Web应用加速架构中，CloudFront位于用户和源站之间，默认情况下单个源站一旦出现故障，所有经由该源站处理的请求都会失败。为了提高源站可用性，AWS提供了源站组功能，允许为同一路径定义主源站和备用源站，并根据HTTP响应状态码自动执行切换。这种机制不需要额外部署主动健康检查器，只依赖源站返回的状态码即可完成故障转移，非常适合静态资源加速和读多写少的API场景。
源站故障转移的工作机制
源站组由一个主源和一个或多个备用源组成。CloudFront收到用户请求后，会首先将请求发送给主源。如果主源返回的HTTP状态码属于故障转移条件中指定的集合，CloudFront会立即向备用源重新发送相同的请求，并把备用源的响应返回给用户。这个判断发生在响应返回阶段，也就是说主源已经产生了一次错误响应，但用户最终看到的是备用源的结果，因此对用户来说故障切换几乎是透明的。
需要特别注意的是，CloudFront对GET和HEAD请求会自动执行故障转移。对于POST、PUT、PATCH、DELETE等带请求体的方法，CloudFront不会自动重试，因为请求体可能已经部分发送给主源，重复发送可能导致数据不一致或副作用。如果业务需要对这些方法进行故障转移，可以在客户端实现幂等重试逻辑，或者使用Lambda@Edge在边缘侧根据业务规则进行改造。大多数静态加速和读取接口都可以通过GET和HEAD请求覆盖。
创建源站组时，故障转移条件可配置的状态码包括4xx和5xx中的一部分，常见默认值是500、502、503、504。你可以扩展加入403、404、429等状态码，但需要注意：如果选择404，主源返回资源不存在的响应也会被当作故障，可能导致备用源被频繁请求，甚至掩盖真实的业务语义。因此状态码清单应当根据主源的真实错误特征来设定，而不是把所有4xx都包含进去。
配置源站组实现状态码切换
在CloudFront控制台中，首先需要分别创建主源和备用源，然后在分配配置的源组选项卡中新建源组。创建源组时，将两个源加入成员列表，并指定其中一个作为主源。接着在故障转移条件中勾选需要触发的HTTP状态码，保存后把该源组设置为分配默认行为或指定路径的源。配置完成后，CloudFront会开始按照规则判断是否切换。
对于自动化环境和基础设施即代码场景，可以使用AWS CLI或CloudFormation进行配置。下面通过AWS CLI更新分配配置，只展示与源组相关的关键JSON片段。实际操作中需要将该片段合并到完整的分配配置中。
{
"Origins": {
"Items": [
{
"Id": "primary-origin",
"DomainName": "primary.ippipp.com",
"CustomOriginConfig": {
"HTTPPort": 80,
"HTTPSPort": 443,
"OriginProtocolPolicy": "https-only"
}
},
{
"Id": "secondary-origin",
"DomainName": "secondary.ippipp.com",
"CustomOriginConfig": {
"HTTPPort": 80,
"HTTPSPort": 443,
"OriginProtocolPolicy": "https-only"
}
}
],
"Quantity": 2
},
"OriginGroups": {
"Items": [
{
"Id": "my-origin-group",
"FailoverCriteria": {
"StatusCodes": {
"Items": [500, 502, 503, 504],
"Quantity": 4
}
},
"Members": {
"Items": [
{ "OriginId": "primary-origin" },
{ "OriginId": "secondary-origin" }
],
"Quantity": 2
}
}
],
"Quantity": 1
}
}
配置生效后，CloudFront会花费几分钟到十几分钟将新配置部署到全部边缘节点。另外需要重点留意缓存问题：CloudFront可能缓存主源返回的错误响应。如果主源错误响应被缓存，后续请求可能会直接返回缓存的错误而不触发新的故障转移。因此建议在行为设置中将错误响应缓存时间设置为0，或者只缓存正常响应，避免错误页面被边缘节点缓存后持续影响用户。
状态码选择与误切换规避
5xx系列状态码通常表明源站服务器内部错误、网关错误或临时不可用，是最适合触发切换的信号。例如502表示网关错误，503表示服务不可用，504表示网关超时。这些错误通常意味着源站整体或部分服务已经无法正常响应，切换到备用源是合理的。而对于4xx系列则需要更谨慎地评估：403可能表示权限问题，如果主源因权限拒绝但备用源可以访问，可以纳入；404表示资源不存在，如果备用源有完整资源副本，切换是合理的，但如果404只是业务上正常的“无此资源”响应，切换会浪费备用源资源并掩盖业务真相。
另一个容易忽略的点是切换后的缓存行为。CloudFront会把故障转移后的响应视为正常响应，并按照缓存策略进行缓存。如果备用源返回200，边缘节点会缓存该响应，后续请求可能不再回源。如果备用源也返回错误码且不在故障转移条件中，该错误会直接返回给用户。此外，如果主源持续返回错误，CloudFront仍会将后续请求发送给主源，每次根据状态码判断是否切换。这意味着主源可能仍然承受一定压力，可以通过设置较短的错误缓存TTL来减少不必要的重复回源。
CloudFront源站故障转移属于被动式机制，它不会提前探测源站健康，只有请求到达且主源返回错误时才会触发切换。如果需要主动健康检查，可以结合Route 53健康检查、ELB或使用Lambda@Edge做自定义判断。被动机制的好处是简单、零额外成本，适用于大多数静态资源场景。对于核心业务，仍然建议配合监控和主动探测共同使用。
测试与监控主备切换
要验证主备切换是否生效，可以临时修改主源应用逻辑，使其对特定路径返回503，然后通过curl请求CloudFront分配域名。为了区分响应来源，可以在备用源响应中加入自定义响应头，例如X-Origin: secondary。下面是用curl测试的示例命令。
curl -I https://d1234567890.cloudfront.net/test-path
如果故障转移生效，响应头中会包含备用源标识。也可以通过CloudFront标准日志查看x-edge-result-type字段和x-edge-origin字段，确认请求是否被转发到备用源以及响应类型。这些日志字段对于审计切换频率和排查异常非常有帮助。
监控方面，CloudFront提供5xx错误率指标，可以在CloudWatch中创建告警。同时源站自身的日志可以分析哪些状态码触发了切换。对于关键业务，建议同时监控备用源的错误率，确保备用源本身也处于健康状态。如果备用源响应也异常，告警应能及时通知运维人员介入。结合实时日志或标准日志可以快速定位切换原因。
基于响应状态码的主备切换是提升源站可用性的轻量方案。它配置简单，但需要仔细选择触发条件、控制错误缓存、结合监控验证效果。建议将备用源部署在不同可用区甚至不同区域，避免单点故障影响整体可用性。如果业务要求更复杂的故障转移逻辑，可以进一步结合Lambda@Edge实现细粒度控制。
CloudFront源站故障转移响应状态码主备切换修改时间：2026-08-26 12:57:38