一家公司的有状态应用程序在 Amazon EC2 实例的内存中运行。基础设施是使用 AWS CloudFormation 部署的，采用 M5 EC2 实例系列。随着流量增加，应用程序性能下降，用户遇到延迟。哪种解决方案能以最高的运营效率解决这些问题？

正确答案通过升级实例类型并增强监控来解决问题。R5 实例是内存优化型，适用于有状态应用程序的内存密集型需求，这直接解决了性能下降和延迟问题。部署 CloudWatch 代理以生成自定义应用程序延迟指标至关重要，因为 EC2 的内置指标不包括内存使用情况，而自定义指标能提供对应用程序性能更深入的洞察，从而实现准确的容量规划。 其他选项不理想： 将 EC2 实例替换为 T3 实例并使用 Auto Scaling 组不合适，因为 T3 实例是突发性能型，不适合持续高内存使用，并且手动更改 Auto Scaling 组不具备运营效率。 修改 CloudFormation 模板以使用 Auto Scaling 组，但手动增加容量和最大容量，这虽然引入了 Auto Scaling，但手动干预降低了运营效率，且未解决实例类型可能不适合内存密集型应用的问题。 将 EC2 实例替换为 R5 实例，但仅使用 CloudWatch 内置的 EC2 内存指标进行容量规划是不够的，因为 EC2 的内置指标不直接提供内存使用情况，需要自定义指标才能有效监控应用程序的内存需求。