AWS：重定向或代理文件答案

【问题标题】：AWS: To redirect or to proxy filesAWS：重定向或代理文件
【发布时间】：2013-01-06 14:01:20
【问题描述】：

让我解释一下困境。我使用亚马逊的 3 项服务：EC2、S3 和 CloudFront。 EC2 接收文件作为上传，将其存储在 S3 存储桶中。然后 CloudFront 镜像 S3 存储桶。唯一的限制是拥有用户友好的 URL。交付这些文件的哪种方法更好？

客户端 > CloudFront > EC2 > S3

客户端向 CloudFront URL 发出 HTTP 请求
Cloudfront 将请求转发到 EC2
EC2 将用户友好的 URL 转换为原始文件 URL
EC2 从 S3 读取文件

客户端 > EC2 ...重定向 ... CloudFront > S3

客户端向 EC2 发出 HTTP 请求
EC2 将用户友好的 URL 转换为原始文件 URL
EC2 重定向到 CloudFront，巫婆镜像 S3

这有两个维度：速度和成本。

我看到 facebook 在提供个人资料图片时使用第二种方法 http://graph.facebook.com/platform/picture

【问题讨论】：

标签： proxy amazon-web-services amazon-s3 amazon-cloudfront

【解决方案1】：

您当然不想强制 S3 和您的客户端之间的文件传输通过您的 EC2 实例。这会增加 EC2 实例的负载，增加带宽使用，并且无疑会减慢对用户的响应。

您的 EC2 实例为您提供了对 URL 格式的最大控制权，因此您希望客户端向它发出初始请求（以获得“用户友好”的 URL）。 EC2 实例只需向客户端发送重定向到实际包含内容的 CloudFront 或 S3 URL，客户端将直接从那里拉取它，而无需 EC2 的进一步参与。

除非您有大量请求，或者网络延迟必须尽可能低，否则我不会使用 CloudFront。

【讨论】：

所以，我将采用重定向方法。 CloudFront 不是必需品，但我认为这对营销来说是一件好事。
我注意到文件的延迟（到第一个字节的时间）在 S3 中的文件可能会从 120 毫秒到 400 毫秒不等，在我们偶尔缓慢的无线连接工作时甚至会超过 800 毫秒。另一方面，Cloudfront 的延迟低至 18 毫秒，这可不是开玩笑的。我几乎不会排除使用它。更多背景信息：readystate4.com/2012/07/09/amazon-s3-vs-amazon-cloudfront

【解决方案2】：

我个人只会在第一次上传文件时在 S3 中给文件一个好听的名称和适当的内容类型元标记，因此，从下载路径中完全删除您的 EC2 实例。您只需在 HTML 内容中将 clean-url 提供给您的客户端，并且该干净 URL 将直接指向 Cloudfront/S3 中的资源，该资源具有适当的元标记来提供所需的内容类型标头。

【讨论】：

这不是我的选择。 URL 必须非常用户友好。
@Andrew 你可以让 URL 变得尽可能友好。您可以为 Cloudfront 选择的域使用 CNAME，并且可以根据需要命名文件。如果您发送正确的内容类型标头，则绝对没有理由图像文件需要在其末尾具有 .jpg、.png 等。通过在 S3 中使用用户友好的名称命名文件，您可以完全消除通过服务器重定向的需要。没有任何理由让您的网络服务器必须处理比它必须处理的请求多 20 倍以上的请求（取决于您要重定向的图像/文件的数量）。
迈克在这里所说的 110%。至于 Facebook，我上次检查过，他们还进行动态调整大小，这就是他们从云服务器端拉取数据的原因——这是他们负担得起的。不过，对你来说，我会给文件起一个好听的名字，上传到 s3，然后通过云端 URL 提供文件。您可以在您的域 DNS 中创建一条 A 记录，这样您就可以为您的 Cloudfront 提供一个更漂亮的名称，例如 files.yoursite.com。