amazon-web-services - 区域/边缘优化 API 网关 VS 区域/边缘优化自定义域名

Question

这对我来说根本没有意义。创建新的 API 网关时，您可以指定它是区域优化的还是边缘优化的。但话又说回来，当您为 API Gateway 创建自定义域名时，您可以在两者之间进行选择。

最糟糕的是，您可以混合搭配它们!!!您可以为边缘优化的 API 网关设置区域自定义域名，这对我来说绝对没有意义!

为什么这两个可以分别进行区域/边缘优化？我什么时候希望它们中的每一个都进行区域/边缘优化？

Answer 1

Why these two can be regional/edge-optimized separately?

区域和边缘优化是部署选项。一旦请求到达 API Gateway 服务的核心，或者 API Gateway 背后的服务最终如何被访问，这两个选项都不会改变 AWS 基础设施如何处理 API 的任何根本性——改变的是请求最初到达 AWS 的方式和交付给 API Gateway 核心执行。更多关于这一点，如下。
当您使用自定义域名时，您选择的 API 阶段会在第二个端点上再次部署，这就是您必须再次选择部署类型的原因。
每个端点都有其部署类型的特征，无论是区域性的还是边缘优化的。如果使用自定义域名进行部署，并且随后使用该自定义域名进行访问，则 API 本身的原始部署类型不会影响 API 的行为——它们是独立的。
通常，如果您使用自定义域名部署 API，您将不会继续使用为主 API 创建的部署端点(例如 xxxx.execute-api.{region}.amazonaws.com )，因此初始选择应该无关紧要。

And when do I want each of them to be regional/edge-optimized?

如果您使用的是自定义域名，那么，如上所述，当您使用自定义域时，您对 API 的原始部署选择作为一个整体不会产生进一步的影响。
边缘优化端点最初是唯一可用的选项。如果您的选择没有任何依据，则此选择通常是合理的。
此选项通过 AWS“边缘网络”路由传入请求，该网络是 CloudFront 网络，拥有 100 多个全局边缘站点。这不会改变 API Gateway 核心最终处理您的请求的位置——它们最终仍然在同一区域内处理——但请求从世界各地路由到最近的 AWS 边缘，并从那里通过运营的网络传输通过 AWS 到达您部署 API 的区域。
如果您的 API Gateway 阶段的客户端遍布全局，并且您仅在单个区域中部署 API，您可能需要边缘优化部署。
边缘优化的配置往往会为您提供更好的全局响应能力，因为它往往会减少网络往返的影响，并且传输质量不受公共(public) Internet 变幻莫测的影响，因为请求覆盖的范围最少在离开 Internet 进入 AWS 网络之前可能的距离。 TCP 握手和 TLS 在短距离内(从客户端到边缘)与连接的浏览器/客户端协商，并且边缘网络保持可以重复使用的保持事件连接，所有这些通常对您有利......但是，当您的客户总是(或通常)从 AWS 基础设施内的同一区域内调用 API 时，这种优化就会变得相对不利，因为请求需要跳转到边缘网络，然后再返回到核心区域网络。
如果您的 API Gateway 阶段的客户端位于 AWS 内部并且位于您部署 API 的同一区域内(例如，当该区域内的 EC2 中的其他系统调用 API 时)，那么您很可能需要一个区域终端节点。区域终端节点通过较少的 AWS 基础设施路由请求，确保当请求来自同一区域内的 EC2 时，延迟最小并减少抖动。
作为通过边缘网络进行路由的副作用，边缘优化端点还提供了一些您可能会觉得有用的额外请求 header ，例如 CloudFront-Viewer-Country: XX，它尝试识别客户端地理位置的两位数国家/地区代码，使API 请求。区域端点没有这些 header 。
作为一般规则，除非您有理由不这样做，否则请使用边缘优化。
不这样做的原因是什么？如上所述，如果您或其他人从同一 AWS 区域内调用 API，您可能需要一个区域终端节点。边缘优化的端点可能会在更高级或更复杂的配置中引入一些边缘情况的副作用，因为它们集成到基础设施的其余部分的方式。有些事情你不能用边缘优化的部署来做，或者如果你这样做就不是最佳的:

如果您将 CloudFront 用于与 API 网关无关的其他站点，并且 CloudFront 配置为通配符备用域名，例如 *.example.com ，则您不能在边缘使用该通配符域中的子域，例如 api.example.com 。具有自定义域名的优化端点，因为 API Gateway 代表您向边缘网络提交请求，以在该子域通过 CloudFront 到达时声明所有请求，而 CloudFront 拒绝此请求，因为它在与 API Gateway 一起使用时表示不受支持的配置，即使 CloudFront 在其他一些情况下支持它。

如果您想在多个区域提供响应相同自定义域名的冗余 API，并使用 Route 53 Latency-Based Routing 将请求传递到离请求者最近的区域，则无法使用边缘优化自定义域，因为第二个 API 网关区域将无法在边缘网络上声明该子域的流量，因为边缘网络对于任何给定的域名(子域)都需要恰好 1 个目标。此配置可以使用区域终端节点和 Route 53 LBR 来实现，也可以通过使用您自己的 CloudFront 分配、Lambda@Edge 以根据调用者的位置选择目标终端节点以及 API 网关区域部署来利用边缘网络来实现。请注意，如果您需要支持调用方的 IAM 身份验证，这是无法通过任何方式实现的，因为调用方在签署和提交请求之前需要知道目标区域。

如果您想将 API 用作集成多个资源的更大站点的一部分，部署在 CloudFront 后面，并使用路径路由到不同的服务——例如，/images/* 可能路由到 S3 存储桶，/api/* 可能路由到您的 API 网关阶段和 *(其他所有内容)可能会路由到 EC2 中的弹性负载均衡器——那么您不想使用边缘优化的 API，因为这会导致您的请求在边缘网络中循环两次(增加延迟)并导致某些 header 值丢失。此配置不会中断，但不是最佳配置。为此，需要一个区域终点。