Amazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説

Amazon S3（Simple Storage Service）は、画像やログ、バックアップ、データレイク用のファイルを、容量の上限をほぼ気にせず預けられるAWSのオブジェクトストレージです。この記事では、バケット・オブジェクト・キーというデータモデル、11ナインと呼ばれる耐久性と強い整合性、S3標準からGlacierまでのストレージクラス、暗号化やバージョニングといったデータ保護機能、そしてストレージ量・リクエスト・転送で積み上がる料金モデルを一次情報で整理します。EBSやEFSといった他のストレージとの違い、S3を採用すべき条件と見送るべき場面の判断基準まで、実装者が基盤設計で迷う論点を具体的に示します。

まとめ：Amazon S3の仕組み・ストレージクラスと採用判断の要点

Amazon S3は、データをファイル階層ではなくオブジェクト単位でバケットに格納するオブジェクトストレージです。1つのオブジェクトは最大5TBまで扱え、複数のアベイラビリティゾーンへ冗長化することで設計上99.999999999%（イレブンナイン）の耐久性を確保します。2020年末以降はどの操作でも書き込んだ直後に最新の値を読めるため、整合性を気にした作り込みが要りません。用途に応じてS3標準・Intelligent-Tiering・標準-IA・Glacier系といったストレージクラスを選び、頻度の低いデータを安いクラスへ自動で移すライフサイクルでコストを抑えます。

料金はストレージ量にリクエスト数・データ転送アウト・取り出し料金が積み上がる構造で、アクセス頻度から逆算してクラスを選ぶのがコスト設計の起点です。ブロックデバイスが要るOSのボリュームやデータベースの保存先にはEBS、複数サーバーで共有するファイルシステムにはEFSが向き、S3はそれらとは用途が異なります。静的アセットの配信やバックアップ・アーカイブ、データレイクの土台にS3が効きます。迷う実装者は、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめてください。

Amazon S3の仕組みとオブジェクトストレージのデータモデル

S3を設計へ落とし込むには、まず「オブジェクトストレージはファイルサーバーとどう違うのか」を押さえます。ここを曖昧にすると、フォルダ構造やファイルロックを前提にした誤った使い方を作り込みかねません。AWSやクラウドの全体像から確認したい場合は、クラウドとは何か・AWSの仕組みを事業者向けに解説した記事が上位の入り口になります。

バケット・オブジェクト・キーというS3のデータモデルの基本構造

S3のデータは、入れ物であるバケットと、その中に格納するオブジェクトで構成されます。オブジェクトはデータ本体・メタデータ・一意のキー（名前）からなり、キーはバケット内で1つの値を指し示します。ファイルシステムのようなフォルダ階層は物理的には存在せず、「logs/2026/07/access.log」のようにスラッシュを含むキーで階層を表現しているだけです。バケット名はグローバルで一意である必要があり、作成したリージョンに紐づきます。この「階層に見えるがフラットなキー空間」という前提を理解しておくと、プレフィックスによる整理やアクセス制御の設計が組みやすくなります。

オブジェクトサイズの上限とマルチパートアップロードの実務的な扱い

1つのオブジェクトは0バイトから最大5TBまで格納でき、単一のPUTリクエストで送れるのは5GBまでです。それを超える大きなファイルや、ネットワークが不安定な環境からの転送では、オブジェクトを分割して並列に送るマルチパートアップロードを使います。分割送信は途中で失敗した部分だけを送り直せるため、大容量データの転送を安定させられます。逆に、細かなファイルを大量に扱う場合はリクエスト数が料金と性能に効いてくるため、ある程度まとめてから格納する設計が実務では有効です。

ブロックストレージ（EBS）・ファイルストレージ（EFS）との違い

S3はオブジェクトストレージで、OSからボリュームとしてマウントするブロックストレージのEBSや、複数サーバーで共有するファイルシステムのEFSとは役割が異なります。EBSはEC2インスタンスに接続してデータベースやOSの保存先に使い、EFSはNFSで複数のサーバーからマウントして共有します。ブロックストレージのEBSの仕組みや料金は、Amazon EBSとはの記事で確認できます。S3はHTTPベースのAPIでオブジェクトを読み書きするため、OSのファイルとして直接開くのではなく、アプリケーションやSDK経由でアクセスするのが基本です。EC2そのものの仕組みは、AWSの計算資源を扱う観点で別途整理すると使い分けが明確になります。

Amazon S3のストレージクラスと耐久性・データ整合性の設計前提

S3で次に押さえるのがストレージクラスの選択です。アクセス頻度と取り出しの速さ、そして単価のバランスから、データごとに置き場所を決めます。

S3標準からGlacierまでのストレージクラスと選び分けの起点

