🪣【初心者向け】AWS S3とは何か？オブジェクトストレージの仕組みをやさしく解説

AWSを勉強していると、かなり早い段階で登場するサービスのひとつが Amazon S3です。

S3について、

「クラウド上にファイルを保存するサービス」

と説明されることがあります。

これは間違いではありません。

しかし、S3をWindowsのフォルダやLinuxのファイルシステムと まったく同じものとして考えてしまうと、 後から少し不思議な部分が出てきます。

• なぜ「フォルダ」ではなくKeyという言葉が出てくるの？
• Bucketとは何？
• EC2のディスクとは何が違う？
• S3に直接アップロードする仕組みはどう作るの？
• Storage Classは何のためにある？
• CloudFrontと組み合わせる理由は？

これらを理解するために重要なのが、 「S3はオブジェクトストレージである」 という点です。

この記事では、まず初心者向けにS3の基本構造を整理し、 後半ではS3の内部的な考え方や実際のシステム設計まで掘り下げます。

---

結論：S3は「巨大なクラウド上のフォルダ」ではない

最初に結論です。

Amazon S3は、 オブジェクトストレージと呼ばれるストレージサービスです。

基本的には、

Bucket
  ↓
Object
  ↓
データ + メタデータ

という考え方でデータを保存します。

そして、それぞれのオブジェクトを識別するために Keyが使われます。

Bucket
│
├─ images/cat.jpg
├─ images/dog.jpg
└─ documents/report.pdf

        ↑
       Key

見た目はフォルダ構造に見えます。

しかし、S3の基本的なデータモデルでは、 一般的なファイルシステムと同じ意味で 「images」というディレクトリが存在しているわけではありません。

この違いがS3を理解する最初のポイントです。

---

S3とは何か？

S3は、 Amazon Simple Storage Serviceの略です。

AWSが提供するオブジェクトストレージサービスで、 さまざまなデータの保存に利用できます。

たとえば、

• 画像
• 動画
• PDF
• ログ
• バックアップ
• 静的Webコンテンツ
• データ分析用ファイル

などです。

Webアプリケーションでは、

User
 ↓
Application
 ↓
S3
 ↓
画像・PDF・動画など

という構成で、 アップロードされたファイルの保存先として使われることもあります。

---

Bucketとは何か？

S3では、 オブジェクトをBucket（バケット）の中に保存します。

S3
 │
 ├─ Bucket A
 │    ├─ Object
 │    └─ Object
 │
 └─ Bucket B
      ├─ Object
      └─ Object

バケットは、 S3上でオブジェクトをまとめて管理するための基本単位です。

バケット単位で、

• アクセス制御
• Versioning
• Lifecycle
• ログ
• 暗号化に関する設定

など、さまざまな設定を行えます。

ただし、 Bucketそのものを一般的なOSのフォルダと同じものとして考えるのも正確ではありません。

「S3というサービスの中に、オブジェクトを保存するための入れ物を作る」 くらいから理解すると分かりやすいでしょう。

---

Objectとは何か？

S3へ保存されるデータの基本単位が、 Object（オブジェクト）です。

ざっくり整理すると、

Object
 │
 ├─ データ本体
 ├─ Key
 └─ Metadata

という要素を持ちます。

たとえば画像を保存する場合、

データ
↓
cat.jpg の中身

Key
↓
images/cat.jpg

Metadata
↓
Content-Type など

という形で扱われます。

---

Keyとは何か？

Keyは、 バケット内でオブジェクトを識別するための名前です。

たとえば、

users/123/profile.jpg

というKeyを付けることができます。

これを見ると、

users
 └─ 123
     └─ profile.jpg

というフォルダ構造に見えます。

しかしS3では、 「users/123/profile.jpg」という文字列全体がKey として扱われます。

AWSコンソールなどでは「/」を区切りとして、 フォルダのような画面表示ができます。

このような共通するKeyの先頭部分は Prefix（プレフィックス） として扱えます。

users/123/profile.jpg
users/123/icon.jpg
users/123/data.json

─────────
users/123/
↑
共通Prefix

