分配是否可以自动匹配请求中的子域以找出来源

Question

我们在同一个域中添加了许多几乎相同的应用程序，每个应用程序都可以通过其特定的子域访问。每个应用程序都有特定的资产（不是很多）。

每个应用程序都引用相同的内容cdn.mydomain.com以从 Cloudfront 获取资产。

资产以间隔命名。举个例子：

应用程序1：

• 可以从 app1.mydomain.com
• 资产网址是 cdn.mydomain.com/assets/app1
• 云端原点 app1.mydomain.com
• 缓存行为/assets/app1/*到原点app1.mydomain.com

当 Cloudfront 缓存中没有资产时，它会从正确的来源下载资产。

实际上，每次添加新应用程序时，我们都会在同一发行版上创建新的来源和缓存行为。

我们正在尝试简化该过程，以便 Cloudfront 能够从正确的来源获取资产，而无需指定它。如果我们在一个分布中达到原始数量的限制，这将解决问题。

我们怎样才能做到这一点，这可能吗？

我们正在考虑mydomain.com使用缓存配置来转发host标头，但我们不确定这是否会奏效。

Answer 1

起源与缓存行为相关，缓存行为与路径模式相关。你不能真正做你想做的事情。

我建议您应该为每个应用程序和每个子域创建一个发行版。使用 aws-cli 编写脚本非常容易，因为一旦您按照自己喜欢的方式进行设置，您就可以使用其配置输出作为模板来制作更多内容，而只需进行最少的更改。（我使用 Perl 脚本构建最终 JSON 以创建每个分发版，使用最少的输入（例如备用域名和证书 ARN）并将其输出通过管道传输到 aws-cli。）

我相信这是正确的方法，因为：

• CloudFront 无法根据Host标头选择源。只有路径模式用于选择原点。
• Lambda@Edge 可以重写路径并可以检查Host标头，但它不能在匹配完成之前重写路径以选择缓存行为（以及原点）。您不能使用 Lambda@Edge 使 CloudFront 切换或选择源，除非您生成浏览器重定向（出于性能原因，您可能不想这样做）。我已经提交了一个功能请求，以允许 Lambda 触发器向 CloudFront 发出信号，它应该返回到处理的开始并重新评估路径，但我不知道它是否被视为未来的功能——AWS 倾向于保持他们对未来功能的计划接近背心，这是可以理解的。
• 由于资源不同，将站点合并到一个发行版中不会提高效率或节省成本
• 如果您决定将Host标头列入白名单，则意味着 CloudFront 将根据Host标头单独缓存响应，这与创建多个分配时的情况相同。即使路径相同，如果Host标头不同，它仍然会缓存单独的响应，因为它必须确保合理的行为
• 分发的默认限制是 200，而来源和缓存行为的限制是 25。两者都可以通过请求提高，但他们可以给你的分发数量是无限的，而其他资源是有限的，因为它们增加了工作量每个请求的系统，最终会对性能产生负面影响
• 单独的发行版为您提供单独的日志和报告
• 当每个应用程序都有自己的分布时，配置错误的爆炸半径更小

您还可以进入 Amazon Certificate Manager 和 * 的通配符证书*.cdn.example.com。然后使用例如app1.cdn.example.com作为 app1 发行版的备用域名并附加通配符证书。然后在app2.cdn.app.com发行版上重用相同的证书等。

请注意，您还可以从当前的解决方案中获得一个简单的迁移策略：您可以创建一个单独的发行版，*.cdn.example.com并将其作为备用域名。对应用程序进行编码以使用它们自己的唯一名称-here.cdn.example.com。将所有 DNS 记录指向此处。稍后，当您创建具有特定备用域名的分配时foo.cdn.example.com，CloudFront 将自动停止将这些请求路由到通配符分配，并开始将它们路由到具有特定域的分配。您将需要更改 DNS 条目...但 CloudFront 实际上会正确处理请求，将它们路由到新创建的分配，然后 您更改 DNS，因为它具有一些内部魔法，无论浏览器连接到新端点还是旧端点，它都会将非通配符主机名匹配到正确的分布……所以迁移事件几乎应该是非通配符事件。

无论如何，我建议通配符策略是一个很好的策略，这样您的应用程序都可以连接到特定的端点主机名，从而在未来提供更大的灵活性。