回复第一条评论

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

卷曲：（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确定

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

回复第一条评论

感谢Michael-是的，我们正在运行边缘优化的自定义域名，因此我们已将eu-west-1的SSL Cert导出到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，其中每个阶段都有自己的自定义域。

E.G。 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存储桶。

现在发出请求

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确定

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

AWS API Gateway定制域的Cname

回复第一条评论

1 个答案: