由于重定向是浏览器的指令，告诉它在别处寻找所请求的资源，CloudFront isn't designed to follow redirects itself -- 它将重定向返回给浏览器。
您想要的是新的 CloudFront 缓存行为和新的 CloudFront 源服务器声明，在处理您的站点的现有 CloudFront 分配中配置。
在 CloudFront 中，添加一个新的 Origin，将 Origin 域名设置为指向 EC2 实例（或实例前面的负载均衡器，如果有的话）的主机名。您会注意到一个名为“Origin Path”的字段，您可能想将其设置为“/blog/”或类似的内容，但这是不正确的。将“原点路径”留空。
然后添加一个与路径模式/blog/* 匹配的新缓存行为并将其指向新的原点。
简而言之，这就是您要寻找的东西，但还有其他几个因素需要适当的设置和配置。
您的源服务器上需要一个 TLS 证书，除非您将源协议策略设置为仅 HTTP，在这种情况下，您在 CloudFront 和 EC2 之间运行未加密的流量。 CloudFront 有 specific requirements 用于在您的源服务器上正确配置 TLS，大多数与 TLS 相关的错误配置将导致 502 Bad Gateway error 尽管该错误代码当然可能有其他原因。
您的博客软件可能需要查询字符串参数和/或 cookie，默认情况下，CloudFront 会从所有请求中剥离（因为它们会干扰缓存）。这是Cache Behavior settings 中的两个通常需要自定义，因为默认值基于典型静态内容的适当设置。
您还需要将博客软件配置为期望传入请求包含路径前缀“/blog/”，因为 CloudFront 不会删除路径组件。将一个或多个元素剥离的原始服务器路径呈现给原始服务器的唯一方法是使用 Lambda@Edge 重写路径 -- as I explained here。
如果您现在在精神上反对将路径设置为“/blog/”而不是“/blog”，要记住的问题是该路径需要正确锚定——HTTP 语义假定目录级别以“/”结尾" 而文件和其他资源没有，因此如果您尝试将博客放在不以 / 结尾的路径上，您可能会遇到困难......但为了不应该的用户的利益预计会键入尾随 /，您仍然需要在 S3 中配置重定向——但只是为了将 /blog 的请求发送回 /blog/。
<RoutingRules>
<RoutingRule>
<Condition>
<KeyEquals>blog</KeyEquals>
</Condition>
<Redirect>
<ReplaceKeyWith>blog/</ReplaceKeyWith>
<HostName>${main_site_hostname}</HostName>
<Protocol>https</Protocol>
</Redirect>
</RoutingRule>
</RoutingRules>
在测试时，您可能还想设置您的Error Caching Minimum TTL to 0，这样您就不会修复问题并在接下来的 5 分钟内继续看到返回的缓存错误，即使错误已通过您所做的更改得到解决。 CloudFront 这样做是为了帮助避免可能已经遇到问题的源服务器过载（正如它返回错误的事实所证明的那样），但它让一些用户措手不及。