S3 は「ファイルを置ける場所」として最初に紹介されることが多く、それ自体は正しいのですが、「サーバーのディスクとどう違うのか」が曖昧なまま使うと、あとで DynamoDB や EFS が出てきたときに位置づけが混乱します。そして S3 は、AWS で一番多い事故「公開設定の間違い」の舞台でもあります。この記事は、S3 を「ディスクではない置き場」として位置づけ、ストレージクラスと公開設定までを扱います。
この記事の結論
- S3（Simple Storage Service）は、ファイルをオブジェクトとして API で出し入れするストレージです。OS からマウントして使うディスク（EBS）ではありません。
- 置き場の単位はバケット、中のファイルはキー（名前）で指定します。フォルダのように見える階層は、キーの中の「/」の見せ方に過ぎません。
- 容量の上限を気にせず置け、AWS は 99.999999999%（イレブンナイン）の耐久性を設計目標としています。
- ストレージクラスは「取り出す頻度」で選びます。よく読むなら Standard、たまになら IA、ほぼ読まないなら Glacier 系。
- 一番多い事故は公開設定です。ブロックパブリックアクセスをアカウント単位で有効にしたまま、公開が要るときは CloudFront を前に置きます。
S3 は「API で出し入れする置き場」で、ディスクではない
S3（Amazon Simple Storage Service）は、2006 年に AWS が最初に出したサービスの1つです。ファイルをオブジェクトとして置き、HTTP の API（PutObject・GetObject）で出し入れします。
「ディスクではない」が最初に押さえる点です。EC2 とは何かで扱った EBS は、インスタンスに付けて OS がマウントし、ファイルシステムとして読み書きするディスクです。S3 はマウントするものではなく、アプリが「このキーのオブジェクトをください」と API で頼むものです。
| 項目 | S3 | EBS |
|---|---|---|
| 位置づけ | オブジェクトストレージ | ブロックストレージ（ディスク） |
| 使い方 | API（PutObject / GetObject）で出し入れ | OS がマウントしてファイルシステムとして使う |
| 誰から見えるか | 権限があればどこからでも | 付けた1つのインスタンスから |
| 容量 | 上限を気にしない（オブジェクトは1つ 5 TB まで） | 作るときにサイズを決める |
| 向くもの | 画像・動画・ログ・バックアップ・配信物・データレイク | OS・データベースのデータファイル |
| 料金 | 置いた容量＋リクエスト回数＋外への転送 | 確保した容量（使っていなくても） |
「複数のサーバーから同じファイルを見たいか」で迷いが消えます。見たいなら S3、1台のディスクとして使うなら EBS です。
S3 VS EBSディスクではない
複数のサーバーから同じファイルを見たいなら S3
EBS
ブロックストレージ（ディスク）
- OS がマウントしてファイルシステムとして使う
- 付けた1つのインスタンスから見える
- 作るときにサイズを決める
- OS・データベースのデータファイル
S3
オブジェクトストレージ
- API（PutObject / GetObject）で出し入れ
- 権限があればどこからでも見える
- 容量の上限を気にしない
- 画像・ログ・バックアップ・配信物
バケットとキー: フォルダに見えるが、フォルダではない
BUCKET AND KEY置き場の構造
バケットの中に、キーという名前でオブジェクトを置く
-
バケット
入れ物。名前は全世界で一意。リージョンを選んで作る
-
キー
logs/2026/09/app.log のような名前。/ は階層に見えるだけ
-
オブジェクト
本体とメタデータ。API で出し入れ。ディスクではない
- バケットは、オブジェクトを入れる入れ物です。リージョンを選んで作り、名前は全世界の AWS アカウントをまたいで一意です。
- オブジェクトは、置いた1つ1つのファイルです。本体（データ）と、メタデータ（サイズ・更新日時・Content-Type など）を持ちます。
- キーは、バケットの中でのオブジェクトの名前です。
logs/2026/09/26/app.logのように書けます。
コンソールでは logs/ 2026/ とフォルダのように表示されますが、実体は「logs/2026/09/26/app.log」という1つの長い名前です。フォルダを「作る」操作は、その名前で空のオブジェクトを置いているだけです。この理解があると、「フォルダを消したのに中身が残る」「一覧の API に prefix を渡す」といった動きが読めます。
耐久性について、AWS は 99.999999999%（イレブンナイン）を設計目標として公表しています。これは「置いたオブジェクトが失われる確率が極めて低い」という意味で、複数の AZ に自動で複製されることで実現しています。ただし、耐久性が高いことと、自分が間違って消さないことは別です。誤削除への備えは、後述するバージョニングで持ちます。
CHECK 1ここまでの確認
「複数のサーバーから同じファイルを見たい」。置き場はどちら?
答えと解説
答え: 2. S3
EBS は1つのインスタンスに付けて使うディスクです。S3 は API で出し入れし、権限があればどこからでも同じものを見られます。
ストレージクラスは「取り出す頻度」で選ぶ
S3 の料金は、置いた容量に対する単価がストレージクラスで変わります。クラスは「どれくらいの頻度で取り出すか」で選び、取り出す頻度が低いクラスほど、置く単価は安く、取り出しの単価と待ち時間は増えます。
| クラス | 向くもの | 取り出し |
|---|---|---|
| S3 Standard | よく読むデータ（Web の配信物、アプリのデータ） | すぐ、追加料金なし |
| S3 Standard-IA（Infrequent Access） | たまに読むが、読むときはすぐ要る（バックアップ、古いログ） | すぐ、取り出しに料金 |
| S3 Glacier Instant Retrieval | 四半期に1回程度、すぐ要る | すぐ、取り出しに料金 |
| S3 Glacier Flexible Retrieval | 年に1〜2回、数分〜数時間待てる | 分〜時間、取り出しに料金 |
| S3 Glacier Deep Archive | ほぼ読まない。規制で保管が要るもの | 12 時間程度、取り出しに料金 |
| S3 Intelligent-Tiering | 頻度が読めないもの | アクセスのパターンで自動で移動 |
各クラスの単価と取り出し時間は変わるので、ここには書きません。公式の料金ページで確認してください。選び方の考え方だけ持てば十分です。
クラスは手で変えるのではなく、ライフサイクルルールで「30 日経ったら IA に、90 日経ったら Glacier に、365 日で削除」のように自動で移すのが基本です。
バージョニングと削除保護
バージョニングを有効にすると、同じキーに上書きしても前の版が残り、削除しても「削除マーカー」が付くだけで元の版は残ります。誤って上書き・削除したときに戻せる、一番簡単な保険です。
その代わり、残った版の分だけ容量の料金がかかります。ライフサイクルルールで「古い版は 30 日で消す」を組み合わせるのが定石です。
WHAT YOU PROTECT耐久性と、自分で守るもの
耐久性が高いことと、自分が消さないことは別
自分で守る:
- バージョニング（誤削除・上書き）
- ライフサイクル（古い版と要らない物の削除）
- ブロックパブリックアクセス（公開事故）
- バケットポリシーの Principal の点検
置いた物を失う原因は、たいてい自分の操作
CHECK 2ここまでの確認
コンソールで「logs/2026/」というフォルダを作った。実体はどれ?
答えと解説
答え: 2. 「logs/2026/」という名前の空のオブジェクトが置かれただけ
S3 のキーは平らな名前の一覧で、「/」は階層に見える見せ方に過ぎません。フォルダを作る操作は、その名前で空のオブジェクトを置いているだけです。
一番多い事故: 公開設定
S3 の事故の大半は、「公開するつもりの無いバケットが、インターネットから読める状態になっていた」です。原因はたいてい、バケットポリシーや ACL で Principal: "*"（誰でも）に読み取りを許可してしまうことです。
これを防ぐために、AWS はブロックパブリックアクセスという設定を用意しています。これが有効なら、たとえポリシーで公開を許可しても、公開は止められます。新しく作るバケットでは既定で有効です。
公開設定で守ること
- ブロックパブリックアクセスは、アカウント単位で有効にしたままにする。 バケット単位で外すのは、公開が要ると分かっている1つだけ
- 公開が要るときは、バケットを直接公開しない。 CloudFront を前に置き、S3 は CloudFront からだけ読める設定（OAC）にする
- 一時的に渡したいだけなら、署名付き URL を使う。 期限付きの URL を発行し、その間だけ読める
- バケットポリシーの
Principal: "*"を見たら、まず疑う。 意図した公開でなければ消す
IAM とは何かで扱ったポリシーの読み方（Effect・Action・Resource に加えて Principal）が、ここでそのまま使えます。バケットポリシーは「このバケットに対して、誰が、何をしてよいか」をバケット側に書いたものです。
PUBLISH SAFELY公開が要るときの形
バケットは直接公開せず、CloudFront を前に置く
-
利用者
ブラウザから画像を取りに来る
-
CloudFront
CDN。公開されているのはここだけ
-
S3
CloudFront からだけ読める（OAC）。ブロックパブリックアクセスは有効のまま
CHECK 3ここまでの確認
公開が要る静的サイトを S3 で配信する、基本の形はどれ?
答えと解説
答え: 2. ブロックパブリックアクセスは有効のまま、CloudFront を前に置いて S3 は CloudFront からだけ読める設定にする
バケットの直接公開は、公開設定の事故と同じ構造です。CloudFront（OAC）を前に置くか、一時的なら署名付き URL を使います。
まとめ
S3 は、ファイルをオブジェクトとして API で出し入れする置き場で、ディスク（EBS）ではありません。バケットの中にキーで名前を付けて置き、フォルダに見える階層は名前の見せ方です。ストレージクラスは取り出す頻度で選び、ライフサイクルで自動で移します。バージョニングで誤削除に備え、ブロックパブリックアクセスを有効にしたまま、公開は CloudFront か署名付き URL で行います。ここまでで段1「入口」の4つ（EC2・IAM・VPC・S3）が揃いました。次はCloud Practitioner の位置づけで、この4つを資格の地図に置きます。
参照ソース
- Amazon S3 とは（AWS S3 ユーザーガイド） — バケット・オブジェクト・キーの定義、耐久性 99.999999999% の設計目標、オブジェクトの上限サイズの根拠。2026年9月時点の記載
- Amazon S3 ストレージクラス（AWS） — 各ストレージクラスの位置づけと取り出しの性質の根拠。単価はこのページと料金ページで確認する
- Amazon S3 ストレージへのパブリックアクセスのブロック（AWS S3 ユーザーガイド） — ブロックパブリックアクセスの仕組みと、新規バケットで既定で有効なことの根拠
- S3 バケットでのバージョニングの使用（AWS S3 ユーザーガイド） — バージョニングと削除マーカーの動作の根拠
- Amazon EBS とは（AWS EBS ユーザーガイド） — EBS がブロックストレージで、インスタンスに付けて使うものであることの根拠（S3 との対比に使用）
