我们有一个我们从Elastic Beanstalk（AWS）提供的网站，这一切都很好。 我们使用内置负载均衡器通过HTTPS为我们的站点提供服务等。我们的数据库通过RDS服务分离，而不是与Web服务器在相同的EC2实例上。 到目前为止，我们很高兴成立。
现在，我们希望在我们网站的域名'/ blog'下build立一个WordPress博客（不是一个单独的或子域名，为了SEO的原因）。 我们的网站是一个定制的PHP应用程序（使用Laravel框架），我宁愿不从同一个地方托pipeWP应用程序和我们的网站。
我相信我们可以使用CloudFront（Amazon的CDN）来服务我们网站的/ blog部分，并将这些请求路由到不同的EC2实例上的单独WP安装。 我已经使用CloudFront做常规的CDNtypes的东西（静态资产），但是我对如何设置这种特殊types的configuration感到迷茫。
首先，这是一个疯狂的想法，还是听起来不错？ 其次，如果这是合理的，那么我需要知道什么来设置呢？
是的，如果您将整个站点设置为在CloudFront后面运行，则可以。 然后，您可以为该站点configuration默认的后端原始服务，并为/ blog创build一个例外以采用不同的path。
configuration新的CloudFront分配。 使用主站点的ELB或EB主机名称作为原点。 将站点的域名configuration为CloudFront中的备用域名。
接下来，添加第二个来源，目标是WP部署可以到达的主机名。 使用匹配/blog*的path模式创build行为，并使用第二个来源。
（如果/ blog *与网站的根目录中的其他内容相匹配…不太可能，但假设您在根目录/ blogosphere中有另一个页面，这会错误地匹配，所以您实际上需要创build两个模式/博客和/博客/ *）。
问题：请注意，创build一个原点时，有一个原点path的方框。 这可能不符合你的期望。 如果不确定，请留空。
源path是您希望Cloudfront将其发送到原始请求的前缀，即使它在URL中不可见。 所以，如果你把它设置为/ test，并且来自浏览器的请求是/ blog，那么后端服务器会看到请求到达/ test / blog。
原始path允许您预先添加到要请求的path，否则传入的path将从浏览器收到。 这意味着在您的WP安装中，当您直接连接到WP服务器时，内容的根目录需要位于/blog ，而不是/ 。 CloudFront目前不提供任何机制从path中删除组件。
还要记住，启用查询string和cookie转发到WordPress后端到WordPress需要的任何程度的工作。 当然，您的主站点也是如此。
如果您的服务器期望，您可能需要将Host:标题列入白名单 。 可能还有其他的，取决于服务器需要看到的标题，但是作为一条规则，您转发的标题越多，CloudFront可以执行的caching就越less，因为如果它将标题转发到源，则必须假定任何后续请求标头变化可能会从服务器接收到不同的响应，所以除非所有转发的标头匹配，否则不能从caching中提供请求。
最终，在configuration和testing之后，您可以将您的主机名称指向CloudFront端点，然后您就可以正常运行。