Azure Storage Lifecycle Management 完全ガイド｜Blob 自動 Tier 移行・Snapshot/Version 整理・コスト最適化

Storage Lifecycle Management は、Azure Storage の Blob / Data Lake / Files・Disk のライフサイクル全般を管理する仕組みの総称。本記事では特に Blob Lifecycle Management Policy (Tier 自動移行・自動削除)・Soft Delete・Versioning・Snapshot 管理・古いリソースの自動削除を統合的に解説。代表的な施策: 1) Blob Tier 自動移行 (Hot → Cool → Cold → Archive)、2) 古い Blob の自動削除 (Retention Policy)、3) 古い Version / Snapshot の自動削除、4) 古い Disk Snapshot / VM Image の整理、5) Storage Account 全体の Container Policy 統一。年間数百万-数千万円規模のコスト削減効果があり、本番運用では必須の自動化です。

Lifecycle Management Policy は JSON で定義する Rule の集合。Rule 構造: 1) name (ルール名)、2) enabled (有効/無効)、3) type: 'Lifecycle'、4) definition: { filters: { blobTypes: ['blockBlob'], prefixMatch: ['container1/logs/'], blobIndexMatch: [...] }, actions: { baseBlob: { tierToCool: { daysAfterModificationGreaterThan: 30 }, tierToArchive: { daysAfterModificationGreaterThan: 90 }, delete: { daysAfterModificationGreaterThan: 365 } }, snapshot: {...}, version: {...} } }。Filter で対象 Blob を絞り込み (prefix / blob type / Blob Index Tag)、Action で実行内容 (tierTo* / delete) を定義。最大 100 Rules / Storage Account。Azure Portal の Lifecycle Management ペインで GUI 編集も可能で、JSON 直接編集と併用するのが標準的な運用です。

daysAfterModificationGreaterThan: Blob の最終 Modification 日 (作成または書き込み) からの経過日数で判定。最も一般的、デフォルト動作、追加機能不要。daysAfterLastAccessTimeGreaterThan: Blob の最終 Access 日 (Read 操作) からの経過日数で判定、より動的なライフサイクル。Last Access Tracking 機能の有効化が必要 (Storage Account レベルの 1 つの設定)、有効化以降の Access のみ記録 (過去 Access は記録なし)、Read 操作で日次更新 (頻繁更新によるストレージ追加コストなし)。代表的なルール: 『Last Access から 90 日経過で Cool 移行、180 日で Archive、365 日で削除』。Last Access Tracking はストレージ無料・有効化推奨。Active な業務データを Hot に残し、使われないアーカイブを自動的に低コストティアへ移動する『真の自動最適化』が実現可能です。

Versioning: Blob 変更時に旧バージョンを自動保持する機能、Storage Account レベルで有効化。Snapshot: 手動またはコード経由で Blob のスナップショットを取得する機能。両方ともストレージ追加消費するため Lifecycle で削除制御必須。代表的なルール: 1) Snapshot は 30 日後削除、2) Version は 90 日後削除、3) Soft Delete された Blob は 30 日後完全削除。本番運用では Versioning + Snapshot を有効化しつつ、Lifecycle で適切に削除することでコスト管理。Microsoft 推奨: Blob は 7 日 Soft Delete + 30 日 Snapshot + 90 日 Version Retention の組み合わせ。設定漏れで Snapshot / Version が無制限蓄積されるとコスト爆発のリスクがあるため、Lifecycle 設定は Storage Account 作成と同時に必須レベルです。

Disk Snapshot / VM Image は Blob Lifecycle Policy の対象外、別途運用必要。代表的な自動化パターン: 1) Azure Automation Runbook で PowerShell スクリプト定期実行 (例: 90 日経過した Snapshot を Get-AzSnapshot で取得 → Remove-AzSnapshot で削除)、2) Azure Logic Apps の Recurrence Trigger + Azure REST API、3) Azure Functions の Timer Trigger + Azure SDK、4) Azure Backup の Backup Vault Policy で Snapshot Retention 自動管理 (Azure Backup 経由で取得した Snapshot のみ)、5) DevOps Pipeline で IaC 経由の定期クリーンアップ。本番運用では Azure Automation Runbook が最も柔軟、Tag ベース (例: AutoDelete=true) で削除対象を識別する設計が一般的。Snapshot の累積コスト (月数千-数万円) は気づきにくい『隠れコスト』、定期削除自動化は必須です。

Lifecycle Management Policy は Blob レベルのみで Storage Account / Container 自体の削除は対象外。組織レベルでの整理パターン: 1) Tag ベースの命名規則 (CreatedDate・Owner・Project・AutoDeleteDate)、Tag が古いリソースを自動検出、2) Azure Resource Graph Query で 6 ヶ月未使用 Storage Account 一覧、3) Azure Automation Runbook で Tag 条件マッチの Storage Account を週次レビュー + 通知、4) Azure Policy の Deny Effect で『6 ヶ月以上未使用 Storage Account 作成禁止』、5) Cost Management で月額 0 円の Storage Account 検出 (使われていないがコスト発生)。本番運用では Azure Resource Graph + Logic App でレポート自動化、Owner に削除提案メール送信、承認後に削除のワークフローが現代的なベストプラクティス。これにより組織のリソース蓄積を継続的に最適化できます。

重要な注意点: 1) Policy 設定後、初回評価まで 24-48 時間 (即時ではない、想定外の動作確認が必要)、2) Archive 移行後 180 日未満で削除すると早期削除料金 (Cool 30 日・Cold 90 日も同様)、3) Lifecycle Policy の Filter は Container 単位 (Storage Account 全体は対象外)、4) BlockBlob のみ対応 (PageBlob / AppendBlob は別途)、5) Last Access Tracking 有効化後の Access のみ記録、過去データの判定不可、6) Policy 評価は内部的に List Blob 操作実行、大量 Blob 環境では Transaction コスト発生、7) Audit Logs で Policy 動作確認、想定外削除発生時の調査用。設定変更時は Report-only モード相当の挙動シミュレーションがないため、必ず Dev 環境で動作確認 → Production 適用が安全運用パターンです。

AZ-104 (Administrator) のドメイン 2 (Storage 15-20%) で Lifecycle Management が深く問われる本領域の主要トピック。AZ-305 (Solutions Architect Expert) でコスト最適化設計、DP-700 (Fabric Data Engineer) で OneLake / ADLS Gen2 の Lifecycle、DP-300 (DBA) で Backup Retention 戦略との連携。Azure コスト管理は組織全体の継続課題で、Lifecycle Management の理解はクラウドコスト管理担当者・FinOps エンジニアにとって必須スキルです。