つまり、 見た目はフォルダでも、基本的な考え方はKeyによるオブジェクト管理 なのです。

---

S3とEC2のディスクは何が違う？

AWSにはS3以外にもストレージがあります。

代表的なのが、 EC2などで利用されるAmazon EBSです。

両者は同じ「データを保存するもの」でも、 考え方が違います。

項目	S3	EBS
種類	オブジェクトストレージ	ブロックストレージ
主なアクセス方法	APIなど	EC2等からブロックデバイスとして利用
主な用途	画像・ログ・バックアップ等	OSやアプリのディスク等
一般的なファイルシステム	そのままではない	上にファイルシステムを構築可能

たとえば、

EC2
 ↓
EBS
 ↓
Filesystem
 ↓
/var/log/...

という使い方と、

Application
 ↓
S3 API
 ↓
Bucket
 ↓
Object

では仕組みが異なります。

S3をEC2の普通のハードディスクと同じ感覚で扱わない ことが重要です。

---

なぜS3は大量のデータ保存に向いているのか？

S3では、 サーバのディスク容量を先に決めて確保するような感覚とは異なり、 大量のオブジェクトを保存できるようサービス側で設計されています。

アプリケーション側から見ると、

容量が増えた
 ↓
新しいHDDを買う
 ↓
サーバへ追加する

といった物理的なストレージ管理を意識する必要が大きく減ります。

そのため、

• 大量の画像
• バックアップ
• ログ
• データレイク

など、データ量が大きくなる用途でも利用されています。

---

S3は「サーバのローカルディスク」とは違う

ここは重要です。

アプリケーションからS3へアクセスするときは、 通常、 ネットワーク越しにS3のAPIへアクセスします。

Application
    │
    │ Network
    ↓
   S3 API
    ↓
  Object

そのため、 ローカルディスクへの読み書きと まったく同じ性能特性ではありません。

「保存できるから全部S3へ置けばよい」 というわけではなく、 データの性質やアクセス方法に応じてストレージを選ぶ必要があります。

---

ここまでのまとめ（初心者向け）

ここまでで一番大切なのは、 S3を単なるクラウド上のフォルダとして理解しないことです。

• S3はオブジェクトストレージ
• Bucketの中にObjectを保存する
• ObjectはKeyによって識別される
• 「/」を含むKeyによってフォルダのように見せられる
• S3とEBSではストレージの仕組みが異なる
• S3へは通常ネットワーク越しにAPIなどでアクセスする

初心者向けとしては、 まず次の図を理解できれば十分です。

S3
 ↓
Bucket
 ↓
Object
 ├─ Data
 ├─ Key
 └─ Metadata

ここから先は、 S3を実際のシステムで使うときに重要になる仕組みへ進みます。

---

▼▼ 深掘り編ここから ▼▼

---

S3は高い耐久性をどのように実現している？

S3の代表的な特徴のひとつが、 非常に高いデータ耐久性を前提として設計されていることです。

たとえばS3 Standardは、 99.999999999%（イレブンナイン）のデータ耐久性 を想定して設計されています。

これは、 「絶対にデータが消えない」という意味ではありません。

S3ではデータを冗長化して管理し、 ハードウェア障害などが発生してもデータを失いにくい仕組みを提供しています。

ただし、

• 利用者による誤削除
• アプリケーションのバグ
• 認証情報の侵害

などまで自動的に防げるわけではありません。

そこで重要になる仕組みのひとつが、 Versioningです。

---

Versioningとは何か？

S3では、 バケットでVersioningを有効化できます。

Versioningを利用すると、 同じKeyのオブジェクトに複数のバージョンを保持できます。

report.pdf
 │
 ├─ Version 1
 ├─ Version 2
 └─ Version 3

たとえば誤って上書きしてしまった場合でも、 以前のバージョンが保持されていれば復元できます。

正常なファイル
 ↓
誤って上書き
 ↓
Versioning
 ↓
以前のVersionを取得

削除操作についても、 Versioningが有効なバケットでは Delete Markerなどの仕組みが関係します。

ただしVersioningを有効にすると、 古いバージョンもストレージを消費します。

