S3の請求は"置き方"で変わる — アクセス頻度でストレージクラスを選び、ライフサイクルで自動的に寝かせる（と、どこで損するか）

S3に置いたログ、古いバックアップ、使われなくなった成果物。消すには惜しいけれど、毎月の請求はじわじわ膨らんでいないでしょうか。S3の請求額は、同じデータでも「置き方」で変わります。アクセス頻度に合わせてストレージクラス（保存場所の種類）を選び、ライフサイクル（自動で移行・削除するルール）で低頻度のクラスへ寝かせれば、眠っているデータのコストは下げられます。ただし「安いクラスに移せば常に得」とは限りません。本記事では、ストレージクラスの選び方、ライフサイクルによる自動化、そして安いクラスが裏目に出る落とし穴までを、現行（2026年6月時点）の公式仕様にそって整理します。料金レートは変動するため本文では金額を出しません。最新の料金・条件は公式の料金ページでご確認いただく前提で読み進めてください。

なぜS3は”置き方”でコストが変わるのか

S3には、用途の違ういくつかのストレージクラスが用意されています。どのクラスでもデータの耐久性は同じ（イレブンナイン＝99.999999999%の設計）ですが、保存単価・取り出しのしやすさ・可用性が違います。おおまかには、保存単価が安いクラスほど、取り出しに料金や時間がかかり、最低保存期間などの制約が付くという関係になっています。

つまりコストを下げる出発点は、データを「どれくらいの頻度でアクセスするか」で仕分けることです。毎日読むデータを高頻度向けのクラスに置き、ほとんど読まないバックアップを低頻度・アーカイブ向けのクラスへ移す。この仕分けと自動化が「置き方の設計」です。逆に、頻繁に読むデータを保存単価だけ見て深いアーカイブへ入れると、取り出しのたびに料金と待ち時間を払うことになります。まずはクラスの地図を押さえます。

ストレージクラスの地図 — どれを選ぶか

主要な7クラスを、アクセス頻度と取り出し要件で並べると次のようになります。具体的な金額はクラスごとに異なり変動もするため、ここでは区分のみを示します。

クラス	設計対象（アクセス頻度）	取り出し	設計可用性	AZ数	最低保存期間	最低課金サイズ
S3 Standard	高頻度（月1回超）	ミリ秒	99.99%	3以上	なし	なし
S3 Standard-IA	低頻度（月1回程度）	ミリ秒（取り出し料金あり）	99.9%	3以上	30日	128KB
S3 One Zone-IA	再作成可・低頻度	ミリ秒（取り出し料金あり）	99.5%	1（単一AZ）	30日	128KB
S3 Intelligent-Tiering	頻度が不明・変動	ミリ秒〜（自動振り分け）	99.9%	3以上	なし	なし
S3 Glacier Instant Retrieval	まれ（四半期1回程度）	ミリ秒（復元不要）	99.9%	3以上	90日	128KB
S3 Glacier Flexible Retrieval	アーカイブ（年1回程度）	分〜時間（要復元）	99.99%（復元後）	3以上	90日	40KB相当の追加
S3 Glacier Deep Archive	アーカイブ（年1回未満）	時間（要復元）	99.99%（復元後）	3以上	180日	40KB相当の追加

表の読み方はシンプルです。よく読むなら Standard、たまにしか読まない長期保管なら Standard-IA、ほぼ読まないアーカイブなら Glacier 系。頻度が読めない・変動するなら、後述の Intelligent-Tiering に任せる、という対応関係になります。

注意したいのが One Zone-IA です。これだけは単一のアベイラビリティゾーン（AZ＝データセンターのまとまり）にしか保存しないため、可用性が99.5%でAZ単位の物理障害に耐えません。再作成できるデータ（別ソースから復元可能なログの二次コピーなど）に限って使うクラスです。なお Express One Zone（超低遅延・単一AZ）、Reduced Redundancy（公式が非推奨と明記）、Outposts（オンプレミス向け）は選定を散らすため本記事では扱いません。

