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

S3とは、AWSが提供するオブジェクトストレージ「Amazon Simple Storage Service」の略称です。画像やログ、バックアップ、データレイク用のファイルを、容量の上限をほぼ気にせず預けられるサービスです。この記事では、バケット・オブジェクト・キーというデータモデル、1オブジェクト最大48.8TiBという現行の上限、4種類のバケット、11ナインと呼ばれる耐久性と強い整合性、S3標準からGlacierまでのストレージクラス、暗号化やバージョニングといったデータ保護機能、そしてストレージ量・リクエスト・転送で積み上がる料金モデルを、AWS公式ドキュメントをもとに整理します。AWS CLIでバケットを作ってライフサイクルを設定する最小手順、EBSやEFSとの違い、S3を採用すべき条件と見送るべき場面の判断基準まで、実装者が基盤設計で迷う論点を具体的に示します。

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

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

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

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

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

S3という略称の意味とSimple Storage Serviceが担う役割の範囲

「S3」は、Simple Storage Serviceの頭文字であるSが3つ並ぶことに由来する呼び名です。正式名はAmazon Simple Storage Serviceで、AWSの資料やコンソールでは「Amazon S3」と表記されます。検索で「s3とは」と調べる人の多くはこのAWSのサービスを指しており、本記事もその意味で扱います。

役割は、インターネット経由のAPIでデータを保存し、必要なときに取り出す「保管庫」です。AWS公式のWhat is Amazon S3?では、データレイク、Webサイト、モバイルアプリ、バックアップと復元、アーカイブ、IoTデバイス、ビッグデータ分析といった用途が挙がっています。サーバーのディスクを増設するのではなく、容量を気にせず置ける外部の保管先をAPIで呼び出す、という位置付けで捉えると、後述するEBSやEFSとの違いも整理しやすくなります。

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

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

汎用・ディレクトリ・テーブル・ベクトルという4種類のS3バケット

2026年9月時点のS3ユーザーガイドでは、バケットは汎用バケット・ディレクトリバケット・テーブルバケット・ベクトルバケットの4種類に分かれています。一般に「S3のバケット」と呼ぶのは汎用バケットで、ほとんどの用途とアクセスパターンに推奨される元来の種別です。

最初に作るのは汎用バケットで十分です。ミリ秒未満の応答が要る機械学習の前処理などではディレクトリバケット、SQLで分析するデータレイクではテーブルバケット、RAGの検索基盤ではベクトルバケットと、要件が固まってから専用の種別を検討する順序にすると設計の手戻りが減ります。

4種類それぞれの作成コマンド、作れる数の上限、バケットを空にして削除する手順はS3バケットの4種類と管理手順｜作成・一覧・容量確認から上限数と削除までにまとめています。

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

1つのオブジェクトの上限は、マルチパートアップロードの制限値の一覧で2026年9月時点に48.8TiBと示されています。解説記事でよく見る「最大5TB」は以前の値で、現行の仕様ではありません。同じ一覧では、1回のアップロードのパート数は10,000まで、パートサイズは5MiB〜5GiBです。

送り方によっても上限が変わります。オブジェクトのアップロード方法の解説によると、SDKやCLIからの単一PUTは5GBまで、マネジメントコンソールからは160GBまで、マルチパートアップロードなら50TBまで扱え、5TBを超えるファイルはS3 Transfer Managerを使う前提です。大きなファイルや、ネットワークが不安定な環境からの転送では、オブジェクトを分割して並列に送るマルチパートアップロードを使います。分割送信は途中で失敗した部分だけを送り直せるため、大容量データの転送を安定させられます。

逆に、細かなファイルを大量に扱う場合はリクエスト数が料金と性能に効いてくるため、ある程度まとめてから格納する設計が実務では有効です。オンプレミスのファイルサーバーからまとめてS3へ流し込むなら、AWS DataSyncによる転送タスクの設計が選択肢になります。外部の取引先からSFTPで受け取ってS3へ着地させる用途なら、AWS Transfer Familyのエンドポイント設計と料金が受け口の候補です。既存のファイル共有をNFSやSMBのまま残し、保存先だけをS3へ寄せたい場合は、AWS Storage Gatewayによるオンプレミスとの橋渡しが選択肢になります。

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

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

表の「アクセス方法」の行が選定の分かれ目です。アプリがAPIでファイル単位に出し入れするならS3、OSがディスクとして扱うならEBS、複数台から同じディレクトリを見るならEFSを選びます。

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

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

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

ストレージクラスの公式解説によると、2026年9月時点で、頻繁に読むデータ向けのS3標準、アクセス頻度が読めないデータを自動で振り分けるIntelligent-Tiering、低頻度アクセス向けの標準-IAとOne Zone-IA、長期保管のためのGlacier Instant Retrieval・Glacier Flexible Retrieval・Glacier Deep Archive、そして1桁ミリ秒の応答を狙うS3 Express One Zoneといったクラスがあります。読む頻度が高いほど標準系、めったに読まないほどGlacier系という単価と取り出し速度のトレードオフで選びます。

表ではGlacier Flexible RetrievalをFlexible、Glacier Deep ArchiveをDeep Archiveと略記しています。最低保存期間より前に削除や移動をすると、残りの期間分も課金されます。数日で消える一時ファイルを低頻度クラスへ入れると割高になるため、保存期間の見込みもクラス選定の条件に含めてください。長期アーカイブに特化したGlacierの取り出しモードや料金は、Amazon S3 Glacierとはの記事で深掘りしています。

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

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

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

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

