Elastic Beanstalk を使って起動した EC2 インスタンスは、デフォルトで EBS 最適化がオフになるようです。t2 とか対応してないインスタンスだとわかるんですが、c4 系でもオフになるのは微妙ですね。
ちなみに c4.large で Windows インスタンスを立ち上げた場合も、きっちりとオフです。
ドキュメントを読むと最新の c4 / m4 系はデフォルトで EBS 最適化が有効になってるとかいてますが、Beanstalk は CloudFormation のタイミングとかで明示的にオフになってたりするのかもしれません。
もしくは意図があってオフになっているのかもしれないですが、EBS 最適化のデメリットが c4 / m4 系には存在していないと思うので、ebextensions を使って有効化します。
本来なら作成時のパラメータとして渡したいですが、CloudFormation に対して任意のパラメータを設定する方法は ebextensions しか無さそうです。
Resources: AWSEBAutoScalingLaunchConfiguration: Type: "AWS::AutoScaling::LaunchConfiguration" Properties: EbsOptimized: "true"
内容としては AutoScaling の LaunchConfiguration に EbsOptimized: true を追加しただけです。
リソース名とかは CloudFormation のテンプレートを見ればわかるようになってます。既存のサービスを組み合わせて作られているので、拡張性は思ったより高いです。
実際にパッケージを作成して Beanstalk にデプロイしますが、もちろん EBS 最適化に対応したインスタンスを選んで起動する必要はあります。今回は c4.large で試します。
暫く待つと EC2 インスタンスが立ち上がってきます。ちゃんと EBS 最適化が有効になっています。
Beanstalk で I/O が多いアプリケーションをデプロイするかと言われると微妙で、効果もあるのか確認はしてないですが基本的にデメリットはないので標準で対応して欲しいですね。
全く関係ないですが、今回の検証中に Windows Server 2012 R2 と Windows Server 2016 のインストールサイズを確認してみました。まずは Windows Server 2016 です。
Beanstalk のデフォルト EBS ボリュームサイズは 30GB ですが 4 割ほど空きがあります。Windows Server 2012 R2 の場合は 2 割ほどしか空きがありません。
Windows Server 2016 ではインストールサイズの最適化がそこそこ行われているようですね。
Beanstalk で Windows Server 2016 を使う場合、EBS はデフォルトの 30GB のままで問題になることはないでしょう。EBS のサイズ変更は Beanstalk の場合 EC2 作り直しになるので注意。