使用CloudFront的区域API网关 [英] Regional API Gateway with CloudFront

问题描述

Amazon发布了新功能-支持区域性api端点

Amazon released new feature - to support regional api endpoints

这是否意味着我可以在两个区域中部署相同的API代码，从而将请求发送到Lambda micro-服务？ （这将是两个不同的Https端点）

Does it mean I can deploy my same API code in two regions which sends request to Lambda micro-services? (It will be two different Https endpoints)

并且CloudFront可以为我分配流量吗？

And have CloudFront distribute the traffic for me?

任何代码

推荐答案

这是否意味着我可以在两个发送请求的区域中部署相同的API代码Lambda微服务？ （这将是两个不同的Https端点）

Does it mean I can deploy my same API code in two regions which sends request to Lambda micro-services? (It will be two different Https endpoints)

这是可能的。您已经可以在多个区域中部署相同的API代码，并使用API​​ Gateway创建不同的HTTPS端点。

This was already possible. You can already deploy the same API code in multiple regions and create different HTTPS endpoints using API Gateway.

您之前无法做的是配置API Gateway API端点位于不同区域的主机期望使用相同的主机名-如果您想使用API​​网关进行地理路由或故障转移，这是以前不可用的一项关键功能。

What you couldn't do, before, was configure API Gateway API endpoints in different regions to expect the same hostname -- and this is a critical capability that was previously unavailable, if you wanted to have a geo-routing or failover scenario using API Gateway.

使用之前的设置（现已更名为 Edge-Optimized Endpoints），每个API Gateway API都有一个区域终结点主机名，但会自动在CloudFront后面进行设置。从任何地方访问您的API意味着您正在通过CloudFront进行访问，这意味着优化的连接和从API客户端（在全球任何地方）的传输都可以通过AWS Edge Network（该网络通过PowerEdge网络）返回到API的本地区域CloudFront，Route 53和S3传输加速。

With the previous setup -- which has now been renamed "Edge-Optimized Endpoints" -- every API Gateway API had a regional endpoint hostname but was automatically provisioned behind CloudFront. Accessing your API from anywhere meant you were accessing it through the CloudFront, which meant optimized connections and transport from the API client -- anywhere on the globe -- back to your API's home region via the AWS Edge Network, which is the network that powers CloudFront, Route 53, and S3 Transfer Acceleration.

总体而言，这很好，但在某些情况下可能会更好。

Overall, this was good, but in some cases, it can be better.

名为区域API端点的新配置产品不使用CloudFront或边缘网络...但是您的API仍仅位于一个区域中（但请继续阅读）。

The new configuration offering, called a Regional API Endpoint, does not use CloudFront or the Edge Network... but your API is still only in one region (but keep reading).

在以下情况下，区域API端点比较有利：

Regional API Endpoints are advantageous in cases like these:

如果您的流量来自该区域内的EC2，则可以避免跳入该区域边缘网络并再次退出，这将优化来自同一EC2区域内部的API请求的性能。

If your traffic is from EC2 within the region, this avoids the necessity of jumping onto the Edge Network and back off again, which will optimize performance of API requests from inside the same EC2 region.

如果您想在CloudFront发行版后面部署API网关端点那您进行控制（例如，避免跨域合并或将API Gateway集成到更大的站点中），这以前要求您将CloudFront分配指向由API Gateway管理的CloudFront分配，从而两次遍历CloudFront，这意味着传输延迟和灵活性的损失。

If you wanted to deploy an API Gateway endpoint behind a CloudFront distribution that you control (for example, to avoid cross-origin complications, or otherwise integrate API Gateway into a larger site), this previously required that you point your CloudFront distribution to the CloudFront distribution managed by API Gateway, thus looping through CloudFront twice, which meant transport latency and some loss of flexibility.

创建区域API端点后，您可以直接将自己的CloudFront分配指向API端点。

Creating a Regional API Endpoint allows you to then point your own CloudFront distribution directly at the API endpoint.

如果您在一个区域中只有一个API，并且可以从全球各地访问它，并且您自己没有使用CloudFront，那么Edge-Optimized端点几乎肯定是最好的选择。

