先に要点
- Amazon S3 (Simple Storage Service) は AWS の オブジェクトストレージ。ファイルシステムではなく、「バケット」 という入れ物に 「オブジェクト(ファイル + メタデータ)」 を放り込む形で保管する。容量無制限、99.999999999%(イレブンナイン)の耐久性、API でいくらでも読み書きできる。
- 料金は ① 保存容量(GB/月) + ② リクエスト件数 + ③ 下りデータ転送 の3軸。保存単価は東京リージョンで約 $0.025/GB と驚くほど安い一方、下り転送が東京では $0.114/GB(最初の約10TB) と保存の4〜5倍効くのが落とし穴。CloudFront を前段に置くと配信単価が下がる。
- ストレージクラス でコストが大きく変わる。1TB を 「30日後に Standard-IA、180日後に Glacier」 へライフサイクルで自動移行すると、保存費は月 約$25 → 約$2.0 まで圧縮できる。「全部 Standard 放置」 が一番もったいない。
- セキュリティ事故の典型は バケットの誤公開。「ブロックパブリックアクセス」 を有効のまま使い、CloudFront + OAC 経由で読ませるのが現代の標準。S3 公開設定の落とし穴と OAC 移行 も併読推奨。
- S3 は ストレージという枠を超えて、データレイク・静的サイト・イベント駆動アーキテクチャの中核 として使われる。「AWS の構成図にとにかく S3 が出てくる」 のは、これが理由。
「AWS を触ると、なぜか必ず S3 が出てくる」 「バケットってなんで世界で一意なの?」 「S3 って結局どこからどこまで担当?」 ── S3 は AWS の基礎中の基礎ですが、「単なるファイル置き場」 で理解を止めるとあとで詰まりやすいサービスです。
実際には S3 は 保管 / 配信 / バックアップ / データ分析 / イベント起点 / 静的サイトの全部を兼ねる AWS の汎用ストレージ で、「ファイルシステムの代わり」 ではなく API でアクセスするスケール無制限のオブジェクト保管庫 と捉えるのが正確です。
この記事では、S3 の 仕組み・料金・ストレージクラス・セキュリティ・典型ユースケース を、「これから AWS で実務に入る人」 向けに、東京リージョン(ap-northeast-1)の実料金を交えて整理します。
S3 とは — 「オブジェクトストレージ」 とは何か
S3 は オブジェクトストレージ です。「ディレクトリ構造をもつファイルシステム」 とは仕組みが違います。
バケットとオブジェクト
「バケット」 が一番大きな入れ物で、世界で一意の名前を持つ。その中に 「オブジェクト(ファイル + メタデータ)」 をフラットに保管。path/to/file.png のような キー でアクセスするが、実体は階層構造ではなく単なる文字列。
ファイルシステムとの違い
ディレクトリ操作(mv や rm -rf)のような概念はなく、すべて HTTP API でオブジェクト単位の読み書き。一覧取得は LIST API でプレフィックス指定する。「サーバの中のファイル置き場」 ではなく ネットワーク越しのスケーラブルな保管庫。
容量無制限・1オブジェクト最大 5TB
バケット全体に 容量上限なし。個別オブジェクトは最大 5TB まで(マルチパートアップロード使用時)。「PB 級のデータレイク」 から 「数KB の設定ファイル」 まで同じ仕組みで扱える。
ファイルシステムのつもりで S3 を使うと、「mv が無い」 「フォルダの一括操作が遅い」 で詰まるのが典型パターンです。「HTTP API でアクセスする保管庫」 と捉え直すと運用設計が変わります。
料金構造 — 何にいくらかかるのか
S3 の料金は 3軸 で考えます。以下は東京リージョン(ap-northeast-1)の代表的な単価です(2026年6月時点・USD。正確な最新値は必ず公式の料金ページで確認してください)。
| 課金軸 | 東京リージョンの目安単価 | 実務で効くポイント |
|---|---|---|
| ① 保存容量 | Standard 約 $0.025/GB・月(最初の 50TB)、Standard-IA 約 $0.019/GB、Glacier 系は 1/10 以下 | 容量が大きいほど クラス選択の効き目 が出る。後述のライフサイクルが効く軸 |
| ② リクエスト件数 | PUT 約 $0.0047/1,000件、GET 約 $0.00037/1,000件 | 1件あたりは微少だが、「数百万の小ファイル」 を扱うと無視できない額になる |
| ③ 下りデータ転送 | インターネット向けに 約 $0.114/GB(最初の約10TB/月)。最初の 100GB/月は無料 | もっとも油断しやすい。保存単価の4〜5倍。配信用途では CloudFront 経由が定石 |
注目すべきは 下り転送が保存単価より桁違いに高い 点です。東京では下り 1GB が約 $0.114 で、同じ 1GB を 1ヶ月保存する費用(約 $0.025)の 約4.5倍。つまり 「1回配信するたびに、4.5ヶ月分の保存料が飛ぶ」 イメージです。
下り転送で請求が膨らむシナリオ(東京リージョン)
「保存単価が安いから配信もそのまま S3 で」 と始めると、人気が出た瞬間に請求が跳ねます。1ファイル 5MB の画像/動画クリップを S3 から直接インターネット配信した場合の概算です(最初の 100GB 無料分を考慮、$0.114/GB で計算)。
| 月間ダウンロード数 | 下り転送量 | S3 直接配信の下り料金(概算) |
|---|---|---|
| 1万回 | 約 50GB | 無料枠内(0GB 課金)= 約 $0 |
| 10万回 | 約 500GB | (500 − 100)GB × $0.114 ≈ 約 $46(約7,000円) |
| 100万回 | 約 4.9TB | 約 4,800GB × $0.114 ≈ 約 $547(約8万円) |
| 1,000万回 | 約 49TB | 約 49,000GB × $0.114 ≈ 約 $5,580(約84万円) |
同じ 49TB を保存しているだけなら月 約 $1,250 ですが、配信すると下りだけで約 $5,580 ── 保存の4倍以上が転送費です。CloudFront を前段に挟む と、S3→CloudFront 間(オリジンフェッチ)の転送が無料になり、CloudFront からの配信単価も東京で約 $0.114/GB と同等以上ながらキャッシュヒットで オリジンへの GET リクエストと S3 下りを劇的に減らせる ため、結果的に総額が下がるのが現代の AWS の作法です。
ストレージクラスを使い分ける
S3 には用途別のストレージクラスがあり、「どのクラスに置くか」 で大きく料金が変わります。
「月に数回しか読まないが、読むときは即時必要」 なファイル向け。約 $0.019/GB・月と保存単価が安く、取り出しに約 $0.01/GB の取得料が発生。最低30日保存・128KB 最低課金サイズがある点に注意。「ログ集約」 「戻すこともあるバックアップ」 で活躍。
S3 Intelligent-Tiering
「アクセス頻度を AWS が自動判定してクラスを動かしてくれる」。何が読まれるか予測しづらいデータ に向く。少額の自動階層化監視料がかかるが、考えることが減る。
S3 Glacier 系
「数ヶ月〜数年残すアーカイブ」 向け。Glacier Flexible Retrieval は約 $0.0045/GB、Deep Archive は約 $0.002/GB と Standard の 1/10〜1/12。取り出しに時間(数分〜12時間)と料金がかかる。「コンプライアンス保管」 「古いログ」 で使う。
ライフサイクルで月いくら下がるか(1TB の例)
「まずは Standard」 で始めて、データが溜まったらライフサイクルルールで自動移行を組むのが現実的です。1TB(=1,024GB)を放置した場合と、自動階層化した場合の保存費を東京単価で比べると、効き目が一目でわかります。
| 状態 | クラス | 1TB あたり月額(保存のみ・概算) |
|---|---|---|
| 全部 Standard 放置 | S3 Standard($0.025/GB) | 約 $25.6 / 月 |
| 30日後に移行 | Standard-IA($0.019/GB) | 約 $19.5 / 月(約24%減) |
| 180日後に移行 | Glacier Flexible Retrieval($0.0045/GB) | 約 $4.6 / 月(約82%減) |
| 長期アーカイブへ | Glacier Deep Archive($0.002/GB) | 約 $2.0 / 月(約92%減) |
つまり 「30日後に Standard-IA、180日後に Glacier」 という2段のライフサイクルだけで、1TB あたり月 $25.6 → $4.6 へ約8割削減できます。100TB 規模なら 月 約$2,560 → 約$460 で、年間で約25万円(約$25,000 相当)の差です。設定は数分、後はルールが勝手に動くだけ。「ファイルサーバ感覚で全部 Standard 放置」 が一番もったいないパターンであることが数字でわかります。
なお移行時には少額の ライフサイクル移行リクエスト料金(オブジェクト1,000件あたり数セント〜)がかかるため、数KB の細かいオブジェクトを大量に移すと移行料が保存削減を上回ることがあります。「小さいオブジェクトはまとめてから移す/移さない」 と決めておくと安全です。
命名規約と運用ルールを最初に決める
バケットやオブジェクトの命名と運用ルールを プロジェクト開始時に1つ決めておく と、後からの事故・コスト膨張・棚卸し漏れを大きく減らせます。ここでは実務でそのまま使える叩き台を示します。
バケット命名規約
世界で一意なので、{org}-{env}-{purpose}-{region} 形式を推奨。例: acme-prod-assets-apne1 / acme-stg-logs-apne1。英小文字・数字・ハイフンのみ、ドットは TLS 証明書の都合で避ける。環境(prod/stg/dev)を必ず入れると 本番バケットを誤操作しにくい。
キー(プレフィックス)設計
LIST が遅くならないよう、{種別}/{年}/{月}/{日}/... のように 日付プレフィックスで分割する。例: logs/2026/06/13/app.log。1プレフィックスに数百万件を詰めると一覧・棚卸しが重くなる。
タグ付けルール
全バケットに Owner / Env / CostCenter / DataClass の4タグを必須化。コスト配分タグを有効にすれば請求を用途別に分解でき、「どのバケットが下り転送を食っているか」 を Cost Explorer で即特定できる。
運用ルール: 本番3点セット
本番バケットは バージョニング有効 + ライフサイクル設定済み + 監査ログ有効を満たさないと作らない、をチームルールにする。新規作成は IaC(CloudFormation / Terraform)経由のみとし、手動作成を禁止すると規約逸脱を防げる。
このうち 「prod を含むバケット名 + コスト配分タグ + ライフサイクル必須」 の3つだけでも先に決めておくと、「誰のバケットか分からない」 「気づいたら Standard で数十TB溜まっていた」 という典型トラブルがほぼ消えます。
公開設定の落とし穴
S3 で 最も事故が多いのが 「公開バケット」 です。これは AWS 全体でも有名なトラブルパターンで、企業の機密漏洩事故の典型。
事故の典型
「動作確認のため一時的に Public にした」 「IAM ポリシーで誰でも読めるバケットポリシーを書いた」 「ブロックパブリックアクセスを外したまま忘れた」 のいずれか。公開された途端、世界中のスキャナがすぐ発見する。
ブロックパブリックアクセスは ON のまま
新規バケットは ブロックパブリックアクセスが ON でデフォルト。「それを意図的に外す」 のは原則 NG。「Public で配信したい場合でも、CloudFront 経由にして S3 はプライベートのまま」 が定石。
CloudFront + OAC で配信する
「CloudFront に OAC(Origin Access Control)を持たせ、CloudFront からだけ S3 が読める」 構成にする。S3 を直接 URL で叩いても 403 になるので、誤公開リスクが激減。詳しくは S3 公開設定の落とし穴と OAC 移行。
監視で気付ける仕組みを入れる
AWS Config の s3-bucket-public-read-prohibited ルールや、Macie で機密データの自動検出を仕掛ける。「人間が見張る」 ではなく 設定変更があったら通知 の仕組みを使う。
バージョニングとライフサイクル
「誤って消した・上書きした」 を救うのがバージョニング、「古いものを安く / 自動で消す」 のが ライフサイクル。前章の数値どおり、ライフサイクルは 放置との差が年間数十万円に効く運用設定です。
「バージョニング + ライフサイクル + 監査ログ」 の3点セットは 本番運用バケットの最低ライン と考えると安全です。
典型ユースケース
S3 が 「AWS の中核」 と呼ばれるのは、これだけ違う用途で同じ仕組みが使えるためです。
アプリのアセット配信
「画像、CSS、JS、ダウンロード資料」 を保管し、CDN(CloudFront)経由で世界配信。SPA / Next.js 静的書き出しの定番ホスティング。前述のとおり下り転送の観点でも CDN を被せる価値が大きい。
データレイク
「構造化・非構造化を問わずデータを S3 にためる」 → Athena / Glue / EMR / Redshift Spectrum で分析。どんなデータ形式でも入る ことで、後からの分析の柔軟性が高い。
Amazon S3 に関するよくある質問
Q. S3 と EFS / EBS はどう違いますか?
A. 役割と接続形態が違います。EBS は EC2 にアタッチするブロックストレージ(ハードディスク的)、EFS は 複数 EC2 から同時マウントできる NFS、S3 は HTTP API でアクセスするオブジェクト保管庫。「OS から見えるディスク」 が要るなら EBS、「複数台で共有するファイルシステム」 が要るなら EFS、「API でアクセスする保管庫」 なら S3、と用途で分けます。
Q. バケット名はなぜ世界で一意?
A. S3 は HTTPS でグローバルにアクセスできる仕組み で、bucketname.s3.amazonaws.com のような URL でアクセスするためです。DNS 名前空間として世界共通なので、別アカウントが同じ名前のバケットを持つことはできません。本記事で示した {org}-{env}-{purpose}-{region} のような命名で衝突と誤操作を避けるのが定石です。
Q. S3 にファイルを置いたら自動的に世界中に複製されますか?
A. 同じリージョン内の複数 AZ には自動複製されます(これが 11ナインの耐久性の根拠)。別リージョンへの複製は明示的に Cross-Region Replication (CRR) を設定する必要があります。「ディザスタリカバリ目的でリージョン跨ぎの冗長化」 をするときに CRR を使います。なお CRR ではリージョン間転送料金が別途かかる点に注意してください。
Q. S3 の料金で一番気を付けるべきは?
A. 下りデータ転送料金 が圧倒的に効きます。東京では下りが約 $0.114/GB で、保存単価($0.025/GB)の約4.5倍。本記事の試算どおり、5MB のファイルが月100万ダウンロードされると下りだけで 約8万円、1,000万なら 約84万円に達します。「CloudFront 経由にする」 「Price Class を絞る」 「配信地域を限定する」 で対策します。
Q. ライフサイクルでどのくらい安くなりますか?
A. 1TB あたり、Standard 放置の月 約$25.6 が、Glacier 移行後は月 約$4.6(約8割減)、Deep Archive なら 約$2.0(約9割減)まで下がります(東京単価・保存のみの概算)。「30日後に Standard-IA、180日後に Glacier」 の2段ルールが定番です。ただし IA / Glacier には 最低保存日数(30日〜90日)と取り出し料金があるため、頻繁に読み戻すデータには逆効果になることがあります。
Q. ストレージクラスを後から変えられますか?
A. 変えられます。「手動でコピー時にクラス指定」 「ライフサイクルルールで自動移行」 のどちらでも可能。ただし クラスごとに最低保持期間(Standard-IA は30日など)があり、期間内に消すと残り日数分が課金されるため、「頻繁に行き来する」 用途には向きません。「置いてしばらく経ったら IA、長期は Glacier」 のような 一方通行の流れ で設計するのが定石です。
Q. オブジェクトの一覧取得が遅いんですが?
A. S3 は LIST API でプレフィックス指定して取得 する仕組みで、ディレクトリ概念がないため 大量オブジェクトの全件取得は時間がかかります。「日付プレフィックスで分割して取る」 「S3 Inventory(日次の一覧レポート)を使う」 「Athena でメタデータをクエリ」 のいずれかで回避します。「毎リクエストで全件 LIST」 のアプリ設計は避けるべきです。
Q. 静的サイトホスティングは S3 だけで完結しますか?
A. 動くには動きますが、本番では CloudFront を被せるのが標準です。S3 単体だと 「HTTPS が制限あり」 「カスタムドメイン + 無料証明書が組みづらい」 「世界配信が遅い」 「公開設定事故が起きやすい」。CloudFront を前段に挟むと、これらが全部解決します。
まとめ
Amazon S3 は AWS の基本ストレージ という肩書を超えて、配信・バックアップ・データレイク・イベント起点まで担う 汎用ストレージ基盤 です。
「容量無制限 + 11ナイン耐久 + 安い保存単価」 という強みを活かしつつ、下り転送(東京 $0.114/GB)・公開設定・一覧取得の遅さという落とし穴を知り、ライフサイクルで保存費を8〜9割削り、命名規約・タグ・本番3点セットの運用ルールを最初に決めておく ことで、設計とコストの両面で選択肢がぐっと広がります。「AWS を本格的に使うなら、S3 を一度きちんと理解する」 ことが、他サービスの理解を加速させる最短ルートです。
参考リンク
- AWS: Amazon S3
- AWS Docs: Amazon S3 User Guide
- AWS: S3 Pricing
- AWS Docs: Storage Classes
- AWS Docs: Managing your storage lifecycle
- AWS Docs: Blocking public access to your Amazon S3 storage
- AWS Docs: Bucket naming rules