区域/边缘优化 API 网关 VS 区域/边缘优化自定义域名 [英] Regional/Edge-optimized API Gateway VS Regional/Edge-optimized custom domain name

问题描述

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

This does not make sense to me at all. When you create a new API Gateway you can specify whether it should be regional or edge-optimized. But then again, when you are creating a custom domain name for API Gateway, you can choose between the two.

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

Worst of all, you can mix and match them!!! You can have a regional custom domain name for an edge-optimized API gateway and it's absolutely meaningless to me!

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

Why these two can be regional/edge-optimized separately? And when do I want each of them to be regional/edge-optimized?

推荐答案

为什么这两个可以分别进行区域/边缘优化?

区域和边缘优化是部署选项.一旦请求到达 API Gateway 服务的核心，或者 API Gateway 背后的服务最终如何被访问，这两个选项都不会改变 AWS 基础设施如何处理 API 的任何根本性——变化是如何请求最初到达 AWS 并传送到 API Gateway 核心以供执行.更多相关信息，见下文.

Regional and Edge-Optimized are deployment options. Neither option changes anything fundamental about how the API is processed by the AWS infrastructure once the request arrives at the core of the API Gateway service or how the services behind API Gateway ultimately are accessed -- what changes is how the requests initially arrive at AWS and are delivered to the API Gateway core for execution. More about this, below.

当您使用自定义域名时，您选择的 API 阶段会在第二个端点上再次部署，这就是您必须再次选择部署类型的原因.

When you use a custom domain name, your selected API stage is deployed a second time, on a second endpoint, which is why you have a second selection of a deployment type that must be made.

每个端点都有其部署类型的特征，无论是区域性的还是边缘优化的.如果使用自定义域名进行部署，然后使用该自定义域名进行访问，则 API 本身的原始部署类型不会影响 API 的行为——它们是独立的.

Each endpoint has the characteristics of its deployment type, whether regional or edge-optimized. The original deployment type of the API itself does not impact the behavior of the API if deployed with a custom domain name, and subsequently accessed using that custom domain name -- they're independent.

通常，如果您使用自定义域名部署 API，您将不会继续使用为主 API 创建的部署端点(例如 xxxx.execute-api.{region}.amazonaws.com)，所以初始选择应该无关紧要.

Typically, if you deploy your API with a custom domain name, you wouldn't continue to use the deployment endpoint created for the main API (e.g. xxxx.execute-api.{region}.amazonaws.com), so the initial selection should not matter.

我什么时候希望它们中的每一个都进行区域/边缘优化?

如果您使用的是自定义域名，那么，如上所述，当您使用自定义域名时，您对 API 整体的原始部署选择不会产生进一步的影响.

If you're using a custom domain name, then, as noted above, your original deployment selection for the API as a whole has no further impact when you use the custom domain.

边缘优化端点最初是唯一可用的选项.如果您的选择没有任何依据，那么这个选择通常是合理的.

Edge-optimized endpoints were originally the only option available. If you don't have anything on which to base your selection, this choice is usually a reasonable one.

此选项通过 AWS边缘网络"路由传入请求这是 CloudFront 网络，拥有 100 多个全球边缘站点.这不会改变 API Gateway 核心最终处理您的请求的位置——它们最终仍然在同一区域内处理——但请求从世界各地路由到最近的 AWS 边缘，并从那里通过运营的网络传输由 AWS 到达您部署 API 的区域.

This option routes incoming requests through the AWS "Edge Network," which is the CloudFront network, with its 100+ global edge locations. This does not change where the API Gateway core ultimately handles your requests -- they are still ultimately handled within the same region -- but the requests are routed from all over the world into the nearest AWS edge, and they travel from there on networks operated by AWS to arrive at the region where you deployed your API.

如果您的 API Gateway 阶段的客户端遍布全球，并且您仅在单个区域部署 API，您可能需要边缘优化部署.

If the clients of your API Gateway stage are globally dispersed, and you are only deploying your API in a single region, you probably want an edge-optimized deployment.

边缘优化的配置往往会为您提供更好的全局响应能力，因为它往往会减少网络往返的影响，并且传输质量不会因为请求而受到公共互联网那么多变幻莫测的影响在跳出 Internet 并进入 AWS 网络之前，覆盖尽可能少的距离.TCP 握手和 TLS 在短距离内(从客户端到边缘)与连接的浏览器/客户端协商，并且边缘网络保持可以重复使用的保持活动连接，所有这些通常对您有利......但是，当您的客户总是(或通常)从 AWS 基础设施内的同一区域内调用 API 时，这种优化就会变得相对不利，因为请求需要跳转到边缘网络，然后再返回到核心区域网络.

