S3ストレージクラスの解説：コスト最適化のための適切な選択肢

Amazon Simple Storage Service (S3) は、多くのAWSワークロードでデフォルトのオブジェクトストアとして使用されています。これは、スケーラビリティに優れ、さまざまなアクセスパターンに対応する複数のストレージクラスを提供するためです。しかし、すべてのデータが同じようにアクセスされるわけではありません。頻繁にアクセスされるミッションクリティカルなデータと、ほとんどアクセスされないアーカイブデータを同じクラスに保存すると、不必要で多額のクラウド費用が発生する可能性があります。さまざまなS3ストレージクラスの微妙な違いを理解することは、コスト最適化されたアーキテクチャを設計する上で非常に重要です。

S3の耐久性と可用性を理解する

各クラスを詳しく見る前に、S3の2つの主要な指標を定義することが重要です。

• 耐久性: データが時間の経過とともに無傷で維持される可能性。S3は、特定のクラスに使用されるインフラストラクチャ全体で**99.999999999%（イレブンナイン）**の耐久性を実現するように設計されています。
• 可用性: データが取得可能である時間の割合。通常は年間ベースで測定されます（例：99.9%）。

これらの指標は、選択する特定のストレージクラスによって多少異なります。

主要なS3ストレージクラス：詳細比較

AWSは、さまざまなアクセス頻度とダウンタイム許容度に最適化された、いくつかのストレージクラスを提供しています。以下に、最も一般的なオプションの詳細を示します。

1. S3 Standard

S3 Standardは、デフォルトの汎用ストレージクラスであり、頻繁にアクセスされるデータに最適です。

• ユースケース: アクティブデータ、コンテンツ配信、動的に生成されるコンテンツ、モバイル/ゲームアプリケーション。
• 耐久性: イレブンナイン。
• 可用性: 99.99%（高可用性）。
• 取得時間: ミリ秒。
• 料金: 頻繁にアクセスされるティアの中で最も高いストレージコストですが、取得料金はかかりません。

ベストプラクティス: 最小レイテンシで即座にアクセスする必要があるデータに使用します。

2. S3 Intelligent-Tiering (S3-IT)

S3 Intelligent-Tieringは、不明または変化するアクセスパターンのデータ向けに設計されています。使用状況に基づいてオブジェクトを2つ以上のアクセスティア間で自動的に移動し、運用オーバーヘッドなしでストレージコストを最適化します。

• ユースケース: データレイク、予測不能なアクセスパターンのデータ、または時間の経過とともにコストを最適化しながら即時アクセスを確保したい場合。
• 仕組み: アクセスを監視します。オブジェクトが30日間連続してアクセスされない場合、低頻度アクセス（IA）ティアに移動します。再度アクセスされると、高頻度アクセスティアに戻ります。
• 含まれるティア: 高頻度アクセス、低頻度アクセス、アーカイブインスタントアクセス（オプション）。
• コスト要因: オブジェクトごとに月額の少額の監視および自動化料金に加え、オブジェクトが存在するティアに応じて変化するストレージコストが含まれます。

実用的なヒント: データにアクセスされる頻度が不明な場合、S3 Intelligent-Tieringは、コスト削減とパフォーマンスの一貫性の間で最適なバランスを提供することがよくあります。

3. S3 One Zone-Infrequent Access (S3 One Zone-IA)

このクラスは、S3 Standard-IAと同様に、低頻度でアクセスされるが迅速な取得が必要なデータに最適ですが、可用性に大きな違いがあります。

• ユースケース: セカンダリバックアップ、再作成可能なデータ（例：ソースから再生成できるデータ）、またはマルチAZ冗長性を必要としないビジネスクリティカルではないデータの保存。
• 耐久性: イレブンナイン。
• 可用性: 99.5%（Standardよりも低い可用性）。
• 保存場所: データは、他のクラスが複数のAZにまたがるのとは異なり、**単一のAWSアベイラビリティゾーン（AZ）**内に冗長的に保存されます。
• コスト要因: Standardよりも大幅に低いストレージコストですが、データ取得には料金が発生します。

⚠️ One Zone-IAに関する警告: データは1つのAZにのみ存在するため、その特定のAZで壊滅的なイベント（例：大規模な停電や自然災害）が発生した場合、このティアのデータが失われる可能性があります。そのため、重要ではなく、簡単に置き換え可能なデータにのみ使用することが重要です。

4. S3 Glacierストレージクラス（アーカイブ）

Glacierストレージクラスは、数分から数時間の取得時間が許容される長期アーカイブ向けに最適化されています。

S3 Glacier Instant Retrieval (S3 Glacier IR)

これは、低頻度アクセスとディープアーカイブの間を埋めるものです。

• ユースケース: 四半期に1回以下のアクセスだが、必要なときにミリ秒単位の取得が必要なデータ（例：医用画像、ニュースメディアアーカイブ）。
• 取得時間: ミリ秒（IAクラスと同様のレイテンシ）。
• コスト要因: 非常に低いストレージコストと、取得料金。

