S3のキャッチアップ

はじめに

AWSのS3についてです。おそらく実務で使ってる方も多いと思います。
S3はずっと静的ファイルを保存する場所という認識で雰囲気で使っていました。

今回「バケットをterraformで作る」というタスクをする中でなんやこれが多発しました。

ライフサイクル？古いバージョン？暗号化？？と、一気に謎が湧きました。

この記事では、私がS3をキャッチアップして腑に落ちたポイントをまとめます。

まずはタスクだったバケットから。

バケットとは何か

バケットは、S3における「一番外側の箱」です。
S3のオブジェクト（ファイル）は、必ずどれか1つのバケットに属します。

アクセス制御、暗号化、バージョニング、ライフサイクルなどの設定は、すべて「バケット単位」で適用されます。

つまり、バケットは単なる入れ物ではなく、「セキュリティと運用ルールの境界線」です。

S3の事故の多くは、「1つのバケットに性質の違うデータを混ぜたこと」から起きるようです。
ざっくりフォルダみたいなものだと思ってたんですが、そうではなくてドメインの一部みたいです。

S3はフォルダではない

まず、ここを誤解していました。
S3は「フォルダ構造を持つストレージ」ではないようです。

実態はこれです。

{ key: object }

images/2025/logo.png のようなパスはただの文字列（key） です。

フォルダが存在しているわけではなくUIがそれっぽく見せているだけです。

Amazon S3 汎用バケットは、ファイルシステムのような階層構造ではなく、フラットな構造になっています。ただし、整理を簡素化するために、Amazon S3 コンソールでは、オブジェクトをグループ化する手段としてフォルダの概念がサポートされています。

バージョニング = 上書き時の保険

terraformですがこの設定です。

resource "aws_s3_bucket_versioning" "example" {
   bucket = aws_s3_bucket.example.id
   versioning_configuration {
　　　status = "Enabled"
   }
}

同じkeyにファイルを上書きすると、

最新のもの → current
以前のもの → non-current（古いバージョン）

として残ります。

つまり、上書きしても、前のデータは消えないという仕組みです。

上書きしたら普通に消えると思ってた〜〜〜！！！！

「古いバージョンを消す」ライフサイクルの意味

resource "aws_s3_bucket_lifecycle_configuration" "example" {
  bucket = aws_s3_bucket.example.id

  rule {
    id     = "delete-old-versions"
    status = "Enabled"

    noncurrent_version_expiration {
      noncurrent_days = 30
    }
  }
}

これは、今使われていない過去バージョンだけを30日後に削除するという設定です。

S3の暗号化は「保存時」を守る

resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  bucket = aws_s3_bucket.example.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

png / jpg などの画像も 中身のバイナリがS3内部で暗号化されるそうです。

取得時は自動で復号されるため、アプリ側で何か意識する必要はありません。便利、、

公開設定

S3を直接公開すると、こんな感じになるようです。

https://bucket-name.s3.amazonaws.com/image.png

このURLは、

認証なし
URLを知っていれば誰でもアクセス可能

つまり、ユーザー1の画像を、ユーザー2も見れるわけです。

S3は 「誰がアクセスしているか」を判断しません。

URL = 鍵です。

なぜAPI経由にするのか

S3を非公開にして、こうします。

クライアント → API → S3

APIを挟むことで

このユーザーは見ていい？
ログインしている？
公開フラグはON？

といった業務ロジックを載せることができます。

まとめ

S3はKey-Valueストア
バージョニングは事故対策
ライフサイクルはコスト対策
暗号化は保存時の安全性
非公開にして公開判断はAPIでやる

おわりに

バケット・バージョニング・暗号化・公開設定。
1つずつ見ていくと、どれも「事故を防ぐため」「運用を楽にするため」の仕組みでした。

今回のキャッチアップも、例によってAIにたくさん助けられました。
わからないことをそのままにせず、言語化しながら理解していくことで、「なんかわからんから怖い」が「なるほど」に変わる瞬間はやっぱり楽しいです。

同じようにS3を雰囲気で使っている人の、不安が少しでも減ったら嬉しいです。

アウトプット大事やなぁ

はじめに

今回「バケットをterraformで作る」というタスクをする中でなんやこれが多発しました。

ライフサイクル？古いバージョン？暗号化？？と、一気に謎が湧きました。

この記事では、私がS3をキャッチアップして腑に落ちたポイントをまとめます。

まずはタスクだったバケットから。

バケットとは何か

バケットは、S3における「一番外側の箱」です。
S3のオブジェクト（ファイル）は、必ずどれか1つのバケットに属します。

アクセス制御、暗号化、バージョニング、ライフサイクルなどの設定は、すべて「バケット単位」で適用されます。

つまり、バケットは単なる入れ物ではなく、「セキュリティと運用ルールの境界線」です。

S3はフォルダではない

まず、ここを誤解していました。
S3は「フォルダ構造を持つストレージ」ではないようです。

実態はこれです。

{ key: object }

images/2025/logo.png のようなパスはただの文字列（key） です。

フォルダが存在しているわけではなくUIがそれっぽく見せているだけです。

バージョニング = 上書き時の保険

terraformですがこの設定です。

resource "aws_s3_bucket_versioning" "example" {
   bucket = aws_s3_bucket.example.id
   versioning_configuration {
　　　status = "Enabled"
   }
}

