Terraform Backend用のS3バケットのバージョニング設定を考えてみる
「TerraformのBackend用のS3バケットのバージョニングはどうするべき?」
結論は以下です。
- バージョニングは有効化する
- ライフサイクルルールの設定は、設定無しでも良い(無期限保存、ファイル容量が小さいため、コスト増のリスクは低い)
S3バケットのバージョニングとは
単一のオフジェクトの複数のバージョンを保持できるようにする機能です。
「無効」「有効」「停止」の3つのステータスがあり、利用するには「有効」にする必要があります。(2023/12時点のデフォルト設定は「無効」)
詳細は以下のブログが、分かりやすいです。
バージョニングは有効化する
バージョニングは有効化することをお勧めします。
Backend用のS3バケット内に保存されるStateファイルは、Terraformを利用する上で重要なファイルです。
バージョニングを有効化しておくことで、各リビジョンを保存できます。
誤操作等で、Stateファイルを変更や削除してしまった際に、ロールバック可能です。
ちなみに、Terraformの公式ドキュメント上でも以下のように有効化を推奨する旨があります。
Warning! It is highly recommended that you enable Bucket Versioning on the S3 bucket to allow for state recovery in the case of accidental deletions and human error.
Backend Type: s3 | Terraform | HashiCorp Developer から引用
ライフサイクルルールの設定は、設定無しでも良い(無期限保存)
バージョニングを有効化すると、コスト等の問題で古いバージョンの取り扱いが気になると思います。
S3ではライフサイクルルールを使って、古いバージョンを削除等を行うことができます。
「Backend用のS3バケットに、ライフサイクルルールを設定するべきか」という話ですが、こちらは「設定なしでも良い」と考えています。
理由としては、以下です。
- Stateファイルの容量は小さく、更新頻度的にもコストへの影響は小さい
- 性質上バージョンが数百万まで増える可能性は低いため、S3のレスポンスに影響は出ない
1点目、コスト観点です。StateファイルはJSONのファイルで、容量はそこまで大きくありません。 具体的には、Resoruce数 60程度で 200 KB程度でした。(EKS Fargateを作成するTerraformで検証)
S3 Standardバケットのストレージ料金は以下でした。(東京リージョン、2023/12時点)
最初の 50 TB/月 0.025USD/GB
S3 標準 - 頻繁にアクセスするデータに一般的に使用される、あらゆるタイプのデータの汎用ストレージ
最初の 50 TB/月 0.025USD/GB
上記のStateファイルの場合、5,000バージョンでやっと1GBのため、コストへの影響は小さいです。
S3バージョニングの機能観点で確認します。
- S3バージョニングには、バージョン数の制限はない
- バージョン数が数百万まで増えると、レスポンスに影響が出ることはある
S3 バージョニングを有効にしたバケットへの Amazon S3 PUT または DELETE オブジェクトリクエストに対して受信される HTTP 503 (Service Unavailable) レスポンスの数が著しく増加した場合、バケットに数百万のバージョンが存在するオブジェクトがある可能性があります。詳細については、トラブルシューティングの「S3 バージョニングの使用」セクションを参照してください。
S3 バージョニングの仕組み - Amazon Simple Storage Serviceから引用
用途的に数百万まで行くことは、ほぼないため気にする必要はなさそうです。
おまけ: BackendにTerraform Cloudを使う
Terraform CloudをBackendとして利用することが可能です。
SaaSのため、ユーザーがS3 Bucektを用意する必要はありません。
バージョニングも有効になっており、Terraform Cloudの画面上から他バージョンとの差異を確認することも可能です。
まとめ
Terraform Backend用のS3バケットのバージョニングについてでした。
今回はバージョニングのみを取り上げましたが、Backend用S3全般の話はspaceliftさんのブログが参考になりました。
興味がある方は読んでみてください。
How to Manage Terraform S3 Backend - Best Practices
以上、AWS事業本部の佐藤(@chari7311)でした。