S3 Glacier Flexible Retrieval (旧称 S3 Glacier)

これは、数分から数時間の取得が許容される場合の長期アーカイブオプションです。

• ユースケース: 規制コンプライアンスアーカイブ、めったに必要とされないディザスタリカバリデータ。
• 取得オプション（とレイテンシ）:
  • 迅速: 1～5分
  • 標準: 3～5時間
  • 一括: 5～12時間
• コスト要因: 非常に低いストレージコストですが、取得料金が発生し、時間がかかります。

S3 Glacier Deep Archive

AWS S3で最も低コストのストレージオプションです。

• ユースケース: 年に1～2回しかアクセスされない可能性があり、通常はコンプライアンスのために保存されるデータ。
• 取得オプション（とレイテンシ）:
  • 標準: 12時間
  • 一括: 48時間
• コスト要因: 利用可能な最低のストレージレート、最高の取得料金、および最も長い必要な取得時間。

選択方法：意思決定フレームワーク

適切なクラスを選択するには、データライフサイクルに関する3つの重要な質問に答える必要があります。

質問	主な考慮事項	推奨クラスパス
どのくらいの頻度でアクセスされますか？	アクセス頻度	頻繁 → Standard; 低頻度 → IA または Glacier
許容できるダウンタイム/データ損失は？	耐久性/可用性	重要 → Standard/Intelligent-Tiering; 使い捨て可能 → One Zone-IA
どのくらいの速さで取得する必要がありますか？	レイテンシ要件	ミリ秒 → Standard/Intelligent-Tiering/Glacier IR; 時間 → Glacier Flexible/Deep Archive

シナリオ例：企業のメディアアセット

マーケティングチームが毎日数百の生のビデオファイルをアップロードします。

1. 現在の編集/プロモーション（過去30日間）: S3 Standard（高アクセス、低レイテンシ）。
2. 時々レビューが必要な古いアセット（30日～1年）: S3 Intelligent-Tiering（初期のホット期間後のコスト削減を実現するため）。
3. 完了し監査済みの最終マスター（1年以上前）: S3 Glacier Deep Archive（最低コスト、コンプライアンス監査にのみ必要）。

シナリオ例：ログ、バックアップ、ユーザーアップロード

単一の企業は、多くの場合、3つの非常に異なるS3パターンを持っています。

アプリケーションログの場合、最近のデータはエンジニアがインシデント中に検索するため価値があります。インシデントの期間が過ぎると、ほとんどのログはコンプライアンスまたはトレンドデータになります。妥当なライフサイクルでは、30～90日間をStandardまたはStandard-IAに保持し、古いログをアーカイブティアに移動し、価値の低いデバッグログを一定の保持期間後に期限切れにします。正確な数値は、保持ポリシーと、人々が実際に古いプレフィックスをどのくらいの頻度でクエリするかによって決まります。

データベースバックアップの場合、ストレージクラスは復元の約束に従う必要があります。チームが本番復元を数分以内に開始する必要があると言った場合、最新のバックアップは即時取得可能なクラスに保持します。古い月次または年次のコピーは、迅速なリカバリではなく監査保持のために存在する場合、よりコールドなクラスに移動できます。選択したクラスからの復元をテストします。一度も復元されたことのないバックアップポリシーは、ほとんど単なる課金ルールです。

ユーザーアップロードの場合、アクセスは予測が困難です。プロフィール写真は小さくても常に取得される可能性があります。大きなオリジナルビデオは1回ダウンロードされ、トランスコードされ、その後ほとんど触れられない可能性があります。派生アセットとオリジナルは別々のプレフィックスの下に保存し、ライフサイクルルールで異なる扱いができるようにします。サムネイルポリシーが、製品が本当に必要としない限り、数ギガバイトのオリジナルと同じアーカイブルールを継承しないようにします。

バケットを変更する前に確認すべき質問

ライフサイクルルールを追加する前に、誰がデータを読み取り、どのように読み取り、取得が遅れた場合に何が起こるかを尋ねてください。エンジニアは、アップロードがアプリケーションの一部であるため、読み取りパスよりも書き込みパスをよく知っていることがよくあります。一方、読み取りは、分析、サポートツール、コンプライアンスエクスポート、または手動のインシデント対応を通じて後で発生します。

古いプレフィックスをスキャンするバッチジョブに注意してください。すべてのオブジェクトをリストし、メタデータを開き、古いファイルをサンプリングする夜間ジョブは、コールドなクラスによる節約の一部を消去する可能性があります。ジョブがマニフェストのみを必要とする場合、バケットを繰り返しリストするよりもS3 Inventoryの方が適している場合があります。アナリストがAthenaでログをクエリする場合、データを復元手順が必要なクラスに移動する前に、パーティション構成と圧縮を検討してください。