2026年7月時点で、頻繁に読むデータ向けのS3標準、アクセス頻度が読めないデータを自動で振り分けるIntelligent-Tiering、低頻度アクセス向けの標準-IAとOne Zone-IA、長期保管のためのGlacier Instant Retrieval・Glacier Flexible Retrieval・Glacier Deep Archive、そして低レイテンシを狙うS3 Express One Zoneといったクラスがあります。読む頻度が高いほど標準系、めったに読まないほどGlacier系という単価と取り出し速度のトレードオフで選びます。長期アーカイブに特化したGlacierの詳細な取り出しモードや料金は、別途専用の記事で深掘りする範囲です。

ライフサイクルポリシーによる自動階層移動とストレージコストの抑制

作成直後はよく読まれ、時間が経つほどアクセスされなくなるデータは、ライフサイクルポリシーで扱うと手間が減ります。「作成から30日で標準-IAへ、90日でGlacierへ移し、7年経過で失効させる」といったルールを定義しておけば、S3が自動でクラスを移し替え、不要になったオブジェクトを削除します。アクセスパターンが読みにくいデータは、Intelligent-Tieringに振り分けを任せる選択肢もあるでしょう。手動でクラスを付け替える運用は抜け漏れが出やすいため、保管方針をポリシーに落とし込んでおくと、コストを適正な水準へ寄せられます。

11ナインの耐久性と強い書き込み後読み取り整合性という設計前提

S3は複数のアベイラビリティゾーンにデータを冗長化することで、設計上99.999999999%（イレブンナイン）の耐久性を確保します。単一AZに閉じるOne Zone-IAだけは冗長先が1つのAZに限られるため、再作成できるデータに限って使うのが前提です。整合性については、2020年12月以降、新規オブジェクトの書き込み・上書き・削除のいずれでも、直後に最新の状態を読み取れる強い整合性を提供します。以前のような「書いた直後は古い値が返り得る」挙動を吸収するリトライ処理を作り込む必要はなく、アプリの実装を素直に組めます。数値や仕様は断定せず、AWS公式のドキュメントで対象リージョンと時点を実測して確定させてください。

Amazon S3のセキュリティ・データ保護機能と料金モデル

S3はデータの入れ物であるがゆえに、公開範囲の設定ミスが情報漏えいに直結します。アクセス制御・暗号化・保護機能を押さえたうえで、料金の積み上がり方を理解します。

ブロックパブリックアクセスとIAM・バケットポリシーによる権限設計

アクセス制御は、誰が何をできるかを定めるIAMポリシー、バケット単位で許可を書くバケットポリシー、そして意図しない公開を止めるブロックパブリックアクセスの3層で組みます。ブロックパブリックアクセスは既定で有効になっており、公開が必要な静的サイト用途などで明示的に解除しない限り、バケットが不用意に全世界へ開くことを防ぎます。原則は最小権限で、特定のIAMロールや同一AWSアカウント内からのみ読み書きを許可し、公開が要る配信物だけをCloudFrontなどの前段経由で出す設計が安全です。設定ミスによる公開はS3の代表的な事故要因のため、公開範囲は必ず二重で確認してください。

サーバーサイド暗号化とバージョニング・Object Lockによるデータ保護

保存データの暗号化は、2023年1月以降すべての新規オブジェクトで既定のサーバーサイド暗号化（SSE-S3）が適用されます。鍵の管理を細かく制御したい場合はKMS連携のSSE-KMS、自前の鍵を持ち込むSSE-Cという選択肢です。誤削除や上書きに備えるならバージョニングを有効化し、過去バージョンを残して復元できるようにします。改ざんや削除を一定期間禁じたい規制対応の要件では、書き込み後は変更できないObject Lock（WORM）が有効です。ここに同一・クロスリージョンのレプリケーションを組み合わせると、地理的な冗長化まで確保できます。

ストレージ・リクエスト・データ転送で積み上がるS3の料金モデル

S3の料金は、格納しているデータ量（クラス別のGB単価）、PUTやGETなどのリクエスト数、インターネット向けのデータ転送アウト、そしてIAやGlacierからの取り出し料金が積み上がる構造です。データ転送インと、同一リージョン内の多くのAWSサービスとの連携は原則無料のため、コストの主因はストレージ量とインターネットへの転送、取り出し料金になります。低頻度クラスはGB単価が安い一方で取り出し料金がかかるため、読む回数が多いデータを安易にIAへ移すとかえって割高になる点に注意します。アクセス頻度を見てクラスを選び、配信の多いデータはCDNでキャッシュして転送アウトを減らすのが基本の打ち手です。

Amazon S3を採用すべき条件と各サービス・派生機能との使い分け

ここでは判断を言い切ります。S3はオブジェクト単位の保管に強い反面、OSからマウントするボリュームや共有ファイルシステムの代わりにはなりません。自社システムのデータ置き場をどこにするかを、条件付きで見極めてください。

Amazon S3の採用が効くワークロードと要件の条件の見極め

