转发CloudFront主机报头到API网关

Question

我们有一个通配符(*)子域指向CloudFront发行版。origin是API Gateway.

我们需要知道API网关内的原始Host标头，以便我们可以路由请求。

当通过HTTP访问CloudFront分发时，简单地将Host标头列入白名单会返回一个错误-大概是因为API网关需要Host标头来知道调用哪个API。

如果是这种情况，是否有可能通过X-Forwarded-Host从CloudFront转发Host头到API网关?还是……是否有另一种方法来使用通配符子域与API网关?

Answer 1

我在今天晚些时候回答这个问题，尽管它有一个公认的答案，因为这个问题出现在这个问题的搜索顶部:

现在完全有可能通过X-Forwarded-Host从CloudFront动态转发原始Host头到API网关，而不必像建议的那样硬编码自定义源头。

这可以通过创建一个查看器请求边缘函数(Lambda@Edge或CloudFront函数)来完成，该函数在请求到达CloudFront之前拦截请求，将传入的Host标头映射到X-Forwarded-Host，然后在传递它之前将新的X-Forwarded-Host附加到请求的标头。

然后将API网关源的X-Forwarded-Host报头加入白名单。

在Node.js中，边缘函数看起来像:

export function handler(event, context, callback) {
    const request = event.Records[0].cf.request;
    request.headers['x-forwarded-host'] = [{
        key: 'X-Forwarded-Host',
        value: request.headers.host[0].value
    }];
    return callback(null, request);
}

Answer 2

这不是你最初问题的答案，但它可能是实现你的目标的另一种方式。

首先，在所有环境(包括prod)之间共享CF发行版会带来风险——当您需要测试CF配置的更改时，您将必须使用未经测试的更改修改prod CF dist，这可能会产生重大后果。

其次，如果你能在CI/CD管道的所有阶段测试整个环境是很棒的，但这并不总是可能的(CF尤其不适合)——所以它是关于在短反馈周期和测试的彻彻性之间找到平衡。

解决方案通常是在您的管道中引入额外的阶段，其中早期阶段对最常见的问题提供快速反馈，而后期阶段对不太常见的问题提供较慢的反馈。

根据你的情况，我建议:

1. 分支部署不部署CF -测试直接针对API网关
2. 主/默认部署DO部署CF -到"登台"环境-测试目标登台CF发行
3. 成功测试到"登台"环境的版本被提升到生产环境

通过引入暂存环境，您可以获得分支构建的快速反馈，但是您仍然有机会在进入prod之前测试缓存后面的东西。

如果您正在对CF配置进行更改，您可以让部署脚本动态地决定在某个触发器(可能是在分支名称中存在"cloudfront"一词-尽管这对某些人来说可能有点"神奇"!)下将CF包含在分支部署中，并且您可以在合并到master以在staging中进行测试之前在分支上测试这些更改。