一家公司运行一个为期 3 年的项目，该项目中的应用程序使用 20 个注册到跨两个可用区的 Network Load Balancer 目标组的 Amazon EC2 On-Demand 实例。该应用程序是无状态的，并且 24/7 运行。正常 CPU 利用率约为 10%，但在持续数小时的短暂繁忙时段，CPU 会升至 100%。用户报告响应缓慢。哪种新架构能最经济高效地解决响应缓慢的问题？

此解决方案最经济高效，因为它利用了 Auto Scaling 组的弹性来应对流量高峰，同时通过 Reserved Instances 降低了基础负载的成本。将最小容量设置为 4，可以确保在低利用率时段只运行必要的实例，从而节省成本。当 CPU 利用率达到 100% 时，Auto Scaling 组可以自动扩展到最大容量 28 个实例，以处理增加的负载并解决响应缓慢的问题。为 4 个实例购买 Reserved Instances 可以在项目持续的 3 年内显著降低这部分基础容量的成本。 其他选项的不足之处： 选项一：将最小容量设置为 20 并在所有 20 个实例上使用 Reserved Instances，在正常利用率只有 10% 的情况下，成本过高，因为大部分时间这些实例都处于闲置状态。 选项二和选项三：Spot Fleet 不适合 24/7 运行且需要持续可用性的关键应用程序，因为 Spot 实例可能会被中断，导致服务中断或性能下降。此外，选项三中将 NLB 替换为 ALB 并非解决响应缓慢问题的核心，且会增加不必要的复杂性和潜在成本。