ただし、強い整合性の対象はオブジェクトの読み書きです。公式のデータ整合性モデルの説明では、バケットの設定は結果整合性とされ、バージョニングを初めて有効にした後は、書き込みを始める前に15分待つよう推奨しています。構築スクリプトでバケット作成・設定・書き込みを連続実行する場合は、この待ち時間を入れておくと想定外の挙動を避けられます。数値や仕様は断定せず、AWS公式のドキュメントで対象リージョンと時点を実測して確定させてください。

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

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

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

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

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

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

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

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

4つの要素のうち、見積もりで漏れやすいのはリクエストと取り出し料金です。月間のPUT・GET回数と、低頻度クラスから読み出す量を先に見込んでおくと、請求額の想定外の増加を防げます。

AWS CLIで試すS3バケット作成・アップロード・ライフサイクル設定の手順

S3の仕組みは、実際にバケットを1つ作ってみると理解が早まります。ここではAWS CLI v2が設定済みで、S3の操作権限を持つIAMユーザーまたはロールで認証できている前提で、東京リージョン（ap-northeast-1）に汎用バケットを作る最小手順を示します。バケット名は全アカウントで一意にする必要があるため、例の名前は自社の命名に置き換えてください。

create-bucketとcpで東京リージョンにバケットを作りオブジェクトを置く手順

AWS CLIのcreate-bucketリファレンスにあるとおり、us-east-1以外のリージョンで作る場合は LocationConstraint の指定が必要です。作成後にバージョニングを有効化し、ファイルを1つ置いて一覧を確認します。

# 東京リージョンに汎用バケットを作成する
aws s3api create-bucket \
  --bucket example-issoh-s3-demo-20260925 \
  --region ap-northeast-1 \
  --create-bucket-configuration LocationConstraint=ap-northeast-1

# バージョニングを有効化する（有効化後は書き込み前に15分待つのが公式推奨）
aws s3api put-bucket-versioning \
  --bucket example-issoh-s3-demo-20260925 \
  --versioning-configuration Status=Enabled

# ファイルを置き、プレフィックス単位で一覧する
aws s3 cp ./access.log s3://example-issoh-s3-demo-20260925/logs/2026/09/access.log
aws s3 ls s3://example-issoh-s3-demo-20260925/logs/ --recursive

一覧に「logs/2026/09/access.log」が表示されれば、フォルダを作らなくてもキーのスラッシュで階層が表現されていることを確認できます。CLIやboto3でのIAM権限設計と署名付きURLの発行までを通しで試す場合は、AWS S3の使い方｜CLIでのバケット作成から権限設計・署名付きURLまでの実装手順で手順を追えます。

ライフサイクル設定JSONで30日後に標準-IAへ移し失効させる設定例

次に、「logs/」配下を作成30日後に標準-IAへ、90日後にGlacier Flexible Retrievalへ移し、7年（2,555日）で削除するルールを設定します。ルールはJSONで書き、put-bucket-lifecycle-configuration で適用します。

# lifecycle.json を作成する
cat > lifecycle.json <<'EOF'
{
  "Rules": [
    {
      "ID": "logs-tiering",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 2555 }
    }
  ]
}
EOF

# バケットに適用し、設定内容を読み戻して確認する
aws s3api put-bucket-lifecycle-configuration \
  --bucket example-issoh-s3-demo-20260925 \
  --lifecycle-configuration file://lifecycle.json
aws s3api get-bucket-lifecycle-configuration \
  --bucket example-issoh-s3-demo-20260925

標準-IAは最低保存期間が30日のため、30日より前に移す設定は避けます。バージョニングを有効にしたバケットでは、上書きで残った過去バージョンも保存量として課金されるため、本番では過去バージョンを失効させるルールもあわせて検討してください。試し終えたバケットは、オブジェクトと過去バージョンを削除してからバケットを消すと、課金が残りません。

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

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

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

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

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

OSからボリュームとしてマウントしてデータベースを動かす、ファイルをその場で細かく上書きしながら扱う、といった要件はS3では向きません。ブロックデバイスが要るならEBS、複数サーバーで共有するファイルシステムが要るならEFS、という切り分けになります。2026年4月からは、S3バケットを正本のままNFSでマウントするS3 Filesも選べるようになりました。仕組みと手順、EFSとの使い分けはS3 Filesとは：S3バケットをNFSでマウントする手順とEFS・Mountpointとの使い分けで解説しています。S3はオブジェクト全体の入れ替えを前提にしたAPIで、ファイルの一部分だけを書き換える操作には設計上馴染まないためです。単純な保管単価だけを見てS3に寄せると、マウント前提のアプリで作り替えが発生しかねないため、アクセス方法（マウントかAPIか）を軸に選定してください。なお、AWSではなくAzure中心の構成なら、S3に対応するオブジェクトストレージはAzure Blob Storageとはを実装者目線で解説した記事で扱うAzure Blob Storageになります。

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

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

よくある質問

「s3とは何か」を調べ始めた段階から導入検討まで、実装者から多く挙がる質問を、AWS公式ドキュメントに基づいて簡潔に整理します。

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

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

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

読む頻度が高いデータはS3標準、頻度が読めないデータはIntelligent-Tiering、めったに読まない低頻度データは標準-IA、長期保管はGlacier系という単価と取り出し速度のトレードオフで選びます。アクセスパターンが時間とともに変わるデータは、ライフサイクルポリシーで自動的にクラスを移すと、手作業なくコストを抑えられます。低頻度クラスには30日や90日の最低保存期間があるため、短期間で消すデータは標準のまま置くのが無難です。アーカイブ向けのGlacier系クラスごとの取り出し時間や料金の違いは、Amazon S3 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系サービス
• AWS S3の使い方｜CLIでのバケット作成から権限設計・署名付きURLまでの実装手順：CLIとboto3で実際にバケットを作る手順を確かめたい場合に