※本記事にはアフィリエイト広告が含まれます。
S3のストレージクラスは、SAAの学習で名前と特徴を一通り覚える。ただ、実際にアップロードファイルやログ、バックアップの置き場所を決める段になると、「IAにすれば安くなるはず」と思って設定したライフサイクルが、小さいファイルばかりのバケットでは逆に割高になる、ということが起こりえる。
この記事では、AWS公式ドキュメントの比較表を日本語で組み直したうえで、料金表の単価だけでは見えない「最低保存期間」「最小課金サイズ」「128KB未満のオブジェクトのライフサイクル移行ルール」を整理する。記載はすべて確認日（2026-10-01）時点の公式ドキュメントに基づく。単価はリージョンや改定で変わるため、本文には金額を書かず、料金ページで確認すべき項目だけを示す。
結論：まず「サイズ・保存期間・アクセス頻度」の3つで絞る
- 迷ったらS3 Standard。アップロード時にクラスを指定しなければStandardになる既定のクラスで、最低保存期間も最小課金サイズもない
- アクセスパターンが読めないならIntelligent-Tiering。取り出し料金がない。ただし128KB未満のオブジェクトは監視されず、常に高頻度アクセス階層に置かれる
- 128KB未満が大半のデータ、30日以内に消すデータは、IA系・Glacier系に移すと最小課金サイズ・最低保存期間・移行リクエストの料金で割高になりうる
- アーカイブは、ミリ秒で読めるGlacier Instant Retrieval、数分〜数時間のFlexible Retrieval、数時間のDeep Archiveを、取り出しまで待てる時間で選ぶ
比較表：S3のストレージクラス（公式ドキュメントの値のみ）
公式ドキュメント「Comparing the Amazon S3 storage classes」の表を日本語にしたもの。耐久性・可用性は設計値（designed for）である。
| クラス | 想定用途 | 耐久性 | 可用性 | AZ数 | 最低保存期間 | 最小課金サイズ | その他 |
|---|---|---|---|---|---|---|---|
| S3 Standard | 高頻度（月1回より多い）・ミリ秒アクセス | 99.999999999% | 99.99% | 3以上 | なし | なし | なし |
| S3 Standard-IA | 長期保存・低頻度（月1回）・ミリ秒アクセス | 99.999999999% | 99.9% | 3以上 | 30日 | 128KB | GB単位の取り出し料金あり |
| S3 Intelligent-Tiering | アクセスパターンが不明・変化する | 99.999999999% | 99.9% | 3以上 | なし | なし | オブジェクト単位の監視・自動化料金あり。取り出し料金なし。128KB未満は監視されず常に高頻度階層 |
| S3 One Zone-IA | 再作成できる低頻度（月1回）データ | 99.999999999% | 99.5% | 1 | 30日 | 128KB | GB単位の取り出し料金あり。AZの喪失に耐えない |
| S3 Express One Zone | レイテンシ重視のアプリ向け（1桁ミリ秒） | 99.999999999% | 99.95% | 1 | なし | なし | 自分で選んだ単一AZに保存 |
| S3 Glacier Instant Retrieval | 四半期に1回程度アクセスするアーカイブ・ミリ秒アクセス | 99.999999999% | 99.9% | 3以上 | 90日 | 128KB | GB単位の取り出し料金あり |
| S3 Glacier Flexible Retrieval | 年1回程度アクセスするアーカイブ・取り出しは数分〜数時間 | 99.999999999% | 99.99%（復元後） | 3以上 | 90日 | なし（※40KBのメタデータが加算） | GB単位の取り出し料金あり。アクセス前に復元が必要 |
| S3 Glacier Deep Archive | 年1回未満のアーカイブ・取り出しは数時間 | 99.999999999% | 99.99%（復元後） | 3以上 | 180日 | なし（※40KBのメタデータが加算） | GB単位の取り出し料金あり。アクセス前に復元が必要 |
| Reduced Redundancy Storage | 重要でない高頻度データ（非推奨） | 99.99% | 99.99% | 3以上 | なし | なし | なし |
表の読み方で押さえておきたい点は2つある。1つめは、One Zone-IAとExpress One Zoneだけが、災害などによるAZの物理的な喪失に耐える設計になっていないこと。2つめは、Reduced Redundancy Storage（RRS）について、公式が「このクラスは使わないことを推奨する。S3 Standardのほうがコスト効率がよい」と明記していること。古い記事や教材でRRSを選択肢として見かけても、新規に選ぶ理由はない。
観点1：最低保存期間と最小課金サイズで「損する」パターン
Standard-IAとOne Zone-IAは、公式に「128KBより大きく、30日以上保存するオブジェクトに適している」と書かれている。128KB未満のオブジェクトは128KBとして課金され、30日より前に削除・上書き・別クラスへの移行をすると、通常のストレージ料金に加えて30日に満たない残り日数分が日割りで課金される。
Glacier系も同じ構造で、最低保存期間はInstant Retrievalが90日（最小課金サイズ128KB）、Flexible Retrievalが90日、Deep Archiveが180日。最低保存期間より前に別のクラスへ移すと残りの期間分が課金され、Flexible RetrievalとDeep Archiveでは期間内の削除・上書きに日割りの早期削除料金がかかる。
見落としやすいのが、Flexible RetrievalとDeep Archiveのメタデータである。アーカイブした1オブジェクトごとに40KBの追加メタデータが必要になり、内訳は次のとおり。
- 8KB：オブジェクト名などのメタデータ。S3 Standardの料金で課金される（アーカイブ済みオブジェクトをS3 APIでリアルタイムに一覧できるようにするため）
- 32KB：インデックスなどのメタデータ。移行先のGlacierクラスの料金で課金される（データの識別と復元に必要）
つまり、数KBのファイルを大量にDeep Archiveへ送ると、本体より上乗せされる40KBのほうが大きくなる。公式も、小さいオブジェクトをアーカイブする場合はこの料金を考慮し、多数の小さいオブジェクトを少数の大きいオブジェクトにまとめることを検討するよう書いている。ログなら日単位・月単位でtar.gzにまとめてから保存する、といった設計が選択肢になる。
観点2：ライフサイクルで移行するときの制約
移行は「下る方向」だけ（ウォーターフォール型）
ライフサイクルによる移行は、公式が「ウォーターフォールモデル」と呼ぶ一方向の流れで、サポートされる組み合わせは次のとおり。
- Standard → Standard-IA / Intelligent-Tiering / One Zone-IA / Glacier Instant Retrieval / Flexible Retrieval / Deep Archive
- Standard-IA → Intelligent-Tiering / One Zone-IA / Glacier Instant Retrieval / Flexible Retrieval / Deep Archive
- Intelligent-Tiering → 階層によって異なる（高頻度・低頻度階層からはOne Zone-IAとGlacier 3クラス、など）
- One Zone-IA → Flexible Retrieval / Deep Archive
- Glacier Instant Retrieval → Flexible Retrieval / Deep Archive
- Flexible Retrieval → Deep Archiveのみ
Deep Archiveからはライフサイクルで他のクラスに移せない。別のクラスに戻したい場合は、復元で一時コピーを作ってから、コピー操作でクラスを指定して上書きする必要がある。また、Express One Zoneが使うディレクトリバケットのライフサイクルは、有効期限切れ（削除）と未完了のマルチパートアップロードの中止だけをサポートし、移行はサポートしていない。
2024年9月の変更：128KB未満は既定で移行しない
2024年9月から、ライフサイクルの既定の動作として128KB未満のオブジェクトはどのストレージクラスにも移行されなくなった。それ以前の既定では、128KB未満でもFlexible RetrievalとDeep Archiveにだけは移行できた。理由として公式は、移行リクエストはオブジェクトごとに課金されるため、小さいオブジェクトでは移行コストが保存料金の削減分を上回りうる、と説明している。
運用中のバケットで注意したいのは、2024年9月より前に作った設定は、変更しない限り旧動作のままという点だ。ルールを作成・編集・削除すると、その設定の既定の動作が新しい動作に切り替わる。「ログ用のルールを少し直しただけなのに、小さいファイルがGlacierに移らなくなった」という変化は、この仕様で説明がつく。
小さいオブジェクトもあえて移したい場合の手段は2つある。
- ルールのフィルタで
ObjectSizeGreaterThan（最小サイズ）やObjectSizeLessThan（最大サイズ）を指定する。独自のフィルタは既定の動作より常に優先される PutBucketLifecycleConfigurationのリクエストでx-amz-transition-default-minimum-object-sizeヘッダーを指定する。値はall_storage_classes_128K（128KB未満はどのクラスにも移行しない）とvaries_by_storage_class（128KB未満もFlexible Retrieval・Deep Archiveには移行する）の2つ
逆に、大小のファイルが混在するバケットをGlacierに送る場合、公式はサイズフィルタで小さいオブジェクトを除外して移行リクエストの料金を抑えることを推奨している。
最低保存期間より前に次のクラスへ移す単一ルールは作れない
1つのライフサイクルルールの中で、最低保存期間を過ぎる前に次のクラスへ移す設定はできない。公式の例では、Glacier Instant Retrieval（最低90日）に4日後に移し、20日後にDeep Archiveへ移す、というルールは作れず、Deep Archiveへの移行は94日以降にする必要がある。ルールを2つに分ければ設定自体は可能だが、その場合は最低保存期間分の料金を払うことになる。
Glacierへの移行は非同期、課金はルールを満たした日から
Flexible Retrieval・Deep Archiveへの移行は非同期に行われ、ルールの日付と実際の移行日にずれが出ることがある。それでも、移行先クラスの料金・最低保存期間・40KBのメタデータ料金は、ルールの条件を満たした日から発生する。例外はIntelligent-Tieringへの移行で、こちらは物理的な移行が完了してから課金が変わる。
観点3：Intelligent-TieringとStandard-IAのどちらにするか
Intelligent-Tieringは、アクセス状況に応じてオブジェクトを自動で階層間に移す。階層と日数は次のとおり。
| 階層 | 移る条件 | 備考 |
|---|---|---|
| Frequent Access | アップロード・移行した直後 | 128KB未満は常にここ |
| Infrequent Access | 30日連続でアクセスなし | 自動 |
| Archive Instant Access | 90日連続でアクセスなし | 自動・ミリ秒アクセス |
| Archive Access | 最低90日連続でアクセスなし | オプトインで有効化。アクセス前に復元が必要 |
| Deep Archive Access | 最低180日連続でアクセスなし | オプトインで有効化。アクセス前に復元が必要 |
取り出し料金がないので、ときどき急にアクセスが増えるデータでも料金が跳ねにくい。その代わり、オブジェクト単位の監視・自動化料金がかかる。Archive AccessとDeep Archive Accessは、アプリが非同期（復元を待つ前提）でアクセスできる場合にだけ有効にするよう公式が注意している。Webアプリの画像のように、リクエストにすぐ応答する必要があるデータでは有効にしないほうがよい。
一方のStandard-IAは、比較表のとおり「月1回程度」のアクセスが想定で、取り出しごとにGB単位の料金がかかる。アクセス頻度が低いと分かっていて、サイズが128KBより大きく、30日以上残すデータならStandard-IA。頻度が読めない、または時期によって変わるならIntelligent-Tiering、という分け方が公式の記載と整合する。どちらが安いかの最終判断は、監視料金と取り出し料金をオブジェクト数・取り出し量で見積もって比べる。AWSはStandardとStandard-IAの判断材料としてStorage Class Analysisも用意している。
用途別のおすすめ（Webアプリの典型データで考える）
LaravelなどのWebアプリでS3に置く代表的なデータを4種類に分け、ここまでの公式の記載を当てはめると、選び方は次のようになる。
- ユーザーのアップロード画像：サイズもアクセスもまちまちで、すぐ表示できる必要がある。まずStandard、アクセスの偏りが読めないならIntelligent-Tiering（Archive Access系は有効にしない）。サムネイルのような128KB未満のファイルはIntelligent-Tieringでも高頻度階層のままなので、恩恵は元画像側に限られる
- アプリケーションログ：小さいファイルが大量にでき、一定期間で消すことが多い。30日以内に削除するならStandardのまま有効期限切れのルールで消すのが素直。長く残すなら、まとめて大きいファイルにしてからGlacier系へ送ると、40KBのメタデータと移行リクエストの料金を抑えられる
- DBダンプなどのバックアップ：公式は、再作成できない主コピー・唯一のコピーにはStandard-IA、AZ障害時に再作成できるデータやクロスリージョンレプリケーションの複製にはOne Zone-IAを推奨している
- 監査用の長期保管：年1回未満しか見ず、取り出しに数時間かかってよいならDeep Archive。最低180日の保存期間を前提に、保管期間のルールと合わせて設計する
金額で比べるときは、Amazon S3の料金ページで、使うリージョンの次の項目を確認する。ストレージ単価だけで比べると、この記事で挙げた「損するパターン」を見落とす。
- ストレージ料金（GB/月）
- リクエスト料金（PUT・GETなど）
- データの取り出し料金（IA系・Glacier系）
- ライフサイクルの移行リクエスト料金（オブジェクト数に比例）
- Intelligent-Tieringの監視・自動化料金（オブジェクト数に比例）
まとめ
ストレージクラスを選ぶ前に、次のチェックリストで「損するパターン」に当てはまらないかを確認しておきたい。
- 128KB未満のオブジェクトが大半ではないか（IA系・Glacier IRの最小課金サイズ、Intelligent-Tieringの監視対象外、移行リクエスト料金）
- 最低保存期間（IA系30日、Glacier IR・Flexible 90日、Deep Archive 180日）より前に消したり上書きしたりしないか
- Flexible Retrieval・Deep Archiveに小さいファイルを大量に送っていないか（1オブジェクト40KBの上乗せ）
- 2024年9月より前に作ったライフサイクル設定を編集して、128KB未満の扱いが変わっていないか
- 単一ルールで最低保存期間を無視した多段移行を組もうとしていないか
SAAではストレージクラスは「どれがどの用途か」を問われることが多いが、実務ではオブジェクトのサイズと保存日数まで見て初めてコストの判断ができる。資格の勉強法はAWS認定アソシエイト3冠の完全攻略ガイドと、AWS三冠を同日受験して全合格した勉強法と当日の話にまとめている。
S3やAWSの設計を体系的に学び直したい場合は、公式ドキュメントと並行して技術書を1冊手元に置いておくと、サービス間の関係を整理しやすい。
楽天市場で探したい場合はこちらから。
