基于路径的Cloudfront和EC2路由

Question

因此，目前我们有两个ec2实例（分别说A和B）和一个云端。

如果用户访问www.appdomain.com/app，则应将其路由到cloudfront SPA页面。但是，如果用户访问www.appdomain.com，则应将其路由到EC2实例A，如果用户访问www.appdomain.com/api，则应将其路由到EC2实例B。

所有这些应用程序必须位于同一域中。

现在，我们了解了如何使用应用程序负载平衡器设置路径规则，但也想知道如何将其设置为cloudfront。

更新： 因此总而言之，问题是我们如何将/ app路由到cloudfront /和/ api路由到ec2。

Answer 1

  

所有这些应用程序必须位于同一域中。

在这种情况下，对该域的每个请求都必须先通过CloudFront 。

您的DNS记录将需要指向CloudFront（而不是ALB），然后CloudFront负责将请求路由到适当的目标-通过ALB到EC2实例，到S3存储桶以及您需要的任何位置。请求执行-这些操作都称为内容origin。

一旦起源由其各自的域名（不是您网站的域名，而是专门用于所涉及资源的域名）指定，您就可以定义CloudFront path patterns来选择接收请求的起源每个模式（例如/api*）。

一旦您的DNS更改为指向CloudFront，所有请求都将首先发送到CloudFront，然后移交给下一个服务，除非CloudFront拥有所请求对象的缓存副本-在这种情况下，CloudFront将从其服务缓存，并且什么都不会发送到源。

您不能从ALB路由到CloudFront，但是可以从CloudFront路由到ALB。

如果不使用能够匹配路径并代表请求者获取内容的反向代理，则无法将域细分为多个不同的基于路径的内容来源，HTTP和DNS不支持功能。除了提供CDN服务之外，CloudFront还是反向代理。

当然，

ALB也是反向代理，但不支持与CloudFront一样多的不同类型内容来源-ALB仅支持EC2实例，即数据中心中的服务器（在在这种情况下，ALB必须具有VPN路径才能访问它们），Lambda充当内容来源。只要使用HTTP / HTTPS并且可以通过Internet进行访问，CloudFront便可以将任何内容用作内容来源。 （要选择一个随机的示例，CloudFront甚至可以使用来自其他供应商的服务（例如Google Cloud Storage存储桶）作为内容来源，如果出于某种原因您需要这样做，因为这些都是可以通过HTTP通过公共互联网访问。）