そこでLifecycleと組み合わせる設計が役立ちます。

---

Lifecycleとは何か？

S3 Lifecycleを使うと、 オブジェクトのライフサイクルに応じて 自動的な処理を設定できます。

たとえば、

作成直後
 ↓
S3 Standard

30日後
 ↓
低頻度アクセス向けClass

さらに時間経過
 ↓
Archive向けClass

といったルールを設計できます。

また、条件に応じて 不要になったオブジェクトや古いバージョンを 期限切れにする設定も可能です。

大量のバックアップやログを保存する場合、 Lifecycleはコスト管理で非常に重要になります。

---

Storage Classとは？

すべてのデータが、 毎日頻繁にアクセスされるわけではありません。

そこでS3には、 用途に応じた複数のStorage Classがあります。

代表的なものには、

• S3 Standard
• S3 Intelligent-Tiering
• S3 Standard-IA
• S3 One Zone-IA
• S3 Glacier Instant Retrieval
• S3 Glacier Flexible Retrieval
• S3 Glacier Deep Archive

などがあります。

考え方としては、

よく使うデータ
 ↓
すぐ取り出せるClass

あまり使わないデータ
 ↓
低頻度向けClass

長期保存データ
 ↓
Archive向けClass

という使い分けです。

ただし、 単純に「安いStorage Classへ移せば得」とは限りません。

クラスによって、

• ストレージ料金
• 取り出し料金
• 最低保存期間
• 取り出しにかかる時間

などの特性が異なるため、 アクセスパターンに合わせて選ぶ必要があります。

---

S3の整合性はどうなっている？

S3について調べると、 古い記事で 「S3は結果整合性」 という説明を見ることがあります。

ここは注意が必要です。

現在のAmazon S3では、 オブジェクトのPUTやDELETEなどに対して 強い読み取り後書き込み整合性（Strong Read-After-Write Consistency） が提供されています。

PUT Object
   ↓
成功
   ↓
GET Object
   ↓
最新データ

新規作成だけでなく、 既存オブジェクトの上書きや削除についても 強い整合性が提供されています。

そのため、 昔のS3の仕様を前提にした記事を読むときは注意しましょう。

---

Presigned URLとは何か？

WebアプリケーションでS3を使うときに、 非常に便利なのが Presigned URL（署名付きURL）です。

たとえばユーザーが画像をアップロードするシステムを考えます。

単純な構成では、

User
 ↓ 画像
Application Server
 ↓ 画像
S3

となります。

この場合、大きなファイルがすべて アプリケーションサーバを通過します。

Presigned URLを利用すると、 アプリケーション側で期限付きのURLを発行し、 クライアントからS3へ直接アップロードする構成を作れます。

User
 │
 │ ① URLを要求
 ↓
Application
 │
 │ ② Presigned URL
 ↓
User
 │
 │ ③ 直接Upload
 ↓
S3

これによって、 アプリケーションサーバがファイル本体を中継しない構成にできます。

Presigned URLには有効期限があり、 URLを生成した主体の権限などに基づいて 限定された操作を一時的に許可できます。

ただしURLを知っている相手が 有効期間中に利用できる可能性があるため、 扱いには注意が必要です。

---

S3を公開設定にすればWeb配信できる？

技術的にはS3からコンテンツを提供する構成がありますが、 だからといって バケットを何となくPublicにする のは避けるべきです。

AWSには、 意図しない公開を防ぐための S3 Block Public Access があります。

公開Webコンテンツを配信する場合も、 要件に応じてCloudFrontなどを組み合わせ、 S3への直接アクセスを制限する構成を検討できます。

---

S3とCloudFrontを組み合わせる理由

画像やCSS、JavaScriptなどを 多くのユーザーへ配信する場合、 S3とAmazon CloudFrontを 組み合わせる構成があります。

User
 ↓
CloudFront
 ↓
S3

CloudFrontはCDNとして、 エッジロケーションなどを利用してコンテンツを配信します。

一度取得されたコンテンツをキャッシュできれば、 毎回S3まで取得しに行く必要を減らせます。

User
 ↓
CloudFront Cache
 ↓
HIT
 ↓
