☰

将一些 URL 请求重定向到 CloudFront，并将其余请求直接重定向到普通服务器？

tag-icon • tag-icon amazon-cloudfront
将一些 URL 请求重定向到 CloudFront，并将其余请求直接重定向到普通服务器？

假设我有两种类型的 URL 请求必须由我的 REST API 处理：

http://query.restapi.com/image.png?apikey=abc123

http://query.restapi.com/2.0/<apiKey>/resource.json?from=umi.us_census00.state_geometry

仅对于静态图像（即正则表达式：）*.png?.*，我才需要利用 CloudFront 的缓存，其余请求将不会获取缓存数据，并且需要转到普通 EC2 服务器（或者至少采取更快的间接路由到普通 EC2 服务器？）。

也许无需担心因 CloudFront 未命中而增加的请求时间？

也许我的情况不太适合使用 CloudFront？

答案1

您应该构建 HTML 以对静态内容使用不同的 URL 主机名。

使用firebug看看任何大型网络公司的主内容。

例如，Facebook 使用http://static.ak.fbcdn.net对于静态内容，我假设使用 Akamai。（另一个 CDN，如 Cloudfront）其他非静态内容直接来自 facebook.com。

通过使用 CNAME，您可以让生活变得更加轻松。

例如 static.restapi.com --> d1234.cloudfront.net

然后，您只需要处理页面的呈现方式，为动态页面使用主主机名，为静态内容使用静态主机名。

您上面提到了“重定向”。我想确保您不要尝试进行 HTTP 重定向。如果您的最终用户必须访问您的网站才能进行重定向，那么 CDN 提供的加速效果将大打折扣。您希望主页一次访问，然后从更靠近最终用户的 CDN 加载尽可能多的内容。

合理？

答案2

正如 @JoelK 所说，您确实应该为静态内容使用不同的域。静态域（例如 static.restapi.com）将完全由 CloudFront 提供服务，而动态域（例如 query.restapi.com）则由您的 EC2 实例提供服务。如果您需要限制对静态资源的访问，请查看 CloudFront 的签名 URL，它允许您生成仅在特定时间内有效的 URL。（API 的用户不应直接引用静态内容 - API 应提供静态资源的位置。）

如果您使用从 EC2 服务器到 CloudFront 的 HTTP 重定向，那么您将不会从 CloudFront 获得任何好处，因为客户端仍然需要为每个静态资源向 EC2 发出请求。

如果由于某种原因您无法在其他域上托管静态内容，则可以使用 CloudFront 的支持动态内容。它允许您为 CloudFront 分发配置多个来源，这样您的静态和动态内容都可以由单个域上的 CloudFront 提供服务。

相关内容