S3托管网站Cloudfront发行版和指向同一子域的API Gateway自定义域 [英] S3 hosted website Cloudfront distribution and API Gateway custom domain pointing to the same subdomain

查看:136
本文介绍了S3托管网站Cloudfront发行版和指向同一子域的API Gateway自定义域的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的网站有一个子域api.example.com,我希望实现以下目标:

I have a subdomain for my website named api.example.com and I want to have the following achieved:


  • 对于映射到api.example.com

  • have 1 CloudFront distribution for an S3 static website mapped to api.example.com

已将API网关自定义域名映射到相同的子域api.example。 com

have the API Gateway custom domain name mapped to the same subdomain api.example.com

我完成此设置的步骤是:

The steps I did to achieve this setup are:


  1. 创建一个API网关自定义域api.example.com,并为我要公开为v1(目前为版本1)的API设置基本映射

  1. Create an API Gateway custom domain api.example.com and set the base mappings for the APIs I want to expose as v1 (version 1 for now)

在Route 53中,我创建了一个CNAME记录api.example.com,指向第1步中API网关的Edge优化目标域名

In Route 53 I created a CNAME record api.example.com pointing to the Edge optimized Target domain name of the API Gateway from Step 1

注意:在这一点上,正如我所料,我收到了 https://api.example.com/v1


  1. 我创建了一个S3存储桶并将其设置为f或静态网站托管。所有文件都已成功上传并且可以正常工作。

  1. I created an S3 bucket and set it up for Static website hosting. All files uploaded successfully and working.

我创建了一个新的Cloudfront发行版,其起源在S3存储桶中。此时,对于此Cloudfront发行版,我无法将CNAME记录设置为api.example.com,因为API网关中设置的第一个自定义域名已经使用了该记录,并且AWS提供了CNAMEAlreadyExistsException-因此我将此字段留空。可以按预期访问S3存储桶的CloudFront分配。

I created a new Cloudfront distribution with the origin in the S3 bucket. At this point, for this Cloudfront distribution, I can not set the CNAME record as api.example.com because it is already used by the first Custom Domain Name set in the API Gateway and AWS gives an CNAMEAlreadyExistsException - so I leave this field empty. Accessing the CloudFront distribution for the S3 bucket works as expected.

在为S3存储桶生成的CloudFront分配下,我添加了另一个来源(API网关自定义域名)并创建Bevahior规则以将v1 / *调用路由到API网关自定义域名。

Under the CloudFront distribution generated for the S3 bucket I add another origin (the API Gateway custom domain name) and create the Bevahior rule to route the v1/* calls to API Gateway custom domain name.

,事情再也不会解决:
-访问 https://api.example.com 我从API网关发行版中获得了{ message: Fobidden}。但是,URL https://api.example.com/v1 仍会返回预期结果。

At this point, things are not falling into place anymore: - when accessing https://api.example.com I get the {"message": "Fobidden" } from the API Gateway distribution. However the URL https://api.example.com/v1 still returns the expected result.

问题:是否有任何我想设置的内容,因此可以用于URL https://api.example.com 返回S3静态网站的内容?

Question: Is there anything which I missed to set so it will work for the URL https://api.example.com to return the content of the S3 static website?

注意:同样,我在S3存储桶的Cloudfront分布上有一个空的CNAME字段,而在Route53中使用相同的Cloudfront分布定义了一个CNAME的事实,这也提示了我一条警告消息,指出这种情况可能会暴露

Note: also, the fact that I have an empty CNAME field on the S3 bucket cloudfront distribution while I have a CNAME defined in Route53 using the same cloudfront distribution prompts me an warning message saying that this situation may expose me to a vulnerability.

推荐答案

对于上述用例,您只需要一个Cloudfront发行版(已映射到api.example.com),它应该能够使用不同的行为约束将流量转发到S3和API网关(均作为源添加到同一分发中)塑像。您可以通过以下方式配置行为:将/ v1 / *流量路由到API网关,将其他流量路由到S3。

For your usecase mentioned, you only need one Cloudfront distribution (which is mapped to api.example.com) where it should be able to forward the traffic to S3 and API Gateway (both added as origins to the same distribution) using different behavior configurations. You can configure the behaviors in a way that /v1/* traffic is routed to the API Gateway and other traffic to S3.

设置起源和行为时,您需要遵循的配置很少。

When setting up the origins and behaviors, there are few configurations you need to follow.


  • 确保S3和API网关行为都将HTTP重定向到HTTPS。

  • 添加API网关源集时仅转发HTTPS流量。

  • 在API网关行为中,将接受-*,授权,原始,引荐来源的标头列入白名单,并确保您不将主机标头列入白名单。

  • 在两个来源中均不要添加

  • 对于API网关行为,将TTL配置为0并允许所有方法(GET,POST等)

  • Make sure both S3 and API Gateway behaviors redirects HTTP to HTTPS.
  • When adding API Gateway origin set only to forward HTTPS traffic.
  • In API Gateway behavior, whitelist the headers for accept-* ones , authorization, origin, referrer and makesure you do not whitelist 'Host' header.
  • In both origins, don't add any paths.
  • For the API Gateway behavior configure the TTLs to 0 and allow all the methods (GET, POST & etc.)

这篇关于S3托管网站Cloudfront发行版和指向同一子域的API Gateway自定义域的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