我正在尝试将 CloudFront 分配配置为对 S3 源使用源故障转移。最初，这看起来是个好主意 - 当主存储桶所在的区域关闭时，所有请求都会自动路由到故障转移存储桶。但是，在 CloudFront 文档中，我发现了以下与响应超时相关的描述：
GET 和 HEAD 请求 – 如果 Amazon S3 在 30 秒内未响应或停止响应 30 秒，CloudFront 将断开连接，并再尝试两次联系源。如果源在第三次尝试期间未回复，CloudFront 不会重试，直到它收到对同一 CloudFront 源上的内容的另一个请求。
对于所有请求，CloudFront 都会尝试与 S3 建立连接。如果连接在 10 秒内失败，CloudFront 将断开连接，并再尝试两次联系 S3。如果源在第三次尝试期间未回复，CloudFront 不会重试，直到它收到对同一源上内容的另一个请求。
无法更改 S3 的响应超时。
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorS3Origin.html#RequestS3RequestTimeout
如此高的响应超时以及 CloudFront 故障转移不像 Route53 健康检查那样工作的事实，即它总是尝试将流量路由到主源，即使以前的请求失败，也提出了一个问题 - CloudFront 故障转移对于整个区域可能关闭的罕见情况是否真的实用？看起来在这种情况下，通过CloudFront托管的网站的性能无论如何都会非常差。我错过了什么吗？
事实上，此响应超时是运行状况检查的一部分，而不是加载请求的用户。如果源运行状况不佳，CloudFront 将开始将所有用户流量定向到故障转移。
因此，除了执行运行状况检查的 30 秒之外，用户不会遇到性能问题，CloudFront 实际上正在执行运行状况检查以了解它是否应该切换
。