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