使用基于地理位置的策略v / s Cloudfront进行多区域部署

Question

我有一个自定义来源，即EC2实例上的Web应用程序。我该如何决定是否应该参加：

1. Cloudfront CDN

或

1. 在不同区域中部署多个实例并配置基于地理位置/邻近性的路由策略

混乱的原因在于，两者都旨在将请求路由到最近的位置（在 Cloudfront 情况下，是边缘位置）以及针对特定区域的EC2实例。 多区域部署，其中基于地理位置的策略采用Route 53 ），基于请求的来源。

Answer 1

主要出于很多原因，您可以使用多区域，

1. 邻近
2. 故障转移（如果第一个区域发生故障，则可以将请求发送到另一个区域）

此处清楚记录了多区域lambda部署。您也可以将相同的逻辑应用于所有AWS资源。 （DynamoDB，S3）

https://aws.amazon.com/blogs/compute/building-a-multi-region-serverless-application-with-amazon-api-gateway-and-aws-lambda/

您还可以运行Lambda @ Edge将所有请求/拆分强制到边缘上的一个区域。

希望有帮助。

Answer 2

没有理由不能同时做到这两者。

CloudFront会自动将请求路由到查看者附近的边缘位置，并且当无法从该位置或最近的区域缓存提供请求时，CloudFront会对原始域名进行DNS查找并从原始位置获取内容

到目前为止，我只说了明显的话。但是接下来是一个微妙但重要的细节：

CloudFront从靠近查看器的位置进行原始服务器DNS查找 -这意味着，如果原始域名是Route 53中基于延迟的记录集，则指向其中的部署两个或更多EC2区域，然后CloudFront发出的“查找”请求将被路由到距离边缘最近的起源部署，根据定义，该部署也将最靠近查看器。

因此，使用基于延迟的配置作为后端的DNS配置，单个全局CloudFront部署可以自动透明地选择最佳来源。

如果CloudFront提供的缓存和传输优化不能满足您所需的全局性能，然后您可以将其部署在CloudFront后面的多个区域中……请始终注意区域部署几乎总是一个更复杂的环境，具体取决于支持应用程序的数据库以及它们如何处理读取和/或写入的跨区域复制。

在多个区域部署中，将CloudFront用作前端也是一种更好的容错解决方案，因为CloudFront会正确遵守源服务器DNS记录上的DNS TTL，并且如果将Route 53运行状况检查配置为不健康在原始域名的DNS响应之外的区域中，CloudFront将迅速停止向其发送进一步的请求。众所周知，浏览器在这方面是不可信任的，有时会缓存DNS答案，直到关闭所有选项卡/窗口。

如果CloudFront是您的前端，则可以根据需要将逻辑的一部分卸载到Lambda @ Edge。