使いすぎずにS3のストレージクラスを選ぶ方法

S3のコストが想定以上に膨らむ最大の要因は、ストレージクラスのGB単価だけで請求額全体を判断することだ。実際にはそうではない。実際のコストは、ストレージのGB・月に加え、リクエスト、移行、取り出し、転送を合算したものになる。

データの経年変化が分かっている場合は、スケジュールに従ってオブジェクトをStandard-IAまたはGlacierへ移行するLifecycleルールが適切なデフォルトだ。アクセスパターンが不明、または変化しているデータについては、AWSは「オブジェクトサイズや保持期間にかかわらず」S3 Intelligent-Tieringを推奨している。これはAmazon S3 Intelligent-Tieringでストレージコストを管理する方法によるとされている。どちらを選ぶにしても、指定可能な日付時点の最新のリージョン別料金に当てはめて計算するまでは意味がない。

コストを抑える主な施策、優先順位

1. まず全コストの計算式を作るうえで、ストレージクラスを比較する
2. 予測可能な経年変化と削除には、LifecycleルールでStandard-IAおよびGlacierへ移行する。
3. 予測不能または変化するアクセスのデフォルトにはIntelligent-Tieringを使う。
4. 数カ月から数年単位のアーカイブにはGlacier Flexible RetrievalおよびDeep Archiveを使う。ただし、復元の挙動をモデル化してから選ぶ
5. ストレージクラス以外のチェックリストを、高リクエスト、高転送、またはマルチリージョンのワークロードに適用する

コスト抑制手法の評価方法

各手法を、アクセスパターンの予測可能性への適合度、実際のオブジェクトサイズ分布におけるオブジェクト単位のオーバーヘッドへの影響、最低保存期間と移行経路の制約、ストレージ料金以外のコスト項目（リクエスト、転送、レプリケーション、暗号化、監視）をどこまでカバーできるか、そしてアクションが実際に実行されたことを検証し、支出を正しく振り分けるガバナンスツールが存在するかという5つの基準で評価した。

これらの基準はマーケティング上の主張ではなく、AWSが文書化しているサービスの仕組みに基づいている。AWSのドキュメントは、Lifecycle、Intelligent-Tiering、Glacierの挙動を正確に説明しているが、節約できる金額の独立したベンチマークではない。予算会議で示す具体的な節約額は、指定した日付時点の最新公開料金を使い、ワークロード固有のモデルで計算する必要がある。

ストレージクラスを選ぶ前にコストの計算式を作る

企業のS3支出は単一の項目ではなく、合計値だ。クラスごとのストレージのGB・月、リクエストコスト（PUT、COPY、LIST、GET、およびオブジェクト単位で課金されるLifecycle移行リクエスト）、取り出し料金（Glacier階層のBulkおよびExpeditedのGB料金とリクエスト料金。別々に計測される）、データ転送（インターネットへのアウトバウンド、インバウンド、EC2やその他のAWSリソースとのリージョン内転送。それぞれ別の使用タイプとして追跡される）、さらにIntelligent-Tieringの監視、S3 Inventoryの一覧、Multi-Region Access Pointsのルーティング、S3 Metadataの処理といったオプション機能が含まれる。AWSによると、これらはすべて使用状況レポートに個別の明細として表示される。Amazon S3のAWS請求・使用状況レポートを理解する。

Lifecycleの移行自体にはデータ取り出し料金はかからない。ただし、いずれのストレージクラスへの移行であっても、PUT、COPY、またはLifecycleによって開始された移動には、リクエストごとの取り込み料金が発生する。また、別のクラスへの移行は、ストレージクラスの料金に加えて、課金対象となる移行リクエスト1件として数えられる。オブジェクトのライフサイクルを管理するおよびAmazon S3 Lifecycleの問題をトラブルシューティングする。