そのまま返す

MISS
 ↓
S3から取得

ここで以前の記事で扱った 「キャッシュ」 の知識がつながります。

S3がオリジンとなるデータを保存し、 CloudFrontがユーザーに近い場所から効率よく配信する、 という役割分担ができます。

---

S3のセキュリティではIAMが再登場する

S3へアクセスできる主体を制御するときには、 IAMの知識が重要になります。

Principal
   ↓
IAM Policy
   ↓
S3
   ↓
Bucket / Object

さらにS3には、 Bucket Policy というリソースベースポリシーもあります。

Identity側
    ↓
IAM Policy

    ＋

S3側
    ↓
Bucket Policy

実際のアクセス可否では、 これらを含む適用対象のポリシーや設定が関係します。

つまりInfrastructure & Cloudの最初の記事で扱ったIAMが、 ここでもそのまま登場します。

---

S3の暗号化

S3では、 保存されるオブジェクトに対する サーバー側暗号化を利用できます。

代表的には、

• SSE-S3
• SSE-KMS

などがあります。

SSE-KMSではAWS KMSのキーを利用するため、 S3へのアクセス権だけでなく KMS側の権限設計も関係する場合があります。

Application
    ↓
   S3
    │
    └─ KMS
        ↓
      Key

そのため、

「S3へのAllowはあるのにアクセスできない」

という場合に、 KMS側の権限が原因になっているケースもあります。

AWSでは、 ひとつのサービスだけを見て権限を判断できない場面があることを覚えておきましょう。

---

S3でありがちな落とし穴

① S3を普通のファイルシステムとして考える

S3はオブジェクトストレージです。

ローカルファイルシステムと同じ操作特性を前提にすると、 設計が噛み合わなくなることがあります。

② 何でもPublicにする

「ブラウザからアクセスしたいからPublic」 と安易に設定すると、 意図しないデータ公開につながる可能性があります。

③ Versioningだけ有効にして安心する

古いVersionもストレージを消費します。 Lifecycleを含めた運用設計も重要です。

④ 安いStorage Classだけを見て選ぶ

取得料金や最低保存期間などを含めて考える必要があります。

⑤ アクセスキーをアプリへ直接埋め込む

EC2やECS、LambdaなどからS3へアクセスする場合は、 可能な構成ではIAMロールなどを利用し、 長期アクセスキーをコードへ埋め込まない設計を検討します。

---

ここまでのInfrastructure & Cloudが全部つながる

ここまでの記事で扱ってきた技術を、 ひとつのWebアプリケーションとして組み合わせてみます。

Developer
   │
   ↓
  Git
   │
   ↓
 CI/CD
   │
   ↓
Docker Image
   │
   ↓
Container
   │
   ├──── IAM Role
   │        ↓
   │       S3
   │
   ↓
Application

User
 ↓
CloudFront
 ↓
S3

それぞれの記事が、 独立した知識ではなくなってきます。

• IAM：誰が何をしてよいか
• Docker：アプリをどのような環境で動かすか
• CI/CD：変更をどう検証し、届けるか
• S3：データをどう保存・配信するか

クラウドを理解するというのは、 サービス名を大量に暗記することではありません。

それぞれのサービスがシステムの中で何を担当しているのか をつなげて考えることが重要です。

---

Deep Friendly Tech の一言（後書き）

S3はAWSの中でも、 最初はとても分かりやすく見えるサービスです。

ファイルを保存する
↓
S3

これだけでも使い始めることはできます。

しかし一段深く見ると、

FileではなくObject

DirectoryではなくKey / Prefix

DiskではなくObject Storage

という、少し違った世界が見えてきます。

さらに、

IAM
      ↓
アクセス制御

Versioning
      ↓
データ保護

Lifecycle
      ↓
ライフサイクル管理

Storage Class
      ↓
コスト最適化

CloudFront
      ↓
コンテンツ配信

と知識をつなげていくと、 S3は単なる「ファイル置き場」ではなくなります。

大量のデータを、どう保存し、守り、届け、そしてコストを管理するのか。

S3は、その問いに対するAWSの基礎部品のひとつです。☁️