同じkeyにファイルを上書きすると、

最新のもの → current
以前のもの → non-current（古いバージョン）

として残ります。

つまり、上書きしても、前のデータは消えないという仕組みです。

上書きしたら普通に消えると思ってた〜〜〜！！！！

「古いバージョンを消す」ライフサイクルの意味

resource "aws_s3_bucket_lifecycle_configuration" "example" {
  bucket = aws_s3_bucket.example.id

  rule {
    id     = "delete-old-versions"
    status = "Enabled"

    noncurrent_version_expiration {
      noncurrent_days = 30
    }
  }
}

これは、今使われていない過去バージョンだけを30日後に削除するという設定です。

S3の暗号化は「保存時」を守る

resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  bucket = aws_s3_bucket.example.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

png / jpg などの画像も 中身のバイナリがS3内部で暗号化されるそうです。

取得時は自動で復号されるため、アプリ側で何か意識する必要はありません。便利、、

公開設定

S3を直接公開すると、こんな感じになるようです。

https://bucket-name.s3.amazonaws.com/image.png

このURLは、

認証なし
URLを知っていれば誰でもアクセス可能

つまり、ユーザー1の画像を、ユーザー2も見れるわけです。

S3は 「誰がアクセスしているか」を判断しません。

URL = 鍵です。

なぜAPI経由にするのか

S3を非公開にして、こうします。

クライアント → API → S3

APIを挟むことで

このユーザーは見ていい？
ログインしている？
公開フラグはON？

といった業務ロジックを載せることができます。

まとめ

S3はKey-Valueストア
バージョニングは事故対策
ライフサイクルはコスト対策
暗号化は保存時の安全性
非公開にして公開判断はAPIでやる

おわりに

バケット・バージョニング・暗号化・公開設定。
1つずつ見ていくと、どれも「事故を防ぐため」「運用を楽にするため」の仕組みでした。

同じようにS3を雰囲気で使っている人の、不安が少しでも減ったら嬉しいです。

アウトプット大事やなぁ

S3のキャッチアップ

はじめに

バケットとは何か

S3はフォルダではない

バージョニング = 上書き時の保険

「古いバージョンを消す」ライフサイクルの意味

S3の暗号化は「保存時」を守る

公開設定

なぜAPI経由にするのか

まとめ

おわりに

書いた人

目次

S3のキャッチアップ

はじめに

バケットとは何か

S3はフォルダではない

バージョニング = 上書き時の保険

「古いバージョンを消す」ライフサイクルの意味

S3の暗号化は「保存時」を守る

公開設定

なぜAPI経由にするのか

まとめ

おわりに

書いた人

関連記事一覧

バイオリン練習アプリ『Arcoda（アルコーダ）』正式リリース！！

【2026年4月最新】AIのめっちゃいい活用方法20選 — 個人・仕事・開発が一気に変わるベストプラクティス

Claude Codeでブラウザ操作するならPlaywright CLI + skills一択だった

Claude Codeの画像生成SkillsをNano Banana ProからGPT Image 2に置き換えた

Claude Codeの新機能「Routines」で「タスク通知秘書Bot」を作ったら想像以上にやばかった

PRを分割したかっただけなのに、コンフリ地獄になった話

画像生成SKILLを置いておくと何かと便利

そのコンポーネント自律してる？関心の分離で整理してみた

最新の記事

【10章】NextJSでのバックエンド開発演習（前半）の振り返り

バイオリン練習アプリ『Arcoda（アルコーダ）』正式リリース！！

【3章】JavaScript基礎＋演習の振り返り

はじめまして！自己紹介します

【2026年4月最新】AIのめっちゃいい活用方法20選 — 個人・仕事・開発が一気に変わるベストプラクティス

エンジニア志望の主婦が初めてバイブコーディングハッカソンに参加した話

【11章】NextJSでのバックエンド開発演習（後半）の振り返り

ハッカソン、アプリは間に合わなかった。でも、小さな体験できるミニサイトを作った！

目次

最新の記事

【10章】NextJSでのバックエンド開発演習（前半）の振り返り

バイオリン練習アプリ『Arcoda（アルコーダ）』正式リリース！！

【3章】JavaScript基礎＋演習の振り返り

はじめまして！自己紹介します

【2026年4月最新】AIのめっちゃいい活用方法20選 — 個人・仕事・開発が一気に変わるベストプラクティス

エンジニア志望の主婦が初めてバイブコーディングハッカソンに参加した話

【11章】NextJSでのバックエンド開発演習（後半）の振り返り

ハッカソン、アプリは間に合わなかった。でも、小さな体験できるミニサイトを作った！

関連記事一覧

バイオリン練習アプリ『Arcoda（アルコーダ）』正式リリース！！

【2026年4月最新】AIのめっちゃいい活用方法20選 — 個人・仕事・開発が一気に変わるベストプラクティス

Claude Codeでブラウザ操作するならPlaywright CLI + skills一択だった

Claude Codeの画像生成SkillsをNano Banana ProからGPT Image 2に置き換えた

Claude Codeの新機能「Routines」で「タスク通知秘書Bot」を作ったら想像以上にやばかった

PRを分割したかっただけなのに、コンフリ地獄になった話

画像生成SKILLを置いておくと何かと便利

そのコンポーネント自律してる？関心の分離で整理してみた