ライフサイクルで自動的に寝かせる

クラスを選んだら、次は「時間が経ったデータを自動で低頻度クラスへ移す／消す」設定です。これがライフサイクルです。1つのバケットに1つのライフサイクル設定を持ち、最大1,000ルールまで定義できます。各ルールはフィルタ（プレフィックスやタグ、オブジェクトサイズ）と、次のアクションの組み合わせです。

• Transition（移行）：経過日数などを条件に、別クラスへ移します。移行は Standard → IA → Glacier 系という一方向のウォーターフォールで、逆流はできません。
• Expiration（失効）：現行バージョンを失効させます。バージョン管理なしのバケットでは完全削除になります。
• NoncurrentVersionTransition / NoncurrentVersionExpiration：バージョニング有効時の旧バージョンを移行・削除します。NewerNoncurrentVersions で「最新のN世代は残す」指定もできます。
• AbortIncompleteMultipartUpload：失敗して途中で止まった分割アップロードの断片を中止・削除します（後述）。
• ExpiredObjectDeleteMarker：不要になった削除マーカーを除去します。

設定するうえで知っておきたい制約が3つあります。Standard-IA・One Zone-IA への移行は作成後30日の経過が必須で、「作成翌日にIAへ」はできません。移行は1オブジェクトにつき1リクエストとして課金されるため、大量の小さなオブジェクトを一斉に移すとリクエスト料金がかさみます。そして128KB未満のオブジェクトは、既定ではどのクラスにも移行されません（2024年9月以降の挙動）。小さすぎると移行コストが保存料金の節約を上回るためで、必要なら ObjectSizeGreaterThan などのフィルタで挙動を変えられます。

失効を設定したのに容量が減らない — 不完全マルチパートの断片

ここが見落とされがちな落とし穴です。大きなファイルは分割（マルチパート）アップロードで送られますが、途中で失敗すると、アップロード済みの断片がバケットに残り続け、保存料金を静かに食い続けます。やっかいなのは、通常の Expiration（失効）ではこの断片は消えないという点です。公式ドキュメントも「オブジェクト失効のライフサイクル設定は、不完全なマルチパートアップロードを削除しない」と明記しています。

そのため、断片を片付けるには専用の AbortIncompleteMultipartUpload アクションを別途設定する必要があります。「失効ルールを入れたのに容量や請求が思ったほど減らない」というときは、この設定が抜けていないかを最初に確認します。数日で中止するルールを1本入れておくだけで、見えない課金を防げます。

自分で決めるか、自動に任せるか（Intelligent-Tiering）

ライフサイクルで閾値を自分で決める代わりに、アクセスパターンに応じて自動でティアを動かしてくれるのが Intelligent-Tiering です。取り出し料金がなく、最低保存期間も最低課金サイズもありません。その代わりに、オブジェクト単位の監視・自動化料金（月額・少額）がかかります。

ティアは自動で動きます。Frequent Access（高頻度）から、30日アクセスがなければ Infrequent Access へ、90日アクセスがなければ Archive Instant Access へ移ります。Archive Instant Access もまだミリ秒でアクセスできるのがポイントです。さらに任意で、復元が必要な非同期のアーカイブ層を有効化することもできます。ただし128KB未満のオブジェクトは監視対象外で、自動ティアリングの恩恵は薄くなります。

手動ルールと自動のどちらを選ぶかの軸は明確です。

観点	自分でライフサイクルルール	Intelligent-Tiering
向く場面	アクセスパターンが読める	パターンが不明・変動する
取り出し料金	IA/Glacierでは発生	なし
最低保存期間	クラスごとに背負う	なし
追加で払うもの	なし（自分で設計）	オブジェクト単位の監視料金

読めるなら手動ルール、読めない・変動するなら自動（Intelligent-Tiering）。これが一次の判断軸です。オブジェクト数が極端に多い場合は監視料金の積み上がりにも目を向けます。

安いクラスにすれば常に得、ではない

