这是否意味着我可以在两个区域部署相同的 API 代码，并向 Lambda 微服务发送请求？ （这将是两个不同的 Https 端点）
这已经是可能的了。您已经可以在多个区域部署相同的 API 代码并使用 API Gateway 创建不同的 HTTPS 终端节点。
以前，您无法做的是将不同区域中的 API Gateway API 端点配置为具有相同的主机名，如果您想使用 API 进行地理路由或故障转移场景，那么这是以前不可用的关键功能网关。
在之前的设置中（现已更名为“边缘优化端点”），每个 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 分配指向 CloudFront由 API Gateway 管理的分发，因此在 CloudFront 中循环两次，这意味着传输延迟和灵活性的一些损失。
创建区域 API 终端节点后，您可以将自己的 CloudFront 分配直接指向 API 终端节点。
如果您在单个区域中有一个 API，并且可以从全球各地的点访问它，并且您自己没有使用 CloudFront，那么边缘优化端点几乎肯定仍然是最佳选择。
但当涉及到自定义域名时，区域 API 端点会变得有趣。使用相同的自定义域名创建 API（例如api.example.com）在多个 AWS 区域中以前是不可能的，因为 API Gateway 依赖于 CloudFront。 CloudFront 是一项全球服务，因此主机名命名空间也是全球性的——全球只有一个 CloudFront 发行版可以响应特定的传入请求主机名。由于区域 API 终端节点不依赖于 CloudFront，因此可以在多个 AWS 区域中使用相同的自定义域名配置 API。
所以，假设你想服务api.example.com在 us-east-2 和 us-west-2 中，您需要部署单独的 API，然后在每个区域中为每个区域创建自定义域名配置api.example.com使用区域 API 端点，为每个部署选择 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 基于延迟的路由来创建 CNAME 记录api.example.com有两个目标（一个来自 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 返回指向的 DNS 记录d-aaaaaaaaaa.execute-api.us-east-2.amazonaws.com.
因此，此功能创建了在多个 AWS 区域部署 API 的能力，这些 API 将响应相同的主机名，而边缘优化 API 端点则无法实现这一点（在宣布此新功能之前，所有端点都是如此）。
CloudFront 是否为我分配流量？
不完全是。或者，至少，不是直接的。 CloudFront 不会根据请求者的区域确定来源，但 Lambda@Edge动态原点选择可用于根据请求者的一般位置修改源服务器（通过评估哪个 API 区域最接近恰好为特定请求提供服务的 CloudFront 边缘）。
但是，正如您在上面看到的，Route 53 基于延迟的路由可以为您做到这一点。然而，无论如何，仍然有一个令人信服的理由将此配置置于 CloudFront 发行版后面......实际上有两个原因......
这本质上是一种 DNS 故障转移配置，当浏览器或未听说过 Java 似乎会无限期缓存 DNS 查找的 Java 程序员进行访问时，这是众所周知的不可靠。浏览器对此也很糟糕。通过将 CloudFront 置于 DNS 故障转移配置之前，您不必担心客户端缓存您的 DNS 查找，因为 CloudFront 可以正确执行此操作。 Route 53 记录（用作 CloudFront 后面的源服务器）的 TTL 行为符合预期，因此区域故障转移正确发生。
将此配置置于 CloudFront 后面的第二个原因是您希望流量在边缘网络上传输。如果请求仅来自托管 API 的两个 AWS 区域，这可能没有帮助，但总体上应该会提高响应能力。
请注意，跨区域的地理冗余并不是在每种情况下都可以使用 API Gateway 完全透明地完成的 - 这取决于您如何使用它。我想到的一个有问题的案例涉及一种设置，您需要针对传入请求进行 IAM 身份验证。这X-Amz-Credential包括目标区域，签名当然会有所不同，因为 Signature V4 中的签名密钥基于秘密/日期/区域/服务/签名密钥范例（这是一个出色的设计，但我离题了）。这会使设置变得复杂，因为调用者不知道目标区域。可能还有其他并发症。 Cognito 可能也有类似的并发症。但对于通过您自己的应用程序令牌、cookie 等机制完成身份验证的简单 API 来说，这种新功能非常重要。
有点有趣的是，在宣布这项新功能之前，我实际上正在设计一项托管服务，该服务将处理跨区域 API 网关冗余部署的请求故障转移和地理路由，包括一种能够补偿故障的机制。签名中所需的不同区域。目前我正在做的事情的未来前景还不太清楚。
