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