在上周的ReInvent上，发布的公告之一是ALB现在可以调用Lambas来提供HTTPS请求。由于我们已经可以将API网关连接到Lambdas，所以我有点困惑这个新功能解决了什么问题。
这是公告-https://aws.amazon.com/about-aws/whats-new/2018/11/alb-can-now-invoke-lambda-functions-to-serve-https-requests/
有人能举几个例子吗？
它解决的问题是，它允许使用Lambda函数处理HTTP请求和生成响应的另一种方式。
但是您已经可以使用API网关或CloudFront的Lambda@Edge特色
那么，真正解决了什么问题？
简化了Lambda请求处理与使用ALB的以服务器为中心的应用程序的集成。
虽然从某种意义上说，此功能提供了API网关功能的一个子集，但它在一个重要方面有所不同——允许您轻松地将Lambda函数"安装"到现有基于EC2的应用程序中的一组特定路径中。
您可以选择特定的路径模式，只将其发送到Lambda函数——在同一域下，没有任何跨域复杂性，也不需要通过您的EC2实例代理请求——同时继续从EC2为应用程序的其余部分提供服务。在应用程序中避免跨域资源简化了许多事情，尤其是cookie和会话。
虽然在某些情况下，您也可以使用它来代替API网关的功能，但我们的想法并不是专门为Lambda函数设置ALB，当然您也可以这样做。
这是一个伟大的公告，真正成为无服务器体系结构的推动者。在我看来，我觉得以下用例现在更有意义了：
- ALB上的侦听器，其中端口80和端口443，现在您可以根据端口侦听器将流量路由到不同的lambda函数。端口80将调用不同的lambda函数，端口443将调用不同
- 基于主机的路由
- 基于应用程序路径的路由
现在，这将使我们能够从/application触发器Lambda函数开始路由请求。
另一个区别是ALB支持HTTP端口80侦听器，而API网关仅支持HTTPS端口443。
在某些用例中，发送/接收数据的客户端/设备由于多种原因(例如远程或嵌入式设备(将不支持HTTPS。
ALB现在允许潜在的更便宜/更有针对性的代理直接进入Lambda功能，而不是从CloudFront到API网关再到Lambda。