这对我来说根本没有意义。当您创建新的 API 网关时，您可以指定它应该是区域优化的还是边缘优化的。但话又说回来，当您为 API Gateway 创建自定义域名时，您可以在两者之间进行选择。
最糟糕的是，你可以混合搭配它们！！！您可以为边缘优化的 API 网关设置区域自定义域名，这对我来说绝对没有意义！
为什么这两个可以分别进行区域/边缘优化？我什么时候希望它们中的每一个都进行区域/边缘优化？
【问题讨论】：
标签： amazon-web-services aws-api-gateway
为什么这两个可以分别进行区域/边缘优化？
区域和边缘优化是部署选项。一旦请求到达 API Gateway 服务的核心或 API Gateway 背后的服务最终如何被访问，这两个选项都不会改变 AWS 基础设施如何处理 API 的任何基本内容 - 如何请求最初到达 AWS 并传送到 API Gateway 核心执行。更多关于这方面的内容，请见下文。
当您使用自定义域名时，您选择的 API 阶段会在第二个端点上再次部署，这就是您必须再次选择部署类型的原因。
每个端点都有其部署类型的特征，无论是区域性的还是边缘优化的。如果使用自定义域名进行部署并随后使用该自定义域名进行访问，则 API 本身的原始部署类型不会影响 API 的行为——它们是独立的。
通常，如果您使用自定义域名部署 API，则不会继续使用为主 API 创建的部署端点（例如 xxxx.execute-api.{region}.amazonaws.com），因此初始选择无关紧要。
我什么时候希望它们中的每一个都进行区域/边缘优化？
如果您使用的是自定义域名，那么如上所述，您对整个 API 的原始部署选择在您使用自定义域名时不会产生进一步的影响。
边缘优化端点最初是唯一可用的选项。如果您没有任何选择的依据，那么这个选择通常是合理的。
此选项通过 AWS“边缘网络”路由传入请求，该网络是 CloudFront 网络，拥有 100 多个全球边缘站点。这不会改变 API Gateway 核心最终处理您的请求的位置——它们最终仍然在同一个区域内处理——但是请求从世界各地路由到最近的 AWS 边缘，并从那里通过运营的网络传输由 AWS 到达您部署 API 的区域。
如果您的 API Gateway 阶段的客户端分布在全球各地，并且您只在单个区域中部署 API，那么您可能需要边缘优化部署。
边缘优化的配置往往会给您更好的全局响应能力，因为它往往会减少网络往返的影响，并且传输质量不会像请求那样受到公共互联网的变幻莫测的影响在跳出 Internet 并进入 AWS 网络之前，覆盖尽可能少的距离。 TCP 握手和 TLS 与连接的浏览器/客户端在短距离内协商（从客户端到边缘），并且边缘网络保持可重用的保持活动连接，所有这些通常都对您有利...但是，当您的客户端总是（或通常）从同一区域内的 AWS 基础设施内调用 API 时，这种优化会成为一种相对损害，因为请求需要跳到边缘网络，然后再回到核心区域网络。
如果您的 API Gateway 阶段的客户端位于 AWS 内部并且在您部署 API 的同一区域内（例如当该 API 被该区域内 EC2 中的其他系统调用时），那么您很可能需要一个区域端点。区域终端节点通过较少的 AWS 基础设施路由请求，确保当请求来自同一区域内的 EC2 时，延迟最小化并减少抖动。
作为通过边缘网络进行路由的副作用，边缘优化端点还提供了一些您可能会觉得有用的额外请求标头，例如 CloudFront-Viewer-Country: XX 尝试识别地理位置的两位数国家代码发出 API 请求的客户端。区域端点没有这些标头。
作为一般规则，除非您找到不这样做的理由，否则请使用边缘优化。
有什么理由不这样做？如上所述，如果您或其他人从同一 AWS 区域内调用 API，您可能需要一个区域终端节点。边缘优化端点可以在更高级或更复杂的配置中引入一些边缘情况的副作用，因为它们集成到基础设施的其余部分的方式。对于边缘优化部署，有些事情是您无法做到的，或者如果您这样做则不是最佳的：
如果您将 CloudFront 用于与 API Gateway 无关的其他站点，并且 CloudFront 配置为通配符备用域名，例如 *.example.com，那么您不能使用来自该通配符域的子域，例如 @987654325 @，在具有自定义域名的边缘优化端点上，因为 API Gateway 代表您向边缘网络提交请求，以在该子域通过 CloudFront 到达时声明该子域的所有请求，而 CloudFront 拒绝此请求，因为它表示不受支持与 API Gateway 一起使用时的配置，即使 CloudFront 在某些其他情况下支持它。
如果您想在多个区域中提供响应同一个自定义域名的冗余 API，并使用 Route 53 基于延迟的路由将请求传递到离请求者最近的区域，则无法使用边缘执行此操作-优化的自定义域，因为第二个 API 网关区域将无法在边缘网络上声明该子域的流量，因为边缘网络对于任何给定的域名（子域）都需要 1 个目标。此配置可以使用区域终端节点和 Route 53 LBR 实现，也可以在利用边缘网络的同时实现，方法是使用您自己的 CloudFront 分配、Lambda@Edge 根据调用者的位置选择目标终端节点以及 API Gateway 区域部署。请注意，如果您需要支持调用方的 IAM 身份验证，这无法通过任何方式实现，因为调用方需要在签名和提交请求之前知道目标区域。
如果您想将您的 API 用作集成多个资源、部署在 CloudFront 后面并使用路径路由到不同服务的大型站点的一部分，例如，/images/* 可能会路由到 S3 存储桶， /api/* 可能会路由到您的 API Gateway 阶段，*（其他所有内容）可能会路由到 EC2 中的弹性负载均衡器——那么您不想使用边缘优化的 API，因为这会导致您的请求通过边缘网络循环两次（增加延迟）并导致一些标头值丢失。此配置不会中断，但不是最佳配置。为此，需要一个区域端点。
【讨论】：