亚马逊发布了new feature - to support regional api endpoints
这是否意味着我可以在两个向Lambda微服务发送请求的区域中部署相同的API代码？ （它将是两个不同的Https端点）
让CloudFront为我分配流量吗？
任何代码段？
答案 0 :(得分：37)
这是否意味着我可以在两个向Lambda微服务发送请求的区域中部署相同的API代码？ （它将是两个不同的Https端点）
这已经成为可能了。您已经可以在多个区域中部署相同的API代码，并使用API网关创建不同的HTTPS端点。
以前，您不能在不同区域配置API网关API端点以期望相同的主机名 - 如果您想拥有地理路由，这是以前不可用的关键功能或使用API网关的故障转移方案。
使用之前的设置 - 现已重命名＆＃34; Edge-Optimized Endpoints＆＃34; - 每个API网关API都有一个区域端点主机名，但在CloudFront后面自动配置。从任何地方访问您的API意味着您通过CloudFront访问它，这意味着优化的连接和从API客户端（全球任何地方）的传输通过AWS Edge网络返回到您的API家庭区域，这是为CloudFront，Route 53和S3 Transfer Acceleration提供支持的网络。
总的来说，这很好，但在某些情况下，它会更好。
新的配置产品，称为区域API端点，不使用CloudFront或Edge Network ...但您的API仍然只在一个区域（但继续阅读）。
区域API端点在以下情况下是有利的：
如果您的流量来自区域内的EC2，则可以避免跳转到Edge网络并再次退回，这将优化来自同一EC2区域内的API请求的性能。
如果您希望在您控制的CloudFront分配后面部署API网关端点（例如，为了避免跨源并发症，或以其他方式将API网关集成到更大的站点中），以前需要您指向CloudFront分配由API网关管理的CloudFront分发，因此两次循环通过CloudFront，这意味着传输延迟和一些灵活性的损失。
创建区域API端点后，您可以直接在API端点指向您自己的CloudFront分配。
如果您在单个区域中拥有单个API，而且它是从全球各地进行访问的，而您自己并未使用CloudFront，那么Edge-Optimized端点几乎肯定是最好的方式去。
但是，对于自定义域名，区域API端点会变得有趣。由于API网关对CloudFront的依赖性，以前无法在多个AWS区域中创建具有相同自定义域名（例如api.example.com）的API。 CloudFront是一种全局服务，因此主机名称命名空间也是全局的 - 全球只有一个CloudFront分配可以响应特定的传入请求主机名。由于区域API端点不依赖于CloudFront，因此可以在多个AWS区域中配置具有相同自定义域名的API。
因此，假设您想要从us-east-2和us-west-2中提供api.example.com，您可以部署各自的API，然后在每个区域中创建自定义域名使用区域API端点为api.example.com的每个区域配置，为每个部署选择一个ACM证书。 （这需要与API在同一区域内的ACM证书，而不是始终在us-east-1中。）
这为您提供了两个不同的主机名，每个区域一个，用于DNS路由。它们看起来像这样：
d-aaaaaaaaaa.execute-api.us-east-2.amazonaws.com
d-bbbbbbbbbb.execute-api.us-west-2.amazonaws.com
那么，下一步是什么？
您使用Route 53 Latency-Based路由为api.example.com创建一个CNAME记录，其中包含两个目标 - 一个来自us-east-2，一个来自us-west-2 - 指向两个相应的名称，以及对目标的健康检查。 Route 53将自动解析DNS查询到任何更靠近请求者的区域端点。例如，如果您尝试从us-east-1到达API，则您的DNS查询将转到Route 53，并且那里没有针对us-east-1的记录，因此Route 53确定us-east- 2是两个区域中较近的区域，并且 - 假设us-east-2端点已通过其健康检查 - Route 53返回指向d-aaaaaaaaaa.execute-api.us-east-2.amazonaws.com的DNS记录。
因此，此功能创建了在多个AWS区域中部署API的能力，这些API将响应相同的主机名，这是边缘优化API端点无法实现的（因为所有端点都是在宣布此新功能之前）
让CloudFront为我分配流量吗？
不完全是。或者，至少，不是直接的。 CloudFront不会根据请求者的区域进行原点确定，但可以使用Lambda @Edge dynamic origin selection根据请求者的一般位置修改原始服务器（通过评估哪个API区域最接近正在为特定请求提供服务的CloudFront边缘。
但是，正如您所看到的，路由53基于延迟的路由可以为您做到这一点。然而，仍然有一个令人信服的理由将这种配置置于CloudFront发行版之后，无论如何......实际上有两个原因......
这本质上是一个DNS故障转移配置，当浏览器或没有听说过Java似乎无限期地缓存DNS查找的Java程序员进行访问时，这是非常不可靠的。浏览器也很糟糕。借助CloudFront在DNS故障转移配置之前，您不必担心客户端缓存DNS查找，因为CloudFront会正确执行此操作。 Route 53记录的TTL（用作CloudFront背后的原始服务器）按预期运行，因此区域故障转移正确发生。
将此配置置于CloudFront后面的第二个原因是，您希望在边缘网络上传输流量。如果请求仅来自托管API的两个AWS区域，则可能没有帮助，但是否则应该提高整体响应能力。
请注意，跨区域的地理冗余不是可以在每种情况下使用API网关完全透明地完成的 - 它取决于您使用它的方式。我想到的一个有问题的案例涉及一个设置，您需要针对传入请求进行IAM身份验证。 X-Amz-Credential包括目标区域，签名当然会有所不同，因为签名V4中的签名密钥基于秘密/日期/地区/服务/签名密钥范例（这是一个很棒的设计，但我离题）。这会使设置复杂化，因为调用者不知道目标区域。可能还有其他并发症。 Cognito可能有类似的并发症。但对于一个简单的API，身份验证由您自己的应用程序令牌，cookie等机制完成，这个新功能非常重要。
有点可笑，在宣布这项新功能之前，我实际上正在设计托管服务，该服务将处理跨区域的API网关冗余部署的请求的故障转移和地理路由，包括具有该功能的机制以补偿签名中所需的不同区域。我目前正在研究的未来前景有点不太清楚。
答案 1 :(得分：0)
这意味着您可以根据减少延迟的区域部署API。
一个用例是，假设你有一个调用API请求的Lambda函数。如果Lambda和API都位于同一区域，那么您可以期待高性能
请查看https://docs.aws.amazon.com/apigateway/latest/developerguide/create-regional-api.html