Azure Blob Storage ティア戦略完全ガイド｜Hot / Cool / Cold / Archive 選定とライフサイクル管理

Hot・Cool・Cold・Archive の 4 ティア。Hot: 頻繁にアクセスされるデータ向け、ストレージ料金は最も高いがトランザクション料金は最も安い。Cool: 30 日以上保管されアクセス頻度が低いデータ向け、ストレージ料金中・トランザクション料金中、最小保管期間 30 日 (早期削除はペナルティ)。Cold: 2022 GA、90 日以上保管想定、ストレージ料金 Cool より安く Archive より高い、トランザクション料金は Cool より高い、最小保管期間 90 日。Archive: 長期保管・年単位アクセスのアーカイブ用、ストレージ料金は最も安いが取り出しに数時間-15 時間かかる、最小保管期間 180 日。組織内ファイル → Hot、ログ・バックアップ → Cool、コンプライアンス長期保管 → Cold、規制対応 5-10 年保管 → Archive という使い分けが定石。

Storage Account のライフサイクル管理ポリシーは、Blob を自動的にティア移動・削除する JSON ベースのルール定義機能。代表的なルール: 1) 作成から 30 日後に Hot → Cool 移行、180 日後に Cool → Cold 移行、365 日後に Cold → Archive 移行、2,555 日 (7 年) 後に削除。2) 最終アクセスから 90 日後に Cool 移行 (Last Accessed Tracking 有効化必要)。3) 特定の Tag・Path・Prefix を持つ Blob のみ対象。ルールは JSON で定義し、Azure Portal・PowerShell・Azure CLI で適用。1 Storage Account あたり最大 100 ルール設定可能。本番運用ではコスト削減効果が大きく (年間数百万円規模) 必ず構成すべき機能です。Last Accessed Tracking は標準 Disabled で、明示的に有効化が必要 (有効化後の Last Accessed のみ追跡)。

Archive Blob の取り出しは 4 つの優先度から選択: 1) High Priority Rehydration: 15 GB 未満 で 1 時間以内、取り出し料金は標準の数倍、緊急時用。2) Standard Rehydration: 数時間 (-15 時間)、標準的なコスト、計画的取り出し。3) Bronze 階層への直接 Read: Set-AzStorageBlobContent でティア変更し Cool / Hot へリハイドレート (最も一般的)。4) Copy 操作で取り出し: 別の Blob にコピーする形でリハイドレート、元 Archive Blob は残せる。リハイドレート中は Blob の取得不可、完了通知は Event Grid 経由で受信可能。コンプライアンス要件で『5 年保管・取り出しは年 1 回の監査時のみ』のような要件で Archive は最強コスト最適化、ただし即時取り出しが必要なデータには絶対使わない。

Storage Account のデータ冗長化オプション。LRS (Locally Redundant Storage): 同一データセンター内 3 コピー、最安・99.999999999% (11 9s) の可用性、リージョン災害には弱い。ZRS (Zone Redundant Storage): 同一リージョン内 3 つの Availability Zone に 3 コピー、99.9999999999% (12 9s)、AZ レベル冗長。GRS (Geo Redundant Storage): プライマリで LRS + セカンダリリージョンで非同期 LRS、99.99999999999999% (16 9s)、リージョン災害対応。GZRS (Geo Zone Redundant Storage): プライマリで ZRS + セカンダリリージョンで非同期 LRS、最高可用性・最高コスト。RA-GRS / RA-GZRS (Read-Access GRS / GZRS): セカンダリリージョンへの読み取りアクセスも有効化、通常時もセカンダリから読める。本番一般 → ZRS、本番重要 → GZRS、コスト最小 → LRS、Disaster Recovery 必要 → RA-GZRS が定石。

可能です。アクセスティアは Hot ↔ Cool ↔ Cold ↔ Archive の任意の組み合わせで直接変更可能で、Hot → Archive 直接移行も問題なし。ただし最小保管期間ルールが適用される: Cool への移行後 30 日未満で別ティア移行・削除すると早期削除料金 (差分相当)、Cold への移行後 90 日未満で同じく早期削除料金、Archive への移行後 180 日未満で早期削除料金。実務的には: アップロード時に直接 Archive 指定 (1 度きりのアーカイブ書き込み) は有効、アップロード後すぐに Hot → Archive 移行は早期削除料金が発生せず OK、Cool/Cold/Archive で 30/90/180 日経過前に削除や移行は早期削除料金を計上する必要がある、という点を把握しておけば設計判断は明確です。

Storage Account のパフォーマンスティア: Standard: 汎用、Hot/Cool/Cold/Archive の 4 アクセスティア対応、コスト最適化が主。Premium Block Blob: SSD ベース、低レイテンシ (1-3 ms)・高 IOPS、Hot ティアのみ (Cool/Cold/Archive 非対応)、コスト高 (Standard の数倍-10 倍)。Premium Block Blob は: 1) 大量小ファイル読み書き (機械学習データセット・ログ集約)、2) リアルタイム分析の中間データ、3) 高頻度 API ベースアクセス、4) AKS PersistentVolume の高性能要件、で活用。コスト面では Standard で十分なケースが圧倒的多数で、Premium Block Blob は明確な低レイテンシ要件がある場合のみ。Block Blob 以外に Premium Page Blob (VM Managed Disk) や Premium File Storage (Azure Files) もある点に注意。

重要なセキュリティ施策: 1) Storage Account の Public Access を Disable (Allow Blob Anonymous Access = false)、Private Endpoint 経由のみアクセス。2) Microsoft Entra ID 認証 (Storage Blob Data Contributor などの RBAC ロール) を使用、Storage Account Key は緊急用に限定。3) SAS トークンには有効期限を必ず設定 (Stored Access Policy で集中管理)、User Delegation SAS (Entra ID ベース) を優先。4) Customer-Managed Key (CMK) で暗号化 (Key Vault または Managed HSM 連携)。5) Microsoft Defender for Storage 有効化 (悪意のあるアップロード検知・Sensitive Data Discovery)。6) Network Access を Selected Networks に制限 + Private Endpoint。7) Versioning + Soft Delete 有効化で論理削除・誤削除対策。8) Diagnostic Logs を Log Analytics に送信、Microsoft Sentinel で監視。本番運用では事故防止のため必ず構成すべき項目です。

AZ-104 (Administrator) のドメイン 2 (Storage 15-20%) で Blob・Files・アクセスティア・ライフサイクル・レプリケーション・SAS が深く問われる。AZ-204 (Developer Associate、2026-07 リタイア注意) で SDK 経由の Blob 操作、AZ-305 (Solutions Architect Expert) でストレージ選定アーキテクチャ、DP-203 / DP-700 (Data Engineer) でデータレイク用途、SC-300 (Identity Admin) で RBAC 認証、SC-100 (Cybersecurity Architect Expert) でデータ保護設計。Azure を扱うすべてのエンジニアにとって Storage Account の理解は必須スキルです。