AWS API Gateway自定义域的Cname

Question

这个概念很简单。

创建一个Cname开关，该开关通过AWS API Gateway指向蓝色/绿色部署通道。 该API有两个阶段，分别将蓝色和绿色映射回环境变量，该环境变量又映射回与其自身专用版本关联的Lambda别名。 因此，现在有两个单独的渠道可以进行部署。 所有这些都很好。

当在Route53中创建一个Cname指向API网关蓝色或绿色自定义域时，就会出现此问题。 SSL证书保存在AWS Certificate Manager中。

当我们通过Cname调用蓝色端点时，会收到SSL错误

curl -Il -H "Host:blue-api.example.com" -H "x-api-key:xxxxxxxxx" 
-X GET https://cname-api.example.com/questions/health

curl：（35）SSL对等握手失败，服务器很可能需要客户端证书才能连接

而当我们直接调用自定义域时，它将起作用

curl -Il -H "Host:blue-api.example.com" -H "x-api-key:xxxxxxxxx" 
-X GET https://blue-api.example.com/questions/health

HTTP / 1.1 200 OK

任何指示或建议将不胜感激？

对第一条评论的回应

谢谢Michael-是的，我们正在运行边缘优化的自定义域名，因此我们已将eu-west-1的SSL证书导出到us-east-1的AWS Cert Manager中。 API网关生成的Cloudfront与costom域和cname一起托管在us-east-1中，而根域则托管在eu-west-1中。 这可能是问题吗？

我们正在尝试一些有关启用以下标头的测试，并将报告如下：

ResponseParameters:
method.response.header.Access-Control-Allow-Headers: true
method.response.header.Access-Control-Allow-Methods: true
method.response.header.Access-Control-Allow-Origin: true

我意识到我们可以使用一个自定义域，而改为使用映射到路径的阶段来创建通道，但是上述方法是首选解决方案。

我们还向AWS开了张罚单，因为这也困扰了他们，并已升级为他们的内部服务团队。

:)

Answer 1

因此，在经过数周的Amazon Support反复研究之后，我们得到了一个可行的解决方案，但也许不是早期提到的解决方案中最具成本效益的解决方案。

工作流程-

1.创建API GW，其中每个阶段都有自己的自定义域。

EG blue-stage> blue-api.example.com和green-stage> green-api.example.com

2.然后在与创建API GW相同的AWS区域中创建一个Cname。 EG cname-api.example.com

3.使用与Cname（cname-api.example.com）相同的DNS条目（重复）创建Web Edge Cloudfront实例，然后将此Cloudfront实例指向任意S3存储桶。

现在发出请求

curl -Il -H "Host:blue-api.example.com" -H "x-api-key:xxxxxxxxx" 
-X GET https://cname-api.example.com/questions/health

HTTP / 1.1 200 OK

是的，这对于我们需要达到的目标来说是过大的，而且不是最具成本效益的，我们也不在做KISS（保持简单愚蠢）。 是的，很高兴听到其他人如何构建类似的基础架构！