ここが本記事の山場です。保存単価の安さだけで深いクラスへ移すと、別のところでコストや時間を払うことになります。代表的な4つを正直に押さえます。

(a) 最低保存期間の早期削除課金。 Standard-IA・One Zone-IA は30日、Glacier Instant/Flexible は90日、Deep Archive は180日という最低保存期間があります。この期間より前に削除・上書き・別クラスへ移行すると、残り期間分の保存料金が日割りで上乗せされます。短命なデータや頻繁に上書きするデータをIA/Glacierに入れると、この早期削除課金で逆に高くつきます。短命データは Standard のまま、または最低保存期間のない Intelligent-Tiering が安全です。

(b) 取り出し料金と遅延。 Glacier Flexible Retrieval と Deep Archive は、その場では読めず復元（restore）が必須です。復元中は、アーカイブ料金に加えて一時コピーの保存料金もかかる二重課金になります。取り出しオプションと所要時間の目安は次のとおりで、環境により前後します。

クラス	Expedited	Standard	Bulk
Glacier Flexible Retrieval	1〜5分（小容量の目安）	3〜5時間	5〜12時間（Flexibleは無料）
Glacier Deep Archive	利用不可	12時間以内	48時間以内

Deep Archive は高速取り出し（Expedited）が使えず、最速でも12時間です。時々ミリ秒で読みたいが頻度は低い、という用途なら、復元の要らない Glacier Instant Retrieval を検討します（取り出し料金は発生します）。

(c) 小さいオブジェクトのオーバーヘッド。 Standard-IA・One Zone-IA・Glacier Instant Retrieval には最低課金サイズ128KBがあり、128KB未満のオブジェクトも128KBとして課金されます。さらに Glacier Flexible・Deep Archive では、1オブジェクトあたり40KB相当のメタデータ（8KBはStandardレート、32KBはアーカイブレート）が上乗せされます。小さなファイルを大量にアーカイブすると、このオーバーヘッドで節約効果が消えます。公式も小さいファイルは束ねて（tarなどで）大きくしてからアーカイブクラスへ入れることを推奨しています。

(d) One Zone-IA の可用性。 単一AZのため保存単価は下がりますが、AZ障害でデータを失う可能性があります。再作成できるデータに限定するのが原則です。

これらは「安い保存単価」の裏側にある条件です。仕様値（最低保存期間・128KB・40KB・取り出し時間）は現行（2026年6月時点）のもので、料金レートも含め、最新の値は必ず公式でご確認ください。

まとめ — 見る、絞る、寝かせる

S3のコスト最適化は、次の3点に整理できます。

1. 見て、仕分ける：データをアクセス頻度で分け、頻度に合うクラスを選ぶ。
2. 自動で寝かせる：ライフサイクルで一方向に移行・失効させる。失効だけでは消えない不完全マルチパートは AbortIncompleteMultipartUpload で片付ける。
3. 安さの裏を確認する：最低保存期間・取り出し料金と遅延・小オブジェクトの課金を踏まえ、短命データや頻繁に読むデータは深いクラスへ入れない。

最初の一歩は「どこにコストがかかっているかを見る」ことです。費用の所在は Cost Explorer × Amazon Q で把握し、全体の最適化は AWS FinOps Agent のような仕組みで進められます。本記事はそのうえで「S3で具体的に削る」打ち手にあたります。ストレージは本記事のクラスとライフサイクルで、コンピュートは Graviton4 や Lambda SnapStart のように、リソースごとに最適化の入口が分かれます。S3を別の角度から使うテーマとしては S3 Vectors や オブジェクトへのビジネス文脈の付与 もあります。まずは置きっぱなしのバケットを1つ、アクセス頻度で見直すところから始めてみてください。

出典

• Amazon S3 ストレージクラスの理解と管理（docs）
• S3 Lifecycle によるオブジェクトの移行（docs）
• ライフサイクル設定要素（docs）
• アーカイブ取り出しオプションの理解（docs）
• Amazon S3 ストレージクラス（製品ページ）
• Amazon S3 の料金