何かを決める前に、まず自分で計算してみよう。代表的なバケットとして、平均2MBのオブジェクト1,000万個を3年間保持し、毎年5%を取り出すケースを想定する。そして、StandardからLifecycleでStandard-IA、さらにGlacier Flexible Retrievalへ移行する構成、Intelligent-Tieringをそのまま使う構成、Archive Accessを有効にしたIntelligent-Tieringの3通りで料金を算出する。AWSの料金ページから、リージョン別の最新のGB単価、リクエスト単価、取り出し料金を使い、取得した日付も記録する。料金は容量、契約期間、サポートレベルによって異なり、時間とともに変わるため、今四半期に確認していない数字は疑ってかかるべきだ。以下の比較表は、そのモデルに入力する仕組み上の数値を示している。

ステップ1：ストレージクラスを選ぶ前にデータを把握する

ストレージクラスのドロップダウンに触れる前に、オブジェクトを平均サイズ、アクセス頻度、保持要件で分類する。2024年9月以降、AWSのデフォルトのLifecycle動作では、128KB未満のオブジェクトがストレージクラスへ自動的に移行されなくなった。それ以前に作成された設定は、変更しない限り従来の動作を維持する。Amazon S3 Lifecycleを使ってオブジェクトを移行するによると、古いバケットを引き継いだ場合は、実際にどちらの動作が適用されているか確認しよう。

まずS3 Storage LensまたはS3 Inventoryを実行し、128KB未満の範囲にオブジェクトが何個あり、容量がどれだけあるかを確認する。AWSは重要性を明確に説明している。「小さなオブジェクトでは、移行コストがストレージの節約額を上回る可能性がある」からだ。移行リクエストは、オブジェクトのサイズがどれほど小さくても、オブジェクト単位で課金される。

バージョニングされたバケットとObject Lockの利用は分けて確認する。バージョニングが有効なバケットでは、現行バージョンを期限切れにしてもオブジェクトは削除されない。削除マーカーが作成され、削除マーカーもオブジェクトとして数えられる。これは「Amazon S3 Lifecycleの問題をトラブルシューティングする」に記載されている。対処しないままだと、ストレージ量とリクエスト数が際限なく膨らむ。以前のバージョン、期限切れの削除マーカー、不完全なマルチパートアップロードを削除するため、2つ目のLifecycleルールが必要になる。

ステップ2：移行先のストレージクラスを選ぶ

実際に受け入れられる最低利用期間にクラスを合わせる。Standard-IAとOne Zone-IAは、安定していてアクセス頻度が低い予測可能なデータに適しており、最低30日間の利用が必要だ。Glacier Instant RetrievalとFlexible Retrievalは、最低90日間のアーカイブに適している。Glacier Deep Archiveは、最低180日間の複数年にわたるコールドストレージ向けだ。

Glacier Flexible RetrievalとDeep Archiveは、数カ月から数年にわたってアーカイブするデータのストレージコストを大幅に削減できる。ただし、Amazon S3 Lifecycleを使ってオブジェクトを移行する場合、「リアルタイムでは利用できない」。データに触れるには、その前に一時コピーを復元する必要がある。また、移行経路は一方向だ。Flexible RetrievalからDeep Archiveへは移行できるが、Lifecycleを使ってDeep Archiveを別のクラスへ戻すことはできない。ここを誤ると、コールドデータが復元プロセスの背後に固定され、自動的に戻す手段がなくなる。

アクセスが本当に予測不能な場合は、単なるスケジュール設定の省力化ではなく、ストレージクラスそのものとしてIntelligent-Tieringを選ぶ価値がある。Intelligent-Tieringは、低レイテンシの3つの階層を自動的にまたぎ、取り出し料金も、自身の階層間の移動に対する追加料金もかからない。さらに、数分から数時間でアクセスできればよいデータ向けに、オプションのArchive AccessおよびDeep Archive Access階層も利用できる。「Amazon S3 Intelligent-Tieringでストレージコストを管理する方法」およびS3 Intelligent-Tieringの利用 - Amazon Simple Storage Serviceによる。

