在游戏发布期间，一家公司在 Network Load Balancer 后运行了 12 个 r6g.16xlarge（内存优化型）Amazon EC2 实例。监控显示实际使用量约为预期 CPU 和内存的四分之一。目前需求已下降并变得更具可变性。该公司将用基于 CPU 和内存进行扩展的 Auto Scaling 组替换固定实例组，以最大限度地降低成本。哪种 Auto Scaling 配置在满足要求的同时最具成本效益？

原始实例是 r6g.16xlarge（内存优化型），表明应用程序对内存有较高要求。因此，选择内存优化型实例（r6g 系列）是合适的。由于当前使用量仅为预期的四分之一，将实例大小从 16xlarge 降至 4xlarge 可以显著降低成本，同时提供足够的资源。12 个 r6g.16xlarge 实例的四分之一计算能力相当于 3 个 r6g.16xlarge 实例，或者 12 个 r6g.4xlarge 实例。因此，将最小容量设置为 3 个 r6g.4xlarge 实例，最大容量设置为 12 个，可以在满足高峰需求的同时优化成本。 其他选项不合适的原因： c6g.4xlarge 是计算优化型实例，可能无法满足应用程序的内存需求。 m6g.4xlarge 是通用型实例，可能无法满足应用程序的内存需求。 r6g.8xlarge 实例虽然是内存优化型，但其大小可能仍然过大，导致成本高于 r6g.4xlarge 实例，且其最小容量设置为 2，可能无法满足初始的四分之一负载需求（相当于 3 个 r6g.16xlarge 或 12 个 r6g.4xlarge）。