The edge-optimized configuration tends to give you better global responsiveness, since it tends to reduce the impact of network round trips, and the quality of the transport is not subject to as many of the vagaries of the public Internet because the request covers the least amount of distance possible before jumping off the Internet and onto the AWS network. The TCP handshake and TLS are negotiated with the connecting browser/client across a short distance (from the client to the edge) and the edge network maintains keep-alive connections that can be reused, all of which usually works in your favor... but this optimization becomes a relative impairment when your clients are always (or usually) calling the API from within the AWS infrastructure, within the same region, since the requests need to hop over to the edge network and then back into the core regional network.

如果您的 API Gateway 阶段的客户端位于 AWS 内部并且位于您部署 API 的同一区域内(例如当该区域内的 EC2 中的其他系统调用 API 时)，那么您很可能需要一个区域终点.区域终端节点通过较少的 AWS 基础设施路由请求，确保在请求来自同一区域内的 EC2 时将延迟降至最低并减少抖动.

If the clients of your API Gateway stage are inside AWS and within the same region where you deployed the API (such as when the API is being called by other systems in EC2 within the region), then you will most likely want a regional endpoint. Regional endpoints route requests through less of the AWS infrastructure, ensuring minimal latency and reduced jitter when requests are coming from EC2 within the same region.

作为通过边缘网络路由的副作用，边缘优化端点还提供了一些您可能会觉得有用的额外请求标头，例如 CloudFront-Viewer-Country: XX，它试图标识发出 API 请求的客户端的地理位置的两位数国家/地区代码.区域端点没有这些标头.

As a side-effect of routing through the edge network, edge-optimized endpoints also provide some additional request headers that you may find useful, such as CloudFront-Viewer-Country: XX which attempts to identify the two-digit country code of the geographic location of the client making the API request. Regional endpoints don't have these headers.

作为一般规则，除非您有理由不这样做，否则请使用边缘优化.

As a general rule, go with edge-optimized unless you find a reason not to.

不这样做的原因是什么?如上所述，如果您或其他人从同一 AWS 区域内调用 API，您可能需要一个区域终端节点.边缘优化端点可以在更高级或更复杂的配置中引入一些边缘情况的副作用，因为它们集成到基础设施的其余部分的方式.有些事情您无法使用边缘优化部署来完成，或者如果您这样做则不是最佳选择:

What would be some reasons not to? As mentioned above, if you or others are calling the API from within the same AWS region, you probably want a regional endpoint. Edge-optimized endpoints can introduce some edge-case side-effects in more advanced or complicated configurations, because of the way they integrate into the rest of the infrastructure. There are some things you can't do with an edge-optimized deployment, or that are not optimal if you do:

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

• if you are using CloudFront for other sites, unrelated to API Gateway, and CloudFront is configured for a wildcard alternate domain name, like *.example.com, then you can't use a subdomain from that wildcard domain, such as api.example.com, on an edge-optimized endpoint with a custom domain name, because API Gateway submits a request to the edge network on your behalf to claim all requests for that subdomain when they arrive via CloudFront, and CloudFront rejects this request since it represents an unsupported configuration when used with API Gateway, even though CloudFront supports it in some other circumstances.

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

if you want to provide redundant APIs that respond to the same custom domain name in multiple regions, and use Route 53 Latency-Based Routing to deliver requests to the region nearest to the requester, you can't do this with an edge-optimized custom domain, because the second API Gateway region will not be able to claim the traffic for that subdomain on the edge network, since the edge network requires exactly 1 target for any given domain name (subdomain). This configuration can be achieved using regional endpoints and Route 53 LBR, or can be achieved while leveraging the edge network by using your own CloudFront distribution, Lambda@Edge to select the target endpoint based on the caller's location, and API Gateway regional deployments. Note that this can't be achieved by any means if you need to support IAM authentication of the caller, because the caller needs to know the target region before signing and submitting the request.

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

if you want to use your API as part of a larger site that integrates multiple resources, is deployed behind CloudFront, and uses the path to route to different services -- for example, /images/* might route to an S3 bucket, /api/* might route to your API Gateway stage, and * (everything else) might route to an elastic load balancer in EC2 -- then you don't want to use an edge-optimized API, because this causes your requests to loop through the edge network twice (increasing latency) and causes some header values to be lost. This configuration doesn't break, but it isn't optimal. For this, a regional endpoint is desirable.

这篇关于区域/边缘优化 API 网关 VS 区域/边缘优化自定义域名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！