Cloud Service
Amazon S3 Glacier
アクセス頻度の低いデータを高い耐久性のまま超低コストで長期アーカイブできる S3 のストレージクラス群です。
- 1.S3 のアーカイブ向けストレージクラスで、保管コストを大幅に抑えられる
- 2.取り出しには時間と料金がかかるため、アクセス頻度に応じてクラスを選ぶ
- 3.高い耐久性と複数の取り出しオプションを備え、コンプライアンス保管にも適する
Amazon S3 Glacier は、めったにアクセスしないデータを長期間にわたって安全かつ低コストで保管するための、Amazon S3 のアーカイブ向けストレージクラス群です。バックアップ、ログ、メディア原本、規制対応のための保管データなど、すぐに取り出す必要はないが消すこともできないデータの置き場所として広く利用されます。
解決する課題
データには、生成直後は頻繁にアクセスされるが、時間の経過とともにほとんど読まれなくなるという性質があります。こうした「コールドデータ」を、即時アクセスを前提とした標準ストレージに置き続けると、利用実態に見合わない保管コストが発生します。
一方で、規制対応や監査、将来の分析のために長期保管そのものは必要になるケースが多くあります。S3 Glacier は、取り出しに一定の時間と料金がかかることを許容する代わりに保管単価を大幅に下げることで、「消せないが普段は読まないデータ」を経済的に保持するという課題を解決します。自前のテープ装置やオフサイト保管を運用する代わりに、高い耐久性を持つマネージドなアーカイブ基盤を利用できる点も大きな利点です。
主要概念と用語
- アーカイブストレージクラス: S3 のストレージクラスのうち、アクセス頻度の低いデータ向けに保管コストを最適化したもの。即時取り出し向けと、取り出しに時間を要する向けに分かれます。
- Glacier Instant Retrieval: ミリ秒単位で即時に取り出せるアーカイブクラス。四半期に一度程度しかアクセスしないが、必要なときにはすぐ読みたいデータに向きます。
- Glacier Flexible Retrieval: 取り出しに数分から数時間を要するクラス。コストと取り出し速度のバランスを取りたいバックアップなどに向きます。以前は Glacier と呼ばれていた区分に相当します。
- Glacier Deep Archive: 最も保管単価が低く、取り出しに時間を要するクラス。年に一度程度しかアクセスしない長期保管に向きます。
- 取り出し(リトリーブ): アーカイブされたオブジェクトを読み取り可能な状態にする操作。取り出し速度のティア(迅速・標準・大容量など)によって所要時間と料金が変わります。
- ライフサイクルポリシー: オブジェクトの経過日数などに応じて、別のストレージクラスへ自動的に移行したり削除したりする S3 のルール。
- S3 Glacier ボールト: 旧来の Glacier 専用 API で利用するアーカイブの入れ物。現在は S3 のストレージクラスとして扱う方式が一般的で、本記事も主にそちらを前提とします。
仕様・制限・クォータ
S3 Glacier の各クラスはオブジェクトストレージとして S3 のバケットの中に存在し、通常の S3 オブジェクトと同じキー構造やメタデータの考え方を共有します。耐久性は S3 の他クラスと同等に高い水準で設計されています。
重要な制限として、取り出しに時間を要するクラス(Flexible Retrieval や Deep Archive)では、オブジェクトを直接読むことはできず、まず取り出しリクエストを発行して一時的にアクセス可能な状態にする必要があります。取り出し速度のティアによって所要時間が変わり、迅速なティアほど料金が高くなる傾向があります。
また、これらのクラスには最小保管期間が設定されており、その期間より早く削除や上書きを行うと、残りの期間分の保管料金が課金される点に注意が必要です。さらに、小さなオブジェクトを大量に保管する場合は、各オブジェクトにメタデータ用のオーバーヘッドが加算されるため、極端に小さいファイルは集約してから保管する方が効率的です。具体的な所要時間や金額、最小保管期間の日数は変動し得るため、利用前に公式ドキュメントで最新値を確認してください。
内部の仕組み
S3 Glacier のクラスに保管されたデータは、複数の物理的に分離した設備に冗長化して格納されることで、高い耐久性が実現されています。利用者から見ると S3 のオブジェクトですが、内部ではアクセス頻度の低さを前提にコストを最適化した媒体やレイアウトで保持されています。
取り出しを要するクラスでは、オブジェクトの実体はすぐに読める状態にはなっておらず、取り出しリクエストを受け取ってから一時的なコピーを利用可能領域へ復元します。この復元処理に要する時間が、ティアごとの取り出し所要時間として現れます。Instant Retrieval のように即時アクセス可能なクラスは、この復元ステップを必要としない代わりに保管単価が相対的に高く設定されています。整合性についても、保管後のオブジェクトは強い耐久性を持つよう設計されており、保管中のデータ破損を検知・修復する仕組みが背後で継続的に働いています。
設計パターン / ベストプラクティス
最も一般的なパターンは、ライフサイクルポリシーによる自動階層化です。生成直後は S3 標準に置き、一定日数を過ぎたら Glacier 系クラスへ自動移行し、保管期限を迎えたら自動削除するというルールを組むことで、アクセス頻度の変化にコストを追従させられます。
クラスの選択は、想定される取り出し頻度と許容できる取り出し時間で決めます。普段は読まないが必要なときは即時に欲しいなら Instant Retrieval、即時性が不要でコストを抑えたいバックアップなら Flexible Retrieval、年に一度程度の超長期保管なら Deep Archive が目安です。
ストレージクラス間の移行操作自体にもリクエスト料金が発生します。大量の小さなオブジェクトを頻繁に移行すると移行コストがかさむため、移行のしきい値となる日数は十分に長く取り、オブジェクトはある程度のサイズに集約しておくと効率的です。
取り出しを要するアーカイブクラスには最小保管期間があり、その期間より前に削除すると差分の保管料金が課金されます。短期間で消す可能性があるデータをアーカイブクラスへ移行すると、かえって割高になることがあります。
運用・監視
運用面では、まずストレージクラスごとの保管容量とコストの可視化が重要です。S3 のストレージレンズや使用状況のメトリクスを用いて、どのクラスにどれだけのデータが滞留しているかを定期的に確認します。
取り出し操作については、リクエストの完了をイベント通知で受け取る仕組みを使い、処理が長時間に及ぶティアでも完了を確実に検知できるようにします。アクセスや取り出しの監査が必要な場合は、API 呼び出しの記録を有効にしておき、誰がいつどのオブジェクトを取り出したかを追跡できるようにします。ライフサイクルポリシーが意図どおりに移行・削除を行っているかも、定期的に対象オブジェクト数の推移を見て確認すると安心です。
コスト
S3 Glacier のコストは主に、保管容量に対する月額の保管料金と、データを取り出す際の取り出し料金、そして API リクエストや移行に対する料金で構成されます。保管単価はアーカイブクラスの中でも Deep Archive が最も安く、Flexible Retrieval、Instant Retrieval の順に高くなる傾向があります。
コスト最適化の要点は、保管単価の安さだけでなく取り出しコストとのバランスを見ることです。保管が安いクラスほど取り出しに時間と料金がかかるため、想定アクセス頻度より過度に安いクラスを選ぶと、取り出しのたびに割高な費用が発生します。また前述のとおり、最小保管期間より早い削除や移行には差分課金が発生します。具体的な単価は地域やクラス、時期によって変動するため、設計時には公式の料金ページで最新値を確認し、保管量と年間の想定取り出し量の両方で試算してください。
セキュリティ
S3 Glacier のオブジェクトは S3 の暗号化機能を継承し、保管時の暗号化を有効にできます。鍵管理サービスと連携した暗号化を用いれば、鍵のアクセス制御や監査も一元化できます。
アクセス制御は IAM ポリシーやバケットポリシーで行い、取り出しや削除といった操作を必要最小限の主体だけに許可します。コンプライアンス用途では、オブジェクトロックによる書き換え・削除の防止(WORM 相当の保護)を組み合わせることで、保管期間中の改ざんや誤削除を防げます。通信経路の暗号化、最小権限の原則、操作ログの取得を併用することで、長期保管データに対する一貫したセキュリティを確保できます。
Well-Architected の観点
コスト最適化の柱では、アクセス頻度に応じて適切なアーカイブクラスを選び、ライフサイクルで自動階層化することが中心的なプラクティスになります。データの利用実態を継続的に観測し、過剰なストレージクラスに滞留していないかを見直すことが重要です。
信頼性の柱では、高い耐久性を持つマネージドなアーカイブ基盤に長期データを預けることで、自前媒体の劣化や紛失のリスクを下げられます。取り出しに時間がかかるクラスを選ぶ場合は、復旧手順の中に取り出し所要時間を織り込み、目標復旧時間と矛盾しないクラスを選定することが信頼性確保の鍵になります。
試験で問われるポイント
- 取り出しに時間を要するアーカイブクラス(Flexible Retrieval、Deep Archive)と、即時取り出し可能な Instant Retrieval の違いと使い分け
- ライフサイクルポリシーで標準クラスからアーカイブクラスへ自動移行し、期限到来で自動削除する設計
- 取り出し速度のティア(迅速・標準・大容量など)によって所要時間と料金が変わること
- 最小保管期間より早い削除で差分課金が発生する点
- 超長期かつ最安の保管要件なら Deep Archive を選ぶという定番の判断
関連サービス・比較
長期アーカイブ用途では、同じ S3 内のアクセス頻度が読めないデータ向けクラスである S3 Intelligent-Tiering と比較されることがよくあります。Glacier 系は「アクセスがほぼないと分かっているデータ」を明示的に安いクラスへ置く考え方であるのに対し、Intelligent-Tiering は「アクセスパターンが読めないデータ」を自動で適切な階層へ移す考え方です。
| 観点 | S3 Glacier 系クラス | S3 Intelligent-Tiering |
|---|---|---|
| 主な用途 | アクセスがほぼないと分かっている長期保管 | アクセスパターンが読めないデータの自動最適化 |
| 階層移動 | ライフサイクルで明示的に移行 | アクセス状況に応じて自動で移行 |
| 取り出し時間 | クラスにより即時または数分から数時間 | 基本的に即時アクセス |
| コスト特性 | 保管単価は非常に低いが取り出し料金が発生しうる | 監視手数料がかかるが取り出し料金は基本不要 |
ハンズオン / CLI例
既存オブジェクトをアーカイブクラスへ移行する例と、取り出しに時間を要するクラスからオブジェクトを復元(取り出し)する例です。
# 1. オブジェクトを Glacier Flexible Retrieval クラスへ移行(コピーで上書き)
aws s3 cp s3://my-archive-bucket/logs/app.log s3://my-archive-bucket/logs/app.log \
--storage-class GLACIER \
--metadata-directive COPY
# 2. アーカイブクラスのオブジェクトを取り出し(標準ティア、7日間アクセス可能にする)
aws s3api restore-object \
--bucket my-archive-bucket \
--key logs/app.log \
--restore-request '{"Days":7,"GlacierJobParameters":{"Tier":"Standard"}}'
# 3. 取り出し状況の確認(Restore ヘッダで進行中か完了かを確認)
aws s3api head-object \
--bucket my-archive-bucket \
--key logs/app.log
AWS Service
Amazon S3 Glacierを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
ストレージ
比較で見る軸
クラウド: AWS / カテゴリ: ストレージ / 難易度: basic
導入後に効く点
取り出しには時間と料金がかかるため、アクセス頻度に応じてクラスを選ぶ
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- ストレージ
- 難易度
- basic
- 関連資格
- SAA-C03 / SOA-C02
- 設計柱
- cost / reliability
判断チェックリスト
- 自社の用途が「ストレージ / cost」に近いか確認する。
- 強みである「S3 のアーカイブ向けストレージクラスで、保管コストを大幅に抑えられる」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。