这个概念很简单 .
创建一个Cname开关，通过AWS API Gateway指向蓝/绿部署渠道 . API有两个阶段，蓝色和绿色映射回环境变量，然后环境变量映射回与其自己的专用版本相关联的Lambda别名 . 因此，现在有两个单独的渠道进行部署 . 所有这一切都很好 .
当在Route53中创建Cname以指向API网关蓝色或绿色自定义域时，会出现此问题 . SSL证书保存在AWS Certificate Manager中 .
当我们通过Cname调用蓝色 endpoints 时，我们会收到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好的
任何指针或建议将不胜感激？
对第一条评论的回复
感谢迈克尔 - 是的，我们已经将eu-west-1的SSL证书导出到了我们东部1的AWS Cert Manager，因为我们正在运行优化的边缘自定义域名 . 生成Cloudfront的API网关在us-east-1中与costom域和cname一起托管，但根域托管在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开放的机票，因为它也使它们陷入困境，并且已经升级到他们的内部服务团队 .
:)
1 回答
因此，经过数周的亚马逊支持，我们得到了一个解决方案，但可能不是最早的解决方案提到的最具成本效益的解决方案 .
工作流程 -
1.创建API GW，其中每个阶段都有自己的自定义域 .
例如 . blue-stage> blue-api.example.com和green-stage> green-api.example.com
2.然后在与创建API GW相同的AWS区域中创建Cname . 例如 . cname-api.example.com
3.使用与Cname（cname-api.example.com）相同的DNS条目（重复）创建Web Edge Cloudfront实例，并将此Cloudfront实例指向任意S3存储桶 .
现在提出请求
HTTP / 1.1 200好的
是的，这对我们需要的东西来说是过度的，也不是最具成本效益的，也不是我们做的KISS（Keep It Simple Stupid） . 所以是的 - 听到别人如何 Build 类似的基础设施会很棒！