我们在 EC2 集群前面使用 AWS API 网关和负载均衡器。网关需要负载均衡器是公有托管的，这就是我们将负载均衡器放在 VPC 的公有子网中，将所有 EC2 实例放在私有 VPC 中的原因。
由于负载均衡器位于公有 VPC 中，我们面临的问题是，我们如何使不是来自 API 网关的请求无效。我们只想将请求从负载均衡器传递到 EC2 实例，当且仅当它通过我们的 API 网关时。
当我探索可能的解决方案时，有人建议使用来自网关的公共客户端证书来验证您的请求。我能够从网关获取此公共证书，但没有找到任何在负载均衡器中配置它的方法。
现在正确的解决方案是将 VPC 链接与 AWS 中的网络负载均衡器结合使用。您可以在 VPC 资源(例如 EC2 实例(前面设置网络负载均衡器，然后创建 API 网关 VPC 链接。在 API 网关集成中，您可以选择 VPC 链接，然后能够访问网络负载均衡器和扩展您的私有 EC2 实例。
您无法在负载均衡器级别验证客户端证书。需要在容器级别对其进行验证。
您还可以遵循另一种方法，方法是将负载均衡器保持私有并使用 Lambda 函数(放置在 VPC 中(代理到负载均衡器，您可以在其中验证客户端证书。
在进一步分析中，我遇到了以下有关 AWS API 网关方法的问题。
- 当 lambda 容器未重复使用或处于冷状态时，VPC 对 lambda 容器初始化时间有巨大影响。根据其他人的经验，这可能需要 10 到 15 秒，并且可能会延迟响应时间。即使它是热 lambda，当您从它访问 VPC 时，也会产生时间延迟成本。
- Lambda 需要足够数量的 ENI 和私有 IP 范围来支持并行执行。这意味着如果在运行时，负载增加，并且没有任何可用的弹性网卡，则请求将失败。我们不确定是否可以根据请求负载在运行时动态增加 ENI。
- 如果由于 ENI 不可用而导致出现任何错误或超时，AWS 不会为其创建任何日志，您可能对错误来源一无所知。