ステップ3：自動化を選ぶ――LifecycleルールとIntelligent-Tieringの組み込み監視

Lifecycleはスケジュール設定の仕組みであり、それ自体がストレージクラスではない。定めた経過期間のスケジュール（例えば30日でStandard-IA、1年でGlacier Flexible Retrieval）に従って、Standard-IA、One Zone-IA、Intelligent-Tiering、または任意のGlacier階層を対象にできる。また、「オブジェクトのライフサイクルを管理する」にあるように、オブジェクトを自動的に期限切れにすることもできる。

Lifecycleルールの条件を満たした瞬間に請求上の変更が適用され、物理的な移動がまだ完了していなくても同様だ。覚えておくべき例外は2つある。Intelligent-Tieringへの移行では、オブジェクトが実際に移行されるまで請求は変わらない。Glacier階層への移行では、「Amazon S3 Lifecycleの問題をトラブルシューティングする」にあるように、オブジェクト単位の40KBオーバーヘッドと最低利用期間のカウントが、物理的な完了時ではなくルールの条件を満たした時点で始まる。最低利用期間のペナルティを避けるため早期に離脱するタイミングを計る場合、この違いが重要になる。

Intelligent-Tieringの組み込み監視は手動のスケジュール設定に取って代わるが、オブジェクト単位の監視・自動化に対する少額の月額料金が追加される。AWSはこの料金を「少額」としているが、オブジェクト数に応じて増えるため、小さなオブジェクトが数百万個あるポートフォリオでは、取り出し自体が無料でも監視コストが実際に発生し得る。もう1つ注意したい点として、タグベースのLifecycle評価は毎日実行され、ルールの更新が反映されるまで最大15分かかる。したがって、すでにキューに入った移行が、タグを削除したからといって直ちに停止するとは限らない。

ステップ4：アーカイブの取り出しと早期離脱の影響をモデル化する

最低利用期間のあるクラスを選ぶ前に、実際にどのくらいの頻度でデータを戻す必要があるのか、またどれほど急いでいるのかをモデル化する。Glacier Flexible RetrievalのBulkとExpeditedのリクエストはGB単位で別々に計測され、誤った取り出し速度の階層を選ぶと、請求額と待ち時間の両方が変わる。

クラスの最低利用期間より前に削除、上書き、移行を行うと、その期間の残りに対する按分料金が発生する。使用状況レポートでは、Standard-IAとOne Zone-IA（30日）、Glacier InstantおよびFlexible Retrieval（90日）、Deep Archive（180日）について、この料金が個別に追跡される。1回の早期復元で予測した節約額が消えるかどうかは、オブジェクトサイズ、離脱の早さ、取り出し量によって決まる。固定的な結果ではない。ベンダーの目立つ節約額を読むのではなく、自分で損益分岐モデルを実行して得る数字だ。

Glacierへの移行ではすべて、オブジェクト単位で40KBのオーバーヘッドも加わる。内訳はStandard料金で課金される8KBと、移行先のGlacier料金で課金される32KBだ。小さなオブジェクトが多数あるポートフォリオでは、このオーバーヘッドがストレージの節約額を完全に上回る可能性があるため、Lifecycleルールを適用する前に、より少数の大きなオブジェクトへまとめるようAWS自身が推奨している。

ストレージクラス以外のコスト――企業が見落とすチェックリスト

データ転送。使用状況レポートでは、インターネットへのアウトバウンド転送、インバウンド転送、EC2または同じリージョン内のその他のAWSリソースとのリージョン内転送が別々に追跡される。クロスリージョン転送とインターネットへのエグレスは、AWSネイティブのコスト計算ツールが軽視しがちな、最大の明細になることが多い。

Multi-Region Access Pointsとレプリケーション。リージョン内のバケットからMRAPエンドポイントを経由してルーティングされるデータと、AWSネットワーク外でリージョングループ間を転送されるデータは、基本ストレージとは別に課金・報告される。マルチリージョンのレジリエンスやコンプライアンスのアーキテクチャでは重要だが、ストレージクラスの料金だけをモデル化していると見落としやすい。

