S3のキャッチアップ

S3のキャッチアップ

公開: 2025年12月12日

Tips
要約
  • AWS S3は静的ファイルを保存するだけでなく、バケット単位でのセキュリティや運用ルールを管理する重要なストレージサービスである。
  • バージョニング機能で上書き時の事故を防ぎ、ライフサイクル設定で古いバージョンを自動的に削除可能で、暗号化機能で保存時のデータ保護を実現する。
  • 公開設定ではAPIを挟むことでアクセス制御を行い、運用を楽にする仕組みが整っている。
音声で記事を再生
0:00

はじめに

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を雰囲気で使っている人の、不安が少しでも減ったら嬉しいです。

アウトプット大事やなぁ

シェア!

XThreads
ShiftB Logo
user
吉本茜
山口在住/二児の母/エンジニア
Loading...
記事一覧に戻る
XThreads
0