经过大量搜索，我似乎找不到在 Cloudfront 中缓存整个网站是否可行的问题。（静态资产以及动态请求返回的 HTML）。
设置
我的原始服务器不是 EC2 实例，而是在单独的托管上。
我已经设置了一个 Cloudfront 发行版来缓存来自我的原始服务器的所有内容example.com。我可以通过 Cloudfront 生成的 URL 访问它abcxyz.cloudfront.net。
将 Cloudfront 设置为我的原始服务器“前面”？
我需要帮助理解的是，我是否可以将我的域指向 cloudfront，因此example.com首先进入 Cloudfront 缓存（类似于如何在原始服务器“前面”设置 Varnish）。
在这样的设置下，我应该在 Cloudfront 中将我的原始服务器设置为什么？将其设置为example.com会导致循环引用，其中 cloudfront 尝试检查自身资源。
我的原始服务器是否不再设置为响应example.com此设置中的请求？（这允许我将 Cloudfront 中的原始服务器设置为“content.example.com”之类的内容，并从那里响应动态和静态请求？）
或者 Cloudfront 不适合用作全站缓存？我是否不应该尝试从缓存中提供动态响应（HTML 输出），而应该仅提供静态资产（js、img、css 等）？
答案1
经过进一步的研究，Cloudfront 似乎可以缓存您的整个网站，但是否要这样做值得研究。希望这对未来的任何路人都有用。
全站交付
以下是一些信息全站交付 警告：这份幻灯片是高级的，没有涉及实施细节
为了完成全站交付，您需要遵循这些常规步骤。
假设您想要通过 Cloudfront 提供服务
example.com（www.example.com您希望 Cloudfront 充当站点范围的缓存，类似于您使用 Varnish 的方式）。
设置分发
在 Cloudfront 上为您的域设置一个分发。
- 我通常选择让我的源服务器通过输出标头决定缓存设置
- 将您的原点设置为类似
content.example.com
指向您的域名
1）将您的域名顶级（example.com可能www.example.com）指向您的 Cloudfront URL - 它将类似于abc123.cloudfront.net而不是 IP 地址
笔记这是一个 CNAME（abc123.cloudfront.net）而不是 A 记录（IP 地址）。我认为，您的 DNS 是否允许您为根域设置 CNAME 而不是 A 记录可能会因提供商而异。
事实上，我认为为根域级别设置 CNAME 违反了 RFC。这可能会限制您必须将域的“www”版本设置为 Cloudfront、使用 Route 53 或使用 DNS Made Simple 作为这篇文章建议。
2) 设置您的 DNS 记录，使类似的东西content.example.com指向您的原始服务器。这将为 cloudfront 提供一种访问您的原始服务器的方法，但公众仍然可以使用example.com和www.example.com查看网站内容
注意事项
有几点需要注意：
Cookies - 缓存是否删除 cookies 很重要。带有 cookies 的请求通常不会被缓存（或者更准确地说，每个唯一的 cookie 都会创建不同的缓存副本)。考虑让 Cloudfront 忽略服务器设置的 cookie，以便它可以缓存内容。这不会影响从 Google Analytics 或 Disqus 评论等服务添加的客户端 cookie。如果您依赖于将 cookie/会话 ID 与访客和经过身份验证的用户分开，则会影响服务器逻辑。
Cloudfront 支持
GET和HEAD请求。POST 和其他 HTTP 动词请求将导致错误页面。如果您允许用户提交表单以及 ajax 请求，则这会产生影响。
我的网站上没有公共用户。但我有一个仅供我使用的管理区域。因此，我可以content.example.com直接通过 进入我网站的管理区域，而不必通过公共example.com和www.example.com进入。这完全绕过了缓存，消除了传递 cookie 的需要，并允许使用任何 HTTP 动词。
这对我来说很管用，但我怀疑对大多数人来说这不是一个好的情况。Cloudfront 和全站点缓存的情况可能有所不同。它对于静态资产缓存仍然很好。
答案2
我需要帮助理解的是，我是否可以将我的域指向 cloudfront，因此 example.com 首先进入 Cloudfront 缓存（类似于如何在原始服务器“前面”设置 Varnish）。
是的，你的想法是正确的。DNS将直接指向cloudfront。
在这样的设置下，我应该在 Cloudfront 中将原始服务器设置为什么？将其设置为 example.com 会导致循环引用，其中 cloudfront 会尝试检查自身资源。
您需要一个不同的域名来指向您的“来源”（即您的真实服务器）。因此，如果您的实际网址是，example.com您可以执行direct.example.com直接指向您的主机的操作。请注意，您的服务器的证书和路由规则需要能够处理接受此备用域名。
在此设置中，我的原始服务器是否应不再设置为响应 example.com 请求？（这允许我将 Cloudfront 中的原始服务器设置为“content.example.com”之类的内容，并从那里响应动态和静态请求？）
正确。但您不一定需要将源设置为“不再”接受请求。您只需要确保它可以通过新主机名（即content.example.com）处理请求。
或者 Cloudfront 不适合用作全站缓存？我是否不应该尝试从缓存中提供动态响应（HTML 输出），而应该仅提供静态资产（js、img、css 等）？
您绝对可以缓存整个站点。Cloudfront 将响应缓存控制标头（只要您将其配置为这样做）。我建议您确保允许通过您需要的任何 HTTP 请求类型、标头和 cookie（可能允许所有内容）。您可能希望将默认 TTL 设置为 0，以便它只缓存您告诉它的内容（使用缓存控制标头）。