If you have a single API in a single region, and it's being accessed from points all over the globe, and you aren't using CloudFront yourself, the Edge-Optimized endpoint is still almost certainly the best way to go.

但是涉及自定义域名的区域API端点变得很有趣。由于API网关对CloudFront的依赖，以前无法在多个AWS区域中创建具有相同自定义域名（例如 api.example.com ）的API。 CloudFront是一项全局服务，因此主机名名称空间也是全局的-全球只有一个CloudFront发行版可以响应特定的传入请求主机名。由于区域API端点不依赖CloudFront，因此可以在多个AWS区域中以相同的自定义域名配置API。

But Regional API Endpoints get interesting when it comes to custom domain names. Creating APIs with the same custom domain name (e.g. api.example.com) in multiple AWS regions was not previously possible, because of API Gateway's dependency on CloudFront. CloudFront is a global service, so the hostname namespace is also global -- only one CloudFront distribution, worldwide, can respond to a specific incoming request hostname. Since Regional API Endpoints don't depend on CloudFront, provisioning APIs with the same custom domain name in multiple AWS regions becomes possible.

因此，假设您要提供<$从us-east-2和us-west-2中选择c $ c> api.example.com ，您将部署自己的API，然后在每个区域中创建自定义域名配置在每个具有区域API端点的 api.example.com 的区域中，为每个部署选择一个ACM证书。 （这要求ACM证书与API位于同一区域，而不是始终位于us-east-1。）

So, assuming you wanted to serve api.example.com out of both us-east-2 and us-west-2, you'd deploy your individual APIs and then in each region, create a custom domain name configuration in each region for api.example.com with a Regional API Endpoint, selecting an ACM certificate for each deployment. (This requires ACM certs in the same region as the API, rather than always in us-east-1.)

这为您提供了两个不同的主机名，每个区域中一个，用于DNS路由。他们看起来像这样：

This gives you two different hostnames, one in each region, that you use for your DNS routing. They look like this:

d-aaaaaaaaaa.execute-api.us-east-2.amazonaws.com
d-bbbbbbbbbb.execute-api.us-west-2.amazonaws.com

那么下一步呢？

您使用Route 53基于延迟的路由为 api.example.com 创建了一个CNAME记录目标-一个来自us-east-2，一个来自us-west-2-指向两个各自的名称，以及对目标的健康检查。路由53将自动将DNS查询解析到更靠近请求者的区域终结点。例如，如果您尝试从us-east-1到达API，则DNS查询转到Route 53，并且那里没有us-east-1的记录，因此Route 53确定us-east-2距离最近（假设us-east-2端点已通过其运行状况检查）-路由53返回指向 d-aaaaaaaaaa.execute-api.us-east-2的DNS记录。 amazonaws.com 。

You use Route 53 Latency-Based routing to create a CNAME record for api.example.com with two targets -- one from us-east-2, one from us-west-2 -- pointing to the two respective names, along with health checks on the targets. Route 53 will automatically resolve DNS queries to whichever regional endpoint is closer to the requester. If, for example, you try to reach the API from us-east-1, your DNS query goes to Route 53 and there's no record there for us-east-1, so Route 53 determines that us-east-2 is the closer of the two regions, and -- assuming the us-east-2 endpoint has passed its healthcheck -- Route 53 returns the DNS record pointing to d-aaaaaaaaaa.execute-api.us-east-2.amazonaws.com.

因此，此功能使您能够在响应相同主机名的多个AWS区域中部署API，而Edge Optimized API Endpoints无法实现（因为所有

So, this feature creates the ability to deploy an API in multiple AWS regions that will respond to the same hostname, which is not possible with Edge Optimized API Endpoints (as all endpoints were, prior to the announcement of this new feature).

CloudFront是否为我分配了流量？

And have CloudFront distribute the traffic for me?

不完全是。或者，至少不是直接。 CloudFront不会根据请求者的地区来确定来源，但是Lambda @ Edge 动态来源选择可用于根据请求者的大致位置修改原始服务器（通过评估哪个API区域最接近正要为特定请求提供服务的CloudFront边缘）。

