Storage Tiering Strategy

ゴール

最終的に、

古いデータ
→ とにかくArchive

ではなく、

どのくらいの頻度で読むか
+
読めるまで何時間待てるか
+
どれくらい保存するか
+
データサイズはどうなっているか

から、

S3 Storage Class
S3 Intelligent-Tiering
S3 Lifecycle
S3 Glacier
EBS Snapshots Archive

を使い分けられることがゴールです。

1. ストレージ階層化では「保存単価」だけを見ない

ストレージの総コストには、保存料金以外も影響します。

例えば、

保存料金
+
リクエスト料金
+
ストレージクラス移行
+
データ取得
+
復元
+
モニタリング
+
最小保存期間による料金

です。

そのため、

GB単価が低い
=
必ず総コストも低い

とは限りません。

例えば、頻繁に取得するデータを取得料金のある低頻度アクセス向け階層へ移すと、

保存料金
↓
取得コスト
↑

となる可能性があります。

2. 最初に見るのはAccess Frequencyだけではない

ストレージ階層化では、少なくとも次の項目を確認します。

例えば、

年1回しか読まない

という条件だけでは、

ミリ秒で取得必須

なのか、

半日待てる

のかが分かりません。

この2つでは適切なアーカイブ階層が異なります。

3. S3 Storage Classをアクセスパターンへ対応付ける

代表的なS3ストレージクラスを整理すると、概ね次のようになります。

ここで、

最も低頻度
→ 最も安い階層

と機械的には決めません。

既に定めた可用性・耐障害性要件を満たしたうえで、

アクセス頻度
+
取得時間
+
保持期間

を使って絞ります。

4. 既知のアクセスパターンはS3 Lifecycleへ落とし込む

アクセスパターンが明確なら、S3 Lifecycleで時間経過に応じて自動的にストレージクラスを変更できます。

例えば、

作成直後
毎日アクセス

30日後
ほとんどアクセスしない

1年後
監査時のみ利用

というデータなら、

作成
↓
高頻度向け階層
↓
低頻度向け階層
↓
アーカイブ階層

というライフサイクルを設計できます。

重要なのは、

古くなったから移す

ではなく、

作成から何日後に
アクセスパターンがどう変わるか

を根拠にすることです。

5. 不明・変化するアクセスパターンではS3 Intelligent-Tieringを評価する

アクセス頻度が、

予測できない
変化する
不規則

場合、固定した日数だけで階層を決めるのが難しくなります。

この場合、

S3 Intelligent-Tiering

を評価します。

S3 Intelligent-Tieringでは、オブジェクトのアクセスパターンを監視し、アクセス状況に応じて低コストのアクセス階層へ自動的に移動します。

基本的な低レイテンシー階層では、

Frequent Access
↓
30日間アクセスなし
↓
Infrequent Access

さらに
90日間アクセスなし
↓
Archive Instant Access

のように階層化されます。

アクセスされると、対象データは高頻度アクセス階層へ戻ります。

つまり、

アクセス時期を正確に予測できない

こと自体が、S3 Intelligent-Tieringを評価する重要な条件です。

6. Intelligent-Tieringにもコスト条件がある

S3 Intelligent-Tieringは、

完全無料で自動最適化

という意味ではありません。

オブジェクトのモニタリングと自動化に料金があります。

また、128 KB未満のオブジェクトは、

自動階層化の対象外

で、Frequent Access階層に残ります。

したがって、

数十KBの小さいファイルが
数億個存在する

ようなケースでは、

S3 Intelligent-Tieringだから
必ず大きく削減できる

とは判断しません。

オブジェクトサイズと個数も確認します。

7. Intelligent-TieringのArchive階層を区別する

S3 Intelligent-Tieringには、通常の低レイテンシー階層に加えて、非同期アクセスを許容するデータ向けのアーカイブ階層もあります。

代表的には、

Archive Access
Deep Archive Access

です。

Archive Accessは、設定するとアクセスされていないオブジェクトをより低コストなアーカイブ階層へ移せます。

Deep Archive Accessは、さらに長期間アクセスされていないデータ向けです。

これらは、

即座にGETできる階層

ではありません。

必要なオブジェクトを使用するときは復元が必要です。

したがって、

Intelligent-Tiering
=
すべての階層で即時アクセス

とは考えません。

8. S3 GlacierはAccess FrequencyとRetrieval Latencyを組み合わせる

S3 Glacier系のストレージクラスでは、

どのくらいアクセスしないか

だけでなく、

アクセスするとき
どれだけ待てるか

が重要です。

S3 Glacier Instant Retrieval

低頻度
+
アーカイブ
+
ミリ秒アクセスが必要

なデータ向けです。

例えば、

四半期に1回程度
ただし要求されたら即時表示

というケースです。

S3 Glacier Flexible Retrieval

年に1〜2回程度
+
即時アクセス不要
+
分〜時間の復元を許容

するデータに適します。

S3 Glacier Deep Archive

年1回未満
+
長期保存
+
取得まで数時間待てる

ようなデータを評価します。

つまり、

Archive

という1種類の選択肢ではありません。

9. Minimum Storage Durationを無視しない

低コストのストレージクラスには、最小ストレージ期間が設定されているものがあります。

代表例は、

S3 Standard-IA
30日

S3 One Zone-IA
30日

S3 Glacier Instant Retrieval
90日

S3 Glacier Flexible Retrieval
90日

S3 Glacier Deep Archive
180日

です。

例えば、

45日後に必ず削除する

データを、

保存単価が低い

という理由だけでS3 Glacier Instant Retrievalへ置くと、90日の最小ストレージ期間による料金を考慮する必要があります。

したがって、

実際のRetention
<
Minimum Storage Duration

の場合は特に注意します。

10. 小さいオブジェクトでは移行コストが効きやすい

現在、新しく作成・更新するS3 Lifecycle設定では、デフォルトで、

128 KB未満

のオブジェクトはストレージクラス移行の対象になりません。

理由の1つは、小さいオブジェクトでは、

保存料金の削減

に対して、

オブジェクト単位の移行リクエスト

の影響が相対的に大きくなりやすいためです。

必要であればサイズフィルターを指定して128 KB未満を移行対象にすることはできます。

しかし、

設定できる
=
設定すべき

ではありません。

まず、

オブジェクト数
×
移行回数

と、

削減できる保存料金

を比較します。

11. Lifecycleでは「Transitionしない」選択もある

データに保存期限がある場合、

低コスト階層へ移す

だけでなく、

期限が来たら削除する

ことも重要です。

例えば、

法的・業務的に
365日だけ保存

であれば、

何年もDeep Archiveへ残す

必要はありません。

コスト最適化では、

Standard
↓
IA
↓
Glacier
↓
永久保存

という階段を必ず最後まで使うのではなく、

Retention終了
↓
Expiration

も含めて設計します。

最も安い保存データは、

保持要件が終わった後に
不要なのに保存しているデータ

を残さないことです。

12. Amazon EBSでは実行中VolumeとSnapshotを分ける

Amazon EBSのコストでは、

実行中EBS Volume

と、

EBS Snapshot

を分けます。

実行中ボリュームでは、

容量
IOPS
スループット

を需要に合わせる適正サイズ化が中心です。

一方、長期保存するバックアップについては、

EBS Snapshot Standard tier
vs
EBS Snapshots Archive

という階層化を評価できます。

ここでは、

ほとんど利用しない
長期保存スナップショット

の階層化を扱います。

13. EBS Snapshots Archiveは長期・低頻度アクセス向け

通常、EBSスナップショットはStandard tierへ保存されます。

Standard tierではスナップショットは増分です。

一方、

EBS Snapshots Archive

へアーカイブすると、

増分Snapshot
↓
Full Snapshot

へ変換されてArchive tierへ移動します。

Archive tierは、

90日以上保持
+
ほとんどアクセスしない
+
高速復元が不要

なスナップショットを評価する階層です。

代表例は、

プロジェクト終了時Snapshot
月次・四半期・年次Snapshot
長期コンプライアンス保存

です。

14. EBS Snapshot ArchiveではRestore Timeを確認する

Archive tierのEBSスナップショットは、そのままボリューム作成に使うのではなく、

Archive tier
↓
Restore
↓
Standard tier
↓
利用

という流れになります。

スナップショットサイズなどによっては、Archive tierからStandard tierへの復元に、

最大72時間

かかる場合があります。

そのため、

障害時に1時間以内で
このSnapshotから復旧したい

という要件に対して、

Archive tierだけに置く

設計は適しません。

ストレージ階層化では、

ストレージ料金

だけでなく、

必要な復元時間

もコストと交換条件になります。

15. EBS Snapshot Archiveでは「増分サイズのまま」と考えない

Standard tierのEBS Snapshotは増分です。

しかしArchive tierへ移すと、

Full Snapshot

になります。

したがって、

Standard tierで
今回の増分は20 GiB

Archive tierでも
20 GiBだけ保存

とは限りません。

アーカイブによるコスト効果を判断するときは、

Archive tierでのFull Snapshot size

と、

Standard tier側で
実際に削減される保存量

を比較します。

つまり、

ArchiveのGB単価が安い

という理由だけではなく、

何GBがArchive側で課金されるか

まで確認します。

16. ストレージ階層化の判断を統合する

例えば、次の3種類のデータがあるとします。

データA

アクセス頻度
予測不能

数か月後に
再び頻繁にアクセスする可能性あり

ミリ秒アクセス必須

候補：

S3 Intelligent-Tiering

データB

作成後30日は頻繁
その後はほぼアクセスなし

監査時は数時間待てる

7年間保存

候補：

S3 Lifecycle
↓
適切なS3 Glacier階層

データC

EBS Snapshot

1年以上保存

通常は使用しない

復元に最大72時間を許容

候補：

EBS Snapshots Archive

重要なのは、すべてを同じ「Cold Storage」として扱わないことです。

17. 代表的なアンチパターン

18. SAP-C02での判断フロー

データを何日・何年保持する？
        ↓

どのくらいの頻度でアクセスする？
        ↓

アクセス頻度は予測可能？
        │
        ├─ 不明・変化する
        │      ↓
        │   S3 Intelligent-Tieringを評価
        │
        └─ 予測可能
               ↓
           S3 Lifecycleを評価

        ↓

アクセスするとき
どのくらい待てる？
        │
        ├─ ミリ秒
        │    ↓
        │  Standard / IA /
        │  Glacier Instantなど
        │
        └─ 分〜時間
             ↓
           Flexible / Deep Archiveなど

        ↓

Minimum Storage Durationを満たす？
        ↓

Object Sizeは？
128 KB未満が大量？
        ↓

Transition / Retrieval /
Monitoring コストを含めても安い？
        ↓

Retention終了後は
削除できる？
        ↓

EBS Snapshotなら
長期・低頻度か？
        ↓

Restore最大72時間を許容？
        ↓

Archive時のFull Snapshot sizeを含め
総コストを比較

まとめ

ストレージ階層化では、

最も安いStorage Class

を探すのではありません。

まず、

Access Frequency
Predictability
Retrieval Latency
Retention
Object Size

を確認します。

アクセスパターンが明確なら、

S3 Lifecycle

で時間経過に応じた移行を設計できます。

アクセスパターンが不明・変化する場合は、

S3 Intelligent-Tiering

を評価します。

アーカイブでは、

Glacier Instant Retrieval
Glacier Flexible Retrieval
Glacier Deep Archive

を取得頻度と取得待ち時間から選択します。

さらに、

Minimum Storage Duration
Transition コスト
Retrieval コスト

も確認します。

Amazon EBSでは、長期保存しほとんど利用しないSnapshotについて、

EBS Snapshots Archive

を評価できます。

ただし、

ArchiveするとFull Snapshot
+
最小90日
+
Restore最大72時間

という条件があります。

最終的に、

保存単価
+
アクセス方法
+
保持期間
+
移行・復元条件

を合わせて、総コストが最も適切な階層を選びます。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional SAP-C02 Exam Guide — Task 2.6
• Amazon S3 — Understanding and managing Amazon S3 storage classes
• Amazon S3 — How S3 Intelligent-Tiering works
• Amazon S3 — Transitioning objects using Amazon S3 Lifecycle
• Amazon S3 — Understanding S3 Glacier storage classes for long-term data storage
• Amazon EBS — Archive Amazon EBS snapshots
• Amazon EBS — Considerations and limitations for archiving Amazon EBS snapshots
• Amazon EBS — Pricing and billing for archiving Amazon EBS snapshots
• AWS Well-Architected Framework — Lifecycle policies and storage cost optimization