先に要点
- Amazon S3 (Simple Storage Service) は AWS の オブジェクトストレージ。ファイルシステムではなく、「バケット」 という入れ物に 「オブジェクト(ファイル + メタデータ)」 を放り込む形で保管する。容量無制限、99.999999999%(イレブンナイン)の耐久性、API でいくらでも読み書きできる。
- 料金は ① 保存容量(GB/月) + ② リクエスト件数 + ③ 下りデータ転送 の3軸。「保存単価は驚くほど安い」 が、「 下り転送」 が想像以上に効く のが落とし穴。CloudFront を前段に置くと配信単価が下がる。
- ストレージクラス でコストが大きく変わる。「高頻度アクセスは Standard、低頻度は Standard-IA、バックアップは Glacier 系」 と用途で使い分けるのが基本。「 全部 Standard」 のままだと無駄が出る。
- セキュリティ事故の典型は バケットの誤公開。「ブロックパブリックアクセス」 を有効のまま使い、CloudFront + OAC 経由で読ませるのが現代の標準。S3 公開設定の落とし穴と OAC 移行 も併読推奨。
- S3 は 「 ストレージ」 という枠を超えて、データレイク・静的サイト・イベント駆動アーキテクチャの中核 として使われる。「AWS の構成図にとにかく S3 が出てくる」 のは、これが理由。
「AWS を触ると、なぜか必ず S3 が出てくる」 「バケットってなんで世界で一意なの?」 「S3 って結局どこからどこまで担当?」 ── S3 は AWS の基礎中の基礎ですが、「単なるファイル置き場」 で理解を止めるとあとで詰まりやすいサービスです。
実際には S3 は 「 保管 / 配信 / バックアップ / データ分析 / イベント起点 / 静的サイト」 の全部を兼ねる AWS の汎用ストレージ で、「ファイルシステムの代わり」 ではなく API でアクセスするスケール無制限のオブジェクト保管庫 と捉えるのが正確です。
この記事では、S3 の 仕組み・料金・ストレージクラス・セキュリティ・典型ユースケース を、「これから AWS で実務に入る人」 向けに整理します。
S3 とは — 「オブジェクトストレージ」 とは何か
S3 は オブジェクトストレージ です。「ディレクトリ構造をもつファイルシステム」 とは仕組みが違います。
バケットとオブジェクト
「 バケット」 が一番大きな入れ物で、世界で一意の名前 を持つ。その中に 「オブジェクト(ファイル + メタデータ)」 をフラットに保管。「/path/to/file.png」 のような キー でアクセスするが、実体は階層構造ではなく単なる文字列。
ファイルシステムとの違い
「 ディレクトリ操作 (mv、rm -rf) 」 のような概念はなく、すべて HTTP API でオブジェクト単位の読み書き。一覧取得は 「LIST API」 でプレフィックス指定する。「サーバの中のファイル置き場」 ではなく ネットワーク越しのスケーラブルな保管庫。
容量無制限・1オブジェクト最大 5TB
バケット全体に 容量上限なし。個別オブジェクトは最大 5TB まで(マルチパートアップロード使用時)。「PB 級のデータレイク」 から 「数KB の設定ファイル」 まで同じ仕組みで扱える。
`ファイルシステムのつもりで S3 を使うと、「mv が無い」 「フォルダの一括操作が遅い」 で詰まる」 のが典型パターンです。「HTTP API でアクセスする保管庫」 と捉え直すと運用設計が変わります。
料金構造 — 何にいくらかかるのか
S3 の料金は 3軸 で考えます。
| 課金軸 | イメージ | 実務で効くポイント |
|---|---|---|
| ① 保存容量 | GB / 月 × ストレージクラスの単価 | Standard は約 $0.023/GB(東京)、Glacier 系は 1/10 以下。容量が大きいほど クラス選択の効き目 が出る |
| ② リクエスト件数 | PUT/GET/LIST などの操作回数で課金 | 1件あたりは微少だが、「大量の小ファイル」 を扱うと意外な額になる |
| ③ 下りデータ転送 | S3 からインターネットへ出る GB 数 | もっとも油断しやすい。「配信用に S3 を使う」 だと膨らみやすい。CloudFront 経由で単価を下げるのが定石 |
「保存単価は安いから安心」 と思って始めて、配信トラフィックで請求が伸びた という事故が多発します。配信用途では CloudFront を必ず前段に挟む のが現代の AWS の作法です。
ストレージクラスを使い分ける
S3 には用途別のストレージクラスがあり、「どのクラスに置くか」 で大きく料金が変わります。
「 月に数回しか読まないが、読むときは即時必要」 なファイル向け。Standard より 保存単価が安く、取り出し単価が発生。「ログ集約」 「バックアップから戻すこともある」 用途で活躍。
S3 Intelligent-Tiering
「 アクセス頻度を AWS が自動判定してクラスを動かしてくれる」。何が読まれるか予測しづらいデータ に向く。少額の自動階層化料金がかかるが、考えることが減る。
S3 Glacier 系
「 数ヶ月〜数年残すアーカイブ」 向け。保存単価が Standard の 1/10 以下、ただし取り出しに時間と料金がかかる。「コンプライアンス保管」 「ビデオの長期保管」 「古いログ」 で使う。
「 まずは Standard」 で始めて、ある程度データが溜まったら ライフサイクルルール で 「30日後に IA、180日後に Glacier」 のように自動移行を組むのが現実的です。「ファイルサーバ感覚で全部 Standard 放置」 が一番もったいないパターン。
公開設定の落とし穴
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、ダウンロード資料」 を保管し、CloudFront 経由で世界配信。SPA / Next.js 静的書き出しの定番ホスティング。
データレイク
「 構造化・非構造化を問わずデータを 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 名前空間として世界共通 なので、別アカウントが同じ名前のバケットを持つことはできません。「organization-prefix-purpose」 のような命名で衝突を避けるのが定石です。
Q. S3 にファイルを置いたら自動的に世界中に複製されますか?
A. 同じリージョン内の複数 AZ には自動複製されます(これが 11ナインの耐久性の根拠)。「 別リージョンへの複製」 は明示的に Cross-Region Replication (CRR) を設定する必要があります。「ディザスタリカバリ目的でリージョン跨ぎの冗長化」 をするときに CRR を使います。
Q. 静的サイトホスティングは S3 だけで完結しますか?
A. 動くには動きますが、本番では CloudFront を被せるのが標準です。S3 単体だと 「HTTPS が制限あり」 「カスタムドメイン + 無料証明書が組みづらい」 「世界配信が遅い」 「公開設定事故が起きやすい」。CloudFront を前段に挟むと、これらが全部解決します。
Q. S3 の料金で一番気を付けるべきは?
A. 下りデータ転送料金 が圧倒的に効きます。「保存単価は安い」 と思って配信用途に使うと、人気コンテンツが当たった瞬間に 数十万円の請求 になることもあります。「CloudFront 経由にする」 「Price Class を絞る」 「配信地域を限定する」 で対策します。
Q. ストレージクラスを後から変えられますか?
A. 変えられます。「手動でコピー時にクラス指定」 「ライフサイクルルールで自動移行」 のどちらでも可能。「 1日経ってからしか変えられない」 などの最低保持期間 がクラスごとにあるので、「頻繁に行き来する」 用途には向きません。「置いてしばらく経ったら IA、長期は Glacier」 のような 一方通行の流れ で設計するのが定石。
Q. オブジェクトの一覧取得が遅いんですが?
A. S3 は LIST API でプレフィックス指定して取得 する仕組みで、「ディレクトリ」 概念がないため 「 大量オブジェクトの全件取得」 は時間がかかります。「プレフィックスで分割して取る」 「S3 Inventory(日次の一覧レポート)を使う」 「Athena でメタデータをクエリ」 のいずれかで回避します。「毎リクエストで一覧」 のアプリ設計は避けるべきです。
まとめ
Amazon S3 は AWS の基本ストレージ という肩書を超えて、配信・バックアップ・データレイク・イベント起点まで担う 汎用ストレージ基盤 です。
「容量無制限 + 11ナイン耐久 + 安い保存単価」 という強みを活かしつつ、下り転送 / 公開設定 / 一覧取得の遅さ という落とし穴を知っていれば、設計の選択肢がぐっと広がります。「AWS を本格的に使うなら、S3 を一度きちんと理解する」 ことが、他サービスの理解を加速させる最短ルートです。
参考リンク
- AWS: Amazon S3
- AWS Docs: Amazon S3 User Guide
- AWS: S3 Pricing
- AWS Docs: Storage Classes
- AWS Docs: Blocking public access to your Amazon S3 storage