はじめに
- Amazon EC2コンソールのアップデートで、インスタンス作成時にAmazon EFSやAmazon FSx（for NetApp ONTAP / for OpenZFS）をマウントできるようになった。
- これは、「何も考えずにEBSボリュームを使うのはやめて、用途や要件に応じて適切なストレージサービスを使い分けるべし」というAWS側のメッセージなのでは、と考えた。
EBSボリューム以外に選択肢が増えると何が良いのか
- パッと思いつくメリットを書き出してみた。
1. ストレージコストが安くなる（かもしれない）
- Amazon EFSやFSx for ONTAPはストレージ階層化の機能があり、パフォーマンスが必要のないアーカイブファイルなどはより安価な階層に落とすこでコストを削減できる。
- FSx for ONTAPは、さらに重複排除や圧縮の機能があるのでよりコストを削減できる可能性がある。
- 過去の記事で比較したところ、高性能なio1などのEBSボリュームタイプの場合、プロビジョニングするIOPSによってはFSx for ONTAPの方が安価になる。
- コストが安くなるのは嬉しい。
2. バックアップ/リストア運用が楽になる
- EBSボリュームは、EBSスナップショットからデータを復元するのが地味に面倒くさい。
- 別のEBSボリュームとして復元し、元ボリュームをデタッチして付け替えるか、元ボリュームとは別の領域としてマウントして復元しないといけない。
- その点、Amazon EFSは同じボリューム上にデータを復元できるし、FSx for ONTAPのSnapshot（NetApp ONTAPの機能）も同様。
- 運用負荷はいくら下がっても良い。
3. EC2インスタンスをステートレスに保ちやすくなり、IaC（Infrastructure as Code）が捗る
- EBSボリュームはEC2インスタンスとの結びつきが強いため、密結合になりがち。
- ルートボリューム以外のデータをAmazon EFSやFSx for ONTAPなどの共有ストレージに置くことで、EC2インスタンスをステートレスに保ちやすくなる。
- IaCでインフラ構築を自動化している環境でEBSボリューム内にステートフルなデータが格納されていると、そのEBSボリュームをアタッチしているEC2インスタンスを作り直すときになかなか手間がかかる。
- ステートフルなデータがフルマネージドなストレージサービスに集約されていると、その辺がやり易くなる気がする。
まとめ
- Amazon EBSは特にリッチな機能が備わっているわけではないただのブロックストレージなので、用途や要件に応じて最適なストレージサービスを使うというのは理に適っているし、メリットは多そう。
- ということで、Amazon EC2で何も考えずにEBSボリュームだけを使う時代は終わったのかもしれないし、少なくとも自分は少し考えてストレージサービスを使い分けようと思う。
- ちなみに、早速試してみようと思ったのだが、同時に自動作成されるセキュリティグループの作成に失敗してうまくいかなかった。AWS側の不具合とのこと。（2022/4/16現在）
（おまけ）GUI以外でどうやるのか
- 自動化推進過激派としては、インスタンスを作るのにGUIでポチポチやりたくない。
- APIリファレンスを見る限り、今回のGUIのアップデートによるAPIの変更はなさそうなのでこれまでと変わらないと思う。
- 事前にファイルシステム側を作っておいてインスタント作成時にUserDataでマウントしてあげるとか。後は他の構成管理ツール側でやるとか。
- やり方は変わらないが、改めて何も考えずにEBSボリュームを使うのは変えていこう。