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

问题描述

这对我完全没有意义.创建新的API网关时，可以指定是区域优化还是边缘优化.但是同样，当您为API网关创建自定义域名时，可​​以在两者之间进行选择.

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网关服务的核心，或者最终如何访问API网关背后的服务，这两个选项都不会改变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变幻莫测的影响，因为请求在跳出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 infrastrucutre, 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网关无关的其他站点，并且CloudFront已配置为通配符备用域名(如*.example.com)，则您不能使用该通配符域中的子域，例如作为api.example.com，在具有自定义域名的经过边缘优化的终结点上，因为API网关代表您向边缘网络提交请求，以在该子域通过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基于延迟的路由将请求传递到距离请求者最近的区域，则不能执行此操作使用边缘优化的自定义域，因为第二个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 achieve 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屋！