Not exactly. Or, at least, not directly. CloudFront doesn't make origin determinations based on the requester's region, but Lambda@Edge dynamic origin selection could be used to modify the origin server based on the requester's general location (by evaluating which API region is nearest to the CloudFront edge that happens to be serving a specific request).

您可以在上方看到Route 53基于延迟的路由可以为您完成此任务。但是，无论如何，仍然有令人信服的理由将这种配置置于CloudFront发行版之后……实际上有两个原因……

However, as you can see, above, Route 53 Latency-Based routing can do that for you. Yet, there's still a compelling reason to put this configuration behind a CloudFront distribution, anyway... two reasons, actually...

从本质上讲，这是DNS故障转移配置，而且众所周知，当浏览器或Java程序员（未曾听说Java似乎无限期地缓存DNS查找）进行访问时，这是不可靠的。浏览器对此也很不利。将CloudFront置于DNS故障转移配置的前面，您无需担心客户端缓存DNS查找，因为CloudFront可以正确执行。 Route 53记录的TTL（用作CloudFront之后的原始服务器）的行为符合预期，因此可以正确进行区域故障转移。

This is in essence a DNS failover configuration, and that is notoriously unreliable when the access is being made by a browser or by a Java programmer who hasn't heard that Java seems to cache DNS lookups indefinitely. Browsers are bad about that, too. With CloudFront in front of your DNS failover configuration, you don't have to worry about clients caching your DNS lookup, because CloudFront does it correctly. The TTL of your Route 53 records -- which used as an origin server behind CloudFront -- behaves as expected, so regional failover occurs correctly.

放置此记录的第二个原因如果您希望在边缘网络上传输流量，则可以在CloudFront后面进行配置。如果请求仅来自托管API的两个AWS区域，这可能无济于事，但否则它应该整体上提高响应速度。

The second reason to place this configuration behind CloudFront would be if you want the traffic to be transported on the Edge Network. If the requests are only coming from the two AWS regions where the APIs are hosted, this might not be helpful, but otherwise it should improve responsiveness overall.

请注意，跨区域的地理冗余并不是在每种情况下都可以使用API​​ Gateway完全透明地完成的-取决于您的使用方式。我想到的一个有问题的情况是涉及一种设置，其中您需要针对传入的请求进行IAM身份验证。 X-Amz-Credential 包括目标区域，并且签名当然会有所不同，因为签名V4中的签名密钥基于秘密/日期/区域/服务/签名密钥范例（这是一个出色的设计，但我离题了）。由于呼叫者将不知道目标区域，因此这会使设置复杂化。可能还有其他并发症。 Cognito可能有类似的并发症。但是对于直接使用自己的应用程序令牌，Cookie等机制进行身份验证的API来说，这项新功能非常重要。

Note that geo-redundancy across regions is not something that can be done entirely transparently with API Gateway in every scenario -- it depends on how you are using it. One problematic case that comes to mind would involve a setup where you require IAM authentication against the incoming requests. The X-Amz-Credential includes the target region, and the signature of course would differ because the signing keys in Signature V4 are based on the secret/date/region/service/signing-key paradigm (which is a brilliant design, but I digress). This would complicate the setup since the caller would not know the target region. There may be other complications. Cognito may have similar complications. But for a straightforward API where the authentication is done by your own mechanism of application tokens, cookies, etc., this new capability is very much a big deal.

有些有趣，在宣布这项新功能之前，我实际上是在设计一项托管服务，该服务将处理故障转移和对跨地区API Gateway的冗余部署的请求进行地理路由，包括一种能够补偿差异的机制。签名中所需的区域。目前我的工作前景还不太清楚。

Somewhat amusingly, before this new capability was announced, I was actually working on the design of a managed service that would handle failover and geo-routing of requests to redundant deployments of API Gateway across regions, including a mechanism that had the capability to compensate for the differing region required in the signature. The future prospects of what I was working on are a bit less clear at the moment.

这篇关于使用CloudFront的区域API网关的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！