AWS S3 は高い耐久性と柔軟性を持つストレージサービスですが、バージョニングとライフサイクル管理を適切に設定しないと、不要なオブジェクトが増え続け、コスト増加や運用リスクにつながります。
本記事では、Terraform を使って S3 バケットのバージョニングとライフサイクルを管理する方法を、実践的な設定例とともに解説します。
この記事でわかること
- S3 バケットのバージョニングの役割
- ライフサイクルルールでできること
- Terraform による設定例（実務向け）
- 設計時の注意点とベストプラクティス
S3 バージョニングとは
S3 のバージョニングを有効にすると、同じキー（オブジェクト名）に対する変更履歴をすべて保持できます。
主なメリット
- 誤削除・誤上書きからの復旧が可能
- 監査・トラブルシュートに有効
- IaC（Terraform）と相性が良い
注意点
- 古いバージョンも課金対象
- ライフサイクル管理とセットで設計しないとコストが増加
ライフサイクル管理とは
ライフサイクルルールを使うことで、オブジェクトの保存期間やストレージクラスの遷移、削除を自動化できます。
よく使われるルール例
- 一定期間後に Glacier へ移行
- 古いバージョンを自動削除
- 不完全なマルチパートアップロードの削除
Terraform による設定例
以下は、バージョニング + ライフサイクル管理を有効にした S3 バケットの Terraform 設定例です。
resource "aws_s3_bucket" "example" {
bucket = "my-example-bucket"
}
resource "aws_s3_bucket_versioning" "example" {
bucket = aws_s3_bucket.example.id
versioning_configuration {
status = "Enabled"
}
}
resource "aws_s3_bucket_lifecycle_configuration" "example" {
bucket = aws_s3_bucket.example.id
rule {
id = "log-archive-rule"
status = "Enabled"
filter {
prefix = "logs/"
}
transition {
days = 30
storage_class = "STANDARD_IA"
}
transition {
days = 90
storage_class = "GLACIER"
}
noncurrent_version_expiration {
noncurrent_days = 180
}
}
}
設定内容の解説
バージョニング
resource "aws_s3_bucket_versioning" "example" {
versioning_configuration {
status = "Enabled"
}
}
- すべてのオブジェクト変更履歴を保持
- 削除しても「削除マーカー」が付くだけ
ライフサイクルルール
-
logs/プレフィックス配下のみ対象 - 30日後に
STANDARD_IA - 90日後に
GLACIER - 古いバージョンは 180日後に削除
実務での設計ポイント
1. バージョニングは「必ず」ライフサイクルとセット
バージョニング単体はコスト増加の原因になります。
noncurrent_version_expiration の設定を忘れないようにしましょう。
2. バケットポリシー・IAMと合わせて管理
- 誰が削除できるのか
- 復旧操作を誰が行うのか
運用ルールも明確にすることが重要です。
3. Terraform state との整合性
- 手動変更は極力避ける
- 変更は Terraform 経由で統一
まとめ
- S3 バージョニングは安全性向上に有効
- ライフサイクル管理でコストを最適化
- Terraform を使うことで設定をコードで一元管理できる
S3 × Terraform は、運用負荷とリスクを下げる強力な組み合わせです。
ぜひ自分の環境に合わせてカスタマイズしてみてください。
参考
- AWS S3 バージョニング公式ドキュメント
- Terraform AWS Provider Documentation