リクエストとメタデータの多いワークロード。S3 Batch Operationsのジョブ、S3 Inventoryの一覧、S3 Metadataの更新ごとの料金とアノテーションテーブルの処理データ、Intelligent-Tieringのオブジェクト単位の監視数は、すべて別々に計測される。データレイクやIoT取り込みのように、オブジェクト数と変更頻度が多いワークロードでは、ストレージクラス間の差額だけが全体像だと考える前に、これらを見積もるべきだ。SSE-KMSで暗号化されたオブジェクトは移行後も暗号化されたままだが、KMSリクエストごとにS3の請求とは別のコストが発生する。

比較表：ストレージクラス、最低利用期間、自動化との適合性

LifecycleとIntelligent-Tieringは競合する選択肢ではない。Lifecycleは、Standard-IA、One Zone-IA、Intelligent-Tiering、または任意のGlacier階層を対象にできる自動化の仕組みだ。一方、Intelligent-Tieringは階層化機能を組み込んだストレージクラスそのものだ。「S3 Intelligent-Tieringの利用」にあるように、バケットでLifecycleルールを使い、経年化したStandardオブジェクトをIntelligent-Tieringへ振り分けることも問題なくできる。

ガバナンス：タグ付け、コスト配分、Lifecycleアクションの実行確認

バケットタグの支出が請求レポートに表示されるよう、タグキーのレベルでコスト配分タグを有効化する。タグを適用してからコスト配分タグのページに表示されるまで最大24時間、その後有効化されるまでさらに最大24時間かかる。ユーザー定義のコスト配分タグを有効化する - AWS Billing。AWSによると、バケットのタグ付け自体には、標準的なS3 APIリクエスト料金以外の追加料金はかからない。S3汎用バケットでタグを使用する - AWSドキュメント。

Lifecycleアクションによる日々のストレージ変化を確認するには、CloudWatchメトリクスではなくS3 Storage Lensのダッシュボードを使う。AWSもCloudWatchよりStorage Lensを明確に推奨している。S3 Inventoryでオブジェクトが実際に入ったアクセス階層を確認し、S3 Event Notificationsで期限切れと移行のイベントを、サーバーアクセスログでも照合する。Lifecycleの移行と期限切れは非同期で行われるため、適格になってから実際のアクションが実行されるまで遅延する可能性が常にある。

AWS Service Catalog AppRegistryは、自動的に適用され、コストレポート用に自動有効化されるawsApplicationタグを、AWS Service Catalog AppRegistryアプリケーションに関連付けられたリソースへ自動的に追加する。アプリケーションの総支出を追跡するうえで実際に便利だが、意図的に設計したタグ分類体系の代わりではなく、利便性のためのレイヤーと考えるべきだ。無効化すると、自動的に再有効化されることはない。

選び方：ワークロードに合わせて手法を選ぶ

経年変化が分かっていて、明確な削除ポリシーがあり、オブジェクトサイズが128KBを十分に上回っているなら、スケジュールに従ってStandard-IA、次にGlacierへルーティングするLifecycleルールを使う。取り出しと早期離脱の影響について、自分の損益分岐モデルで検証することも必要だ。

アクセスが予測不能または変化している、オブジェクトサイズが混在している、あるいはデータレイクや分析パイプラインのような新規または実績のないワークロードを運用しているなら、デフォルトはIntelligent-Tieringにする。手動で誤った階層に振り分けるリスクへの保険として、オブジェクト単位の監視料金を受け入れる。

高リクエスト、高転送、マルチリージョン、または暗号化・レプリケーションの多いワークロードを運用しているなら、ストレージクラスを決定する前に、上記のストレージクラス以外のチェックリストをすべて実行する。転送、リクエスト、監視のコストが、ストレージクラス間の差額を完全に上回る可能性がある。他の項目が本当の問題なら、「正しい」ストレージクラスを選ぶだけでは解決できない。