EBSボリュームとパーティションについて

前言

最近、EBSの構成とOSのパーティションを悩んでいます。
「汎用SSD(gp2)EBSはボリュームのサイズを大きくするとIOPSも大きくなる」のことを聞いたことがあるでしょうか？
複数のパーティションが一つ大きいボリュームにするIOPS増やすように考えしています。。。

どうすればいいのか？

EBSのベストプラクティス

該当部分を一部抜粋

オペレーティングシステム用およびデータ用として個別に Amazon EBS ボリュームを使用します。データのボリュームがインスタンス終了後も保持されることを確認します。詳細については、「インスタンスの削除で Amazon EBS ボリュームを保持する」を参照してください。

■ 参考リンク
Amazon EC2 のベストプラクティス – Amazon Elastic Compute Cloud https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-best-practices.html

つまり

OSが一つのEBS
データが一つのEBS

複数のデータパーティションが一つのEBS合計１６GB以下なら、
っていいですね？？

実は？

AWS サポートさんに聞いてみました

OS 用とデータ用で EBS ボリュームを分けていただくことを推奨しておりますのは、ルートボリュームでは DeleteOnTermination がデフォルトで true である一方で、ルート以外のボリュームではデフォルトで false となっており、EC2 インスタンスの削除時にデータ用のボリューム (ルート以外のボリューム) が自動的に削除されることを回避するためでございます。

自動的に削除されない回避のためか。。。。

では、
複数のパーティションが一つ大きいボリュームにするIOPS増やすのベストプラクティスがありますか？
AWS サポートさんから回答

データ用のパーティションが複数ある場合に、パーティションごとに EBS ボリュームを作成するべきか、それとも 1 つ EBS ボリュームにこれら全てのパーティションを含めるべきか。
結論は、上記の観点において当方から推奨している方法はございません。
例えば、特定のパーティションのみをデータベース等のミッションクリティカルなワークロードに使用するような場合では、そのパーティションのみio1タイプのボリュームするという方法が考えられます。
他にも、管理のしやすさのために、1 つのパーティションに 1 つの EBS ボリュームを対応させるということも考えられます。

まとめ

• 1 つのパーティションに 1 つの EBS ボリュームで構成する　⇒　管理容易
• パフォーマンス要件があるパーティションのみio1を利用する　⇒　シンプル

以上です
この記事がどなたかのお役にたてば幸いです。