採用が効くのは、書き込んだデータをアプリケーションやSDK経由でオブジェクトとして読み書きし、容量の上限を気にせず高い耐久性で預けたい、という条件が重なるときです。具体例は、Webサイトの画像・動画・CSSといった静的アセットの配信元、システムのバックアップやログの保管先、機械学習の学習データやデータレイクの土台、ユーザーがアップロードするファイルの受け皿が当てはまります。こうしたAWS上のストレージ基盤を自社に取り入れるなら、AWSを含むクラウドインフラ構築の相談窓口で、バケット設計や公開範囲、ストレージクラスとコストの妥当性を相談するとよいでしょう。

S3では向かない要件とEBS・EFSへ寄せるべき場面の切り分け

OSからボリュームとしてマウントしてデータベースを動かす、ファイルをその場で細かく上書きしながら扱う、といった要件はS3では向きません。ブロックデバイスが要るならEBS、複数サーバーで共有するファイルシステムが要るならEFS、という切り分けになります。S3はオブジェクト全体の入れ替えを前提にしたAPIで、ファイルの一部分だけを書き換える操作には設計上馴染まないためです。単純な保管単価だけを見てS3に寄せると、マウント前提のアプリで作り替えが発生しかねないため、アクセス方法（マウントかAPIか）を軸に選定してください。

S3を土台にする派生機能・関連サービスとの連携の全体の見取り図

S3のバケットは、そのままでも使えますが、周辺機能と組み合わせると守備範囲が広がります。テーブル形式のデータをSQLで扱いたいデータレイク用途では、S3上に構造化データの土台を用意するAmazon S3 Tablesの概要を解説した記事が参考になるでしょう。ブラウザからS3のオブジェクトをファイルのように操作したい場合は、Storage Browser for Amazon S3の機能を解説した記事が導入の手掛かりになります。生成AIのRAGやベクトル検索向けにベクトルデータを格納するなら、Amazon S3 VectorsをAI・RAG・検索で使う場面を整理した記事で、通常のS3との棲み分けを確認できます。まずは基礎となるS3のデータモデルとクラス設計を固め、要件に応じてこれらの派生機能を重ねる順序が実務的です。

よくある質問

Amazon S3の導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

Amazon S3とEBS・EFSはどう使い分ければよいですか？

アプリケーションからAPIでオブジェクトを読み書きし、容量上限を気にせず預けたいならS3、EC2にボリュームとしてマウントしてDBやOSの保存先に使うならEBS、複数サーバーで共有するファイルシステムが要るならEFSが基本の分岐です。S3はファイルの一部書き換えには馴染まないため、マウント前提の要件はブロック/ファイルストレージへ寄せます。アクセス方法を軸に選定してください。

S3のストレージクラスはどう選べばよいですか？

読む頻度が高いデータはS3標準、頻度が読めないデータはIntelligent-Tiering、めったに読まない低頻度データは標準-IA、長期保管はGlacier系という単価と取り出し速度のトレードオフで選びます。アクセスパターンが時間とともに変わるデータは、ライフサイクルポリシーで自動的にクラスを移すと、手作業なくコストを抑えられます。

S3のデータは公開されてしまう心配はありませんか？

ブロックパブリックアクセスが既定で有効になっているため、明示的に解除しない限りバケットが全世界へ公開されることはありません。原則は最小権限で、特定のIAMロールや同一アカウントからのみアクセスを許可します。公開が必要な配信物はCloudFrontなどの前段を経由させ、バケット直下は非公開に保つ設計が安全です。

S3の耐久性と整合性はどの程度ですか？

複数のアベイラビリティゾーンへ冗長化することで、設計上99.999999999%（イレブンナイン）の耐久性を確保します。単一AZに閉じるOne Zone-IAだけは冗長先が1つのため、再作成できるデータに限って使います。整合性は2020年末以降、書き込み・上書き・削除の直後に最新状態を読める強い整合性を提供し、古い値を吸収するリトライ処理は要りません。

S3の料金を抑えるにはどうすればよいですか？

アクセス頻度からストレージクラスを選び、頻度の下がるデータはライフサイクルで安いクラスへ移すのが基本です。細かいファイルはまとめてリクエスト数を減らし、配信の多いデータはCDNでキャッシュしてインターネット向けの転送アウトを削ります。低頻度クラスは取り出し料金がかかるため、読む回数が多いデータを安易に移さないよう注意してください。

関連記事

• クラウドとは？AWSとは何かを仕組み・料金・移行の判断まで解説：S3の前提となるクラウド・AWS全体像を事業者向けに整理した上位概念の記事
• Amazon S3 Tablesとは何か？その概要と基本概念：S3上にテーブル形式のデータレイクを構築するS3派生機能
• Storage Browser for Amazon S3の概要と基本機能の解説：ブラウザからS3をファイルのように操作するUI機能
• Amazon S3 VectorsをAI・RAG・検索で使う場面と導入事例：生成AI向けにベクトルデータを格納する別テーマのS3系サービス