AWS CloudFront作为全球性的CDN服务，其源站（Origin）配置直接决定了内容的可靠性和响应速度。许多使用者在入门阶段只会给分发（Distribution）配一个S3或ALB源站，但当业务对可用性有更高要求时，单源站架构就成了明显的短板。CloudFront提供了多源站、Origin Group故障转移、源站权重等高级能力，合理利用这些功能可以在源站故障时实现秒级自动切换，大幅降低故障对用户的影响。
一、CloudFront源站类型与多源站基础配置
CloudFront支持多种源站类型，包括S3存储桶、自定义源站（如EC2上的Web服务器、ELB负载均衡器）、MediaPackage通道以及Lambda函数URL等。在讨论高级配置之前，需要先理解多源站架构的基本形态。
多源站配置的核心是Behavior（行为）与Origin的绑定关系。一个Distribution可以配置多个Origin，而每个Behavior通过Cache Behavior的路径匹配规则将特定请求路由到对应的源站。例如，/api/*可以指向后端API的ALB，/static/*指向S3静态资源桶，其余路径指向主Web服务器。这种按路径分流的方式是最常见的多源站用法。
在创建Distribution时，首先在Origins选项卡中逐个添加源站。以下是一个通过AWS CLI添加自定义源站的示例：
aws cloudfront create-distribution \ --distribution-config file://dist-config.json
其中dist-config.json的关键部分如下：
{
"Origins": {
"Items": [
{
"Id": "primary-web",
"DomainName": "primary.example-origin.com",
"CustomOriginConfig": {
"OriginProtocolPolicy": "https-only",
"OriginReadTimeout": 30,
"OriginKeepaliveTimeout": 5
}
},
{
"Id": "backup-web",
"DomainName": "backup.example-origin.com",
"CustomOriginConfig": {
"OriginProtocolPolicy": "https-only"
}
}
],
"Quantity": 2
}
}需要特别注意的是，Origin的Id在Distribution内必须唯一，后续在Behavior中引用的就是这个Id。另一个容易忽略的细节是OriginProtocolPolicy：如果源站是S3且未配置静态网站托管，建议选择https-only以保证传输安全；而自定义源站如果只支持HTTP，则选择http-only，否则会出现502错误。
多源站按路径分流适合功能拆分场景，但它并不能解决源站故障的问题。当某个源站完全不可用时，按路径分流的架构下该路径的请求依然会失败。要实现故障自动切换，就需要用到Origin Group。
二、Origin Group故障转移的工作原理与配置
Origin Group是CloudFront提供的主备源站机制。一个Origin Group包含一个主源站（Primary Origin）和一个次源站（Second Origin）。CloudFront在向主源站转发请求时，如果收到特定的失败响应或连接超时，会自动将请求重试转发到次源站，整个过程对最终用户透明。
触发故障转移的条件是理解这套机制的关键。当以下情况发生时，CloudFront会将请求切换到次源站：
- 返回HTTP状态码500、502、503或504
- 连接主源站超时（由OriginReadTimeout控制）
- TCP连接被主源站重置
- 源站返回的响应体被截断（例如Content-Length与实际不符）
注意，4xx错误码不会触发故障转移。这是因为404、403等状态码通常代表业务层的问题，例如资源不存在或权限不足，切换到备用源站大概率得到相同结果。如果你的业务场景中备用源站可能持有不同的内容（例如主站故障期间的降级静态页），就需要在源站层面主动返回503来触发切换，而不是返回404。
配置Origin Group可以在控制台的Origins页面点击Create origin group，选择已存在的主源站和次源站，也可以用CLI完成：
{
"Id": "web-failover-group",
"FailoverCriteria": {
"StatusCodes": {
"Items": [500, 502, 503, 504],
"Quantity": 4
}
},
"Members": {
"Items": [
{ "OriginId": "primary-web" },
{ "OriginId": "backup-web" }
],
"Quantity": 2
}
}FailoverCriteria中的StatusCodes是可自定义的，你可以按需增减触发切换的状态码，但不能包含4xx。配置完成后，在Behavior中将Target Origin指定为这个Origin Group即可。运行时，CloudFront会先尝试主源站，失败后自动重试次源站，若次源站也失败，才向用户返回错误。
有一个实际部署中常见的坑：Origin Group只能包含两个成员，且两个源站的内容应保持一致或兼容。如果主备源站返回的内容版本差异较大，故障转移后用户可能看到不一致的页面状态，此时需要在次源站上做好版本同步，或在响应头中标记来源以便排查。
三、源站权重分流与流量灰度
除了主备故障转移，CloudFront还支持基于源站权重的流量分配。在2022年之后推出的Origin Shield和负载均衡增强能力中，可以为Origin Group启用Connection Attempts与Connection Timeout调优，同时对多个源站设置权重实现按比例分流。权重配置适用于蓝绿发布、灰度测试或多机房流量调度场景。
权重分流与故障转移可以组合使用：正常情况下按权重比例分发流量，当某个源站返回失败响应时，该源站的流量会被临时切换到健康源站。这种组合模式的典型配置思路如下：
{
"Origins": {
"Items": [
{
"Id": "web-blue",
"DomainName": "blue.example-origin.com",
"CustomOriginConfig": {
"OriginProtocolPolicy": "https-only"
}
},
{
"Id": "web-green",
"DomainName": "green.example-origin.com",
"CustomOriginConfig": {
"OriginProtocolPolicy": "https-only"
}
}
]
}
}在控制台中将两个源站组成Group时，可以分别设置权重值，例如90比10，表示90%的请求进入蓝组，10%进入绿组。灰度验证新版本时，先将绿组权重设为很小比例，观察监控指标后再逐步调整。
使用权重分流时务必关注缓存一致性。CloudFront边缘节点是根据缓存键（Cache Key）来缓存响应的，默认不包含源站身份。也就是说，同一个URL的响应如果第一次由蓝组返回并缓存，后续请求即使按权重应路由到绿组，也会直接命中缓存。要避免这个问题，可以在请求头中注入源站标识并通过Cache Policy将其纳入缓存键，或者在灰度期间为不同版本使用不同的URL路径。后者实现更简单，推荐在大多数场景下使用路径隔离而非缓存键污染，因为扩大缓存键会显著降低缓存命中率，增加回源压力。
四、高可用架构的进阶设计与监控
单纯依赖CloudFront的故障转移机制还不够完善。故障转移生效的前提是主源站返回5xx或超时，但如果主源站处于亚健康状态（例如响应极慢但不超时、返回内容异常），CloudFront无法感知。因此建议在源站前再加一层弹性负载均衡，由ELB的健康检查机制处理亚健康节点的剔除，CloudFront的Origin Group则处理整个可用区的灾难性故障。
另一个进阶方案是结合Lambda@Edge或CloudFront Functions实现动态源站选择。CloudFront Functions运行在边缘节点，可以在Viewer Request阶段修改请求属性；Lambda@Edge则可以在Origin Request阶段介入，此时可以根据请求特征（如用户区域、Cookie标识）动态改写目标源站。以下是一个简单的Lambda@Edge示例：
exports.handler = async (event) => {
const request = event.Records[0].cf.request;
// 根据自定义头或地理位置改写源站
const region = event.Records[0].cf.viewer.country;
if (region === 'CN') {
request.origin = {
custom: {
domainName: 'ap-origin.example-origin.com',
port: 443,
protocol: 'https',
path: '',
customHeaders: {}
}
};
}
return request;
};这种动态改写方式可以实现地理路由、金丝雀发布等复杂策略，但要注意Lambda@Edge的执行成本和延迟，频繁改写源站还会导致不同边缘节点的缓存内容不一致，需谨慎评估。
监控方面，建议开启CloudFront的标准日志并导入CloudWatch，重点关注两个指标：OriginLatency（回源延迟）和ErrorRate（错误率）。当ErrorRate中5xx占比上升而缓存命中率没有明显变化时，大概率是源端出现了问题。可以为Origin Group的故障转移次数配置CloudWatch告警，一旦发生转移，即便用户请求未失败，也应及时排查主源站健康状态，避免长期运行在降级架构上。
最后补充一个成本相关的注意点：故障转移意味着CloudFront会对同一请求发起两次回源尝试，回源流量和请求费用都会增加。对于大流量站点，频繁触发误转移会造成明显的成本放大，因此FailoverCriteria中的状态码列表不宜配置得过宽，只保留真正代表源站故障的5xx码即可。
综合来看，CloudFront的多源站能力是一个层次分明的工具集：Behavior按路径分流解决功能拆分，Origin Group解决灾难性故障的自动切换，权重分流解决灰度发布，配合ELB和Lambda@Edge则能构建出适应复杂业务场景的高可用分发架构。掌握这些配置的关键在于理解每一层机制的触发条件和局限性，再结合自身业务的容灾目标进行组合使用。
CloudFront多源站故障转移Origin Group修改时间：2026-09-01 10:05:12