一个为移动应用提供服务的单体式 REST API 运行在公共子网中的五台 EC2 实例上，并通过一个直接指向这些实例 IP 的 Route 53 多值应答记录进行访问。突然出现的大流量高峰正在使该应用不堪重负。哪种解决方案能够以最少的操作开销，使应用程序扩展以应对新的、可变的负载？

正确答案是：在 API 前部署一个 Application Load Balancer (ALB)，将 EC2 实例移动到私有子网，将实例注册为 ALB 目标，并更新 Route 53 记录以指向 ALB。 这个方案操作开销最少，因为它直接解决了当前架构的扩展性问题，而无需对应用程序代码进行重大更改。ALB 提供自动负载均衡、健康检查和高可用性，能够有效应对流量高峰。将 EC2 实例移至私有子网并使用 ALB 还可以提高安全性，因为实例不再直接暴露在公共网络中。 其他选项： 将 API 拆分为 Lambda 函数涉及重构单体应用，操作开销巨大，不符合“最少操作开销”的要求。 将 API 容器化并在 EKS 中运行也需要大量的重构和运维工作，增加了复杂性。 将 EC2 实例放入 Auto Scaling 组是正确的方向，但手动创建 Lambda 函数来更新 Route 53 记录过于复杂且不推荐。ALB 可以与 Auto Scaling 组无缝集成，自动注册和注销实例，无需额外的 Lambda 函数。