亚马逊发布new feature - to support regional api endpoints
这是否意味着我可以在向 Lambda 微服务发送请求的两个区域部署相同的 API 代码？ （这将是两个不同的 Https 端点）
让 CloudFront 为我分配流量？
任何代码sn-ps？
【问题讨论】：
标签： amazon-web-services amazon-cloudfront aws-api-gateway regions
这是否意味着我可以在向 Lambda 微服务发送请求的两个区域部署相同的 API 代码？ （这将是两个不同的 Https 端点）
这已经成为可能。您已经可以在多个区域部署相同的 API 代码并使用 API Gateway 创建不同的 HTTPS 端点。
以前您无法做到的是在不同区域配置 API Gateway API 端点以期望相同的主机名 - 如果您想要进行地理路由或故障转移，这是以前不可用的关键功能使用 API Gateway 的场景。
使用之前的设置（现在已重命名为“边缘优化端点”），每个 API 网关 API 都有一个区域端点主机名，但在 CloudFront 之后自动配置。从任何地方访问您的 API 意味着您通过 CloudFront 访问它，这意味着从 API 客户端（全球任何地方）优化连接和传输，通过 AWS 边缘网络返回您的 API 的主区域，该网络支持CloudFront、Route 53 和 S3 传输加速。
总的来说，这很好，但在某些情况下，它可能会更好。
称为区域 API 端点的新配置产品不使用 CloudFront 或边缘网络...但您的 API 仍仅在一个区域中（但请继续阅读）。
区域 API 端点在以下情况下具有优势：
如果您的流量来自区域内的 EC2，这避免了跳转到边缘网络并再次退出的必要性，这将优化来自同一 EC2 区域内的 API 请求的性能。
如果您想在您控制的 CloudFront 分配后面部署 API Gateway 终端节点（例如，为了避免跨域复杂性，或以其他方式将 API Gateway 集成到更大的站点），以前需要您指向您的 CloudFront 分配到由 API Gateway 管理的 CloudFront 分配，因此循环通过 CloudFront 两次，这意味着传输延迟和一些灵活性损失。
创建区域 API 端点后，您可以将自己的 CloudFront 分配直接指向 API 端点。
如果您在单个区域中有一个 API，并且可以从全球各地的点访问它，并且您自己没有使用 CloudFront，那么边缘优化端点仍然几乎肯定是最好的选择。
但是，当涉及到自定义域名时，区域 API 端点会变得很有趣。由于 API Gateway 对 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 证书。 （这要求 ACM 证书与 API 位于同一区域，而不是始终位于 us-east-1。）
这为您提供了两个不同的主机名，每个区域一个，用于您的 DNS 路由。它们看起来像这样：
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——分别指向两个名称，以及对目标进行健康检查。 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 端点无法做到这一点（因为所有端点都是，在此新功能发布之前） .
让 CloudFront 为我分配流量？
不完全是。或者，至少，不是直接的。 CloudFront 不会根据请求者的区域进行源确定，但 Lambda@Edge dynamic origin selection 可用于根据请求者的一般位置修改源服务器（通过评估哪个 API 区域最接近恰好位于的 CloudFront 边缘）服务特定请求）。
但是，如您所见，Route 53 基于延迟的路由可以为您做到这一点。然而，仍然有一个令人信服的理由将此配置置于 CloudFront 分配之后，无论如何......实际上有两个原因......
这本质上是一种 DNS 故障转移配置，当访问是由浏览器或 Java 程序员进行的访问时（他们没有听说过 Java 似乎无限期地缓存 DNS 查找），这是出了名的不可靠。浏览器对此也很不利。在您的 DNS 故障转移配置之前使用 CloudFront，您不必担心客户端会缓存您的 DNS 查找，因为 CloudFront 可以正确执行此操作。您的 Route 53 记录（用作 CloudFront 后面的源服务器）的 TTL 行为符合预期，因此区域故障转移正确发生。
将此配置置于 CloudFront 之后的第二个原因是，如果您希望在边缘网络上传输流量。如果请求仅来自托管 API 的两个 AWS 区域，这可能无济于事，但总体上应该会提高响应能力。
请注意，跨区域的地理冗余并不是在每种情况下都可以使用 API Gateway 完全透明地完成 - 这取决于您如何使用它。想到的一个有问题的情况是您需要对传入请求进行 IAM 身份验证的设置。 X-Amz-Credential 包含目标区域，签名当然会有所不同，因为 Signature V4 中的签名密钥基于 secret/date/region/service/signing-key 范例（这是一个出色的设计，但我离题了） .这会使设置复杂化，因为调用者不知道目标区域。可能还有其他并发症。 Cognito 可能有类似的并发症。但是对于一个简单的 API，其中身份验证由您自己的应用程序令牌、cookie 等机制完成，这个新功能非常重要。
有点有趣的是，在宣布这项新功能之前，我实际上正在设计一个托管服务，该服务将处理请求的故障转移和地理路由到跨区域的 API 网关冗余部署，包括具有该功能的机制以补偿签名中所需的不同区域。目前我所从事的工作的未来前景还不太清楚。
【讨论】：
这意味着您可以根据区域部署 API，从而减少延迟。
一个用例是，假设您有一个调用 API 请求的 Lambda 函数。如果 Lambda 和 API 在同一个区域，那么您可以期待高性能
请关注https://docs.aws.amazon.com/apigateway/latest/developerguide/create-regional-api.html
【讨论】：