オブジェクトサイズに注意してください。最小請求可能オブジェクトサイズを持つストレージクラスは、非常に多数の小さなファイルには適さない場合があります。そのような場合、データをより大きなオブジェクトに圧縮する、分析にParquetを使用する、または不要なオブジェクトを期限切れにすることが、ストレージクラスの切り替えよりも効果的な場合があります。

最後に、インシデント中に説明できる方法でライフサイクルルールを作成します。archive-old-logs-after-90-days という名前のプレフィックスルールは、30日後にすべてを静かに移動するバケット全体のルールよりも推論が容易です。コスト最適化は、回復を不可解にすることなくシステムを安くする必要があります。

もう1つの実用的なチェックは、所有権です。実際のアカウントでは、バケット所有者、アップロードアカウント、レプリケーションロール、分析アカウントが常に同じであるとは限りません。データをアーカイブクラスに移動する前に、誰が復元でき、誰が取得料金を支払うかを確認してください。KMS暗号化を使用したクロスアカウントバケットは、オブジェクトを必要とするロールがバケットをリストできるがキーを使用できない場合、復元時に失敗する可能性があります。これは監査中の厄介な驚きです。

バージョニングも計算を変えます。ライフサイクルルールは、現在のバージョンと非現行バージョンを異なる方法で移行または期限切れにすることができます。アプリケーションが毎時間同じキーを上書きする場合、非現行バージョンがバケットの最大の部分になる可能性があります。現在のオブジェクト数が全体像を物語っていると想定せずに、それらを個別に確認してください。

ライフサイクルポリシーの実装

オブジェクトを手動でクラス間で移動するのは非効率的です。これらのティア間でコストを管理する最も効果的な方法は、S3ライフサイクルポリシーを使用することです。

ライフサイクルポリシーを使用すると、定義された日数が経過した後に、オブジェクトをよりコールドなストレージティアに自動的に移行したり、完全に期限切れにしたりするルールを定義できます。

ライフサイクルルールの例（移行）:

<Rule>
    <ID>Move_to_IA_After_30_Days</ID>
    <Status>Enabled</Status>
    <Filter>
        <Prefix>logs/</Prefix>
    </Filter>
    <Transition>
        <Days>30</Days>
        <StorageClass>GLACIER_IR</StorageClass>
    </Transition>
</Rule>

この設定により、logs/ プレフィックス内のオブジェクトは作成から30日後に自動的にGlacier Instant Retrievalに移動され、必要な場合に高速な取得機能を維持しながら、長期的なストレージコストを大幅に削減します。

見落とされがちなコストの落とし穴

ストレージクラスの決定は、単なる月間GB単価の比較だけではありません。取得料金、リクエスト料金、最小ストレージ期間、最小請求可能オブジェクトサイズ、レプリケーション、ライフサイクル移行リクエスト、監視料金によって結果が変わることがあります。数百万のキーを持つ小さなオブジェクトのアーカイブは、少数の大きなバックアップファイルとはまったく異なる動作をする可能性があります。

たとえば、アプリケーションログは一度書き込まれてほとんど読み取られないことが多いため、StandardからGlacier Instant RetrievalまたはGlacier Flexible Retrievalへのライフサイクルルールは理にかなっているかもしれません。しかし、インシデントプロセスで古いログをAthenaで頻繁にスキャンする場合、積極的なアーカイブは復元の遅延と予期しない取得コストを生み出す可能性があります。その場合、ログを日付でパーティション分割し、ノイズの多い価値の低いプレフィックスを期限切れにし、最近の数ヶ月をクエリに適したクラスに保持することで、30日後にすべてを盲目的にコールド化するよりも多くのコストを節約できる可能性があります。

バックアップは異なる形状を持っています。月に1回テストするデータベースダンプは、予測可能な復元動作を必要とします。復旧時間目標が数分で測定される場合、Deep Archiveは、保存中は安価であっても、復元可能な唯一のコピーを置く場所としてはおそらく適切ではありません。同じダンプが監査保持のためだけに保持される3番目のコピーである場合、Deep Archiveは妥当かもしれません。

メディアチームは、予測不能な方法で古いアセットを必要とすることがよくあります。Intelligent-Tieringは、特にオブジェクトが十分に大きく監視料金が決定要因にならない場合、これらの未知のパターンに対する適切なデフォルトになる可能性があります。多数の小さなサムネイルの場合、料金と最小オブジェクトサイズの動作は、どこでも有効にする前に詳しく調べる価値があります。

実用的な選択方法は、1つのバケットをサンプリングし、S3 Inventoryをエクスポートし、プレフィックス、オブジェクト数、合計バイト数、最終更新日、既知のアクセスパターンでグループ化し、プレフィックスごとにライフサイクルルールを作成することです。バケットに本当に1種類のデータしか含まれていない場合を除き、バケット全体のルールは避けてください。