EC2 上の Jenkins サーバーは、500 GB の gp2 EBS ボリュームを使用しています。夜間ビルドには持続的な 3,000 IOPS が必要ですが、CloudWatch ではビルド中にボリュームの BurstBalance が 0 になっていることが示されています。持続的な IOPS 要件を最も費用対効果の高い方法で満たす変更はどれですか？

gp2ボリュームはサイズに応じてIOPSが決まりますが、500GBではベースラインIOPSが1,500、バーストIOPSが3,000です。夜間ビルドで持続的な3,000 IOPSが必要で、BurstBalanceが0になっていることから、バーストクレジットが枯渇していることがわかります。gp2ボリュームを1,000GBに増やすと、ベースラインIOPSが3,000になり要件を満たしますが、ストレージコストが増加します。 gp3ボリュームは、サイズとは独立してIOPSとスループットをプロビジョニングできるため、500GBのままで3,000 IOPSをプロビジョニングできます。これにより、ストレージ容量を増やすことなく持続的なIOPS要件を満たせるため、最も費用対効果の高い解決策となります。 st1はスループットに最適化されたHDDであり、IOPS要件には適していません。io2は非常に高いIOPSを提供しますが、費用が高くなるため、このケースでは過剰なプロビジョニングとなり、費用対効果が低くなります。