AWS 15：S3 と CloudFront ― 写真をサーバーの外に置き、世界へ速く配る

S3 は「オブジェクトストレージ」：番号札で預ける、巨大な倉庫

Amazon S3（Simple Storage Service）は、AWS でいちばん古いサービスの1つで、ファイルを預かる倉庫です。

ストレージ（データの置き場）には、大きく3つの種類があります。

オブジェクトストレージは、ファイルを丸ごと預け、名前を言えば丸ごと返してくれる仕組みです。コートを預けて番号札をもらうクロークに似ています。途中を少し書き換えることはできませんが、その代わりに、いくらでも預けられ、どこからでも取り出せます。

写真は「一度投稿したら書き換えず、表示するときは丸ごと読む」ものです。まさにオブジェクトストレージが向いている使い方です。

S3 は VPC（第5章）の中に置くものではなく、リージョンごとに AWS が用意している大きな倉庫です。HTTPS の API で、どこからでも読み書きします（ただし、許された人だけ。後で見ます）。

バケットとキー：倉庫の名前と、荷物の番号札

S3 の言葉を3つ覚えます。

図の左がバケットの中身の例です。uploads/u123/ のように、フォルダがあるように見えますが、実は S3 にフォルダはありません。キー全体が1つの名前で、/ で区切った頭の部分（プレフィックス）が、画面上でフォルダのように見えているだけです。

バケットの名前には決まりがあります。

名前が世界で重ならないように、photolog-photos- の後ろに自分だけの文字を足すのがふつうです。この章では説明のため photolog-photos と書きます。

S3 は、預けたものをまず失くさないように作られている

S3 のいちばんの強みは、預けたものを失くさないことです。

ふつうの（Standard の）S3 は、1つのリージョンの中の複数の AZ（第2章）に、データを分けて保存しています。図のように、AZ が1つ丸ごと止まっても、写真は他の AZ に残っています。

耐久性は「預けたものが失われない確かさ」のことです。9が11個というのは、1000万個のファイルを預けても、平均して1万年に1個失うかどうか、という水準です。

ただし、これは機械の故障から守る話です。第13章の RDS の Multi-AZ と同じで、あなたが間違って消したものは戻りません。間違いに備えるには、バージョニング（上書きや削除をしても古い版を残す設定）を有効にしておく方法があります。消した版も保管料がかかるので、ライフサイクル（後で説明）と組み合わせます。

なお、図の下の注記のとおり、安さと引き換えに1つの AZ だけに置く種類もあります。これも後で見ます。

バケットは公開しない。「ブロックパブリックアクセス」はオンのまま

S3 で起きる情報流出の事故の多くは、S3 が破られたのではなく、バケットを「誰でも読める」設定にしてしまったことが原因です。

そのため、S3 にはブロックパブリックアクセスという安全装置があります。これがオンの間は、どんな設定を書いても、バケットが公開されることはありません。

図では、知らない人が S3 を直接読もうとして、止められています。

「でも、写真はみんなに見せたい。公開しないとどうやって見せるの？」と思うかもしれません。答えは2つあります。

どちらも、バケットは閉じたままです。バケットを公開する必要がある場面は、ほとんどありません。

Web サーバーは IAM ロールで S3 を使う。鍵を置かない

Web サーバーのアプリが S3 を使うには、AWS に「私は使ってよい者です」と示す必要があります。

ここで、アクセスキー（第3章）をアプリの設定ファイルに書くのはやめます。漏れたら誰でもバケットを使えますし、取り替えるのも大変です。

代わりに、EC2 に IAM ロールを付けます（第3章の「ロールをかぶる」考え方）。

図の下の板は、ロールに付けるポリシーの中心部分です。

{
  "Effect": "Allow",
  "Action": ["s3:PutObject", "s3:GetObject"],
  "Resource": "arn:aws:s3:::photolog-photos/*"
}

Resource でバケットを1つに絞り、Action で必要な操作だけを許しています。最小権限（第3章）です。削除（s3:DeleteObject）が必要なら、そのときに足します。

Auto Scaling で増えた Web サーバーも、同じ起動テンプレートから生まれるので、全員が同じロールで S3 を使えます。

写真を Web サーバー経由で S3 に送ると、サーバーが2回運ぶ

置き場が決まったので、投稿の流れを考えます。素直に作ると、図のようになります。

これでも動きますが、困りごとがあります。

写真の中身は、Web サーバーが見る必要のないものです。Web サーバーが知りたいのは「誰が、どの写真を投稿したか」だけです。

だったら、写真は利用者から S3 へ直接送ってもらえばいいはずです。でも、バケットは閉じていて、利用者は S3 に置く権限を持っていません。

そこで使うのが署名付き URLです。

署名付き URL ①：Web サーバーは「置いてよい URL」だけを渡す

署名付き URL（presigned URL）は、「この URL を使えば、この名前で、この期限まで、S3 に置いて（または読んで）よい」という許可証つきの URL です。権限を持つ Web サーバーが、自分の権限で署名して作ります。

図の番号の順に見ます。

2で返すのは小さな文字列だけです。Web サーバーの仕事は一瞬で終わります。

たとえるなら、倉庫の受付（Web）が、「この番号の棚に、今から5分以内なら置いてよい」と書いた入館証を渡すようなものです。受付は荷物を運びません。

署名付き URL は、作るときに AWS へ問い合わせる必要すらありません。Web サーバーが持っているロールの資格で、手元で計算して作れます。だから速く、何枚でも作れます。

次に、利用者がこの URL を使って写真を置くところを見ます。

署名付き URL ②：写真は S3 へ直接。Web は名前だけを DB に書く

続きです。

写真は S3 が直接受け取るので、Web サーバーは写真の大きさに関係なく、小さな文字のやり取りだけで済みます。

4を忘れると、S3 に写真はあるのに、どの投稿の写真かが DB に残りません。反対に、3が失敗したのに4を記録すると、存在しない写真を指す投稿ができます。置けたことを確かめてから記録する順番が大事です。

S3 には、置かれたことを知らせる通知の仕組み（イベント通知）もあります。第24章の非同期の話で、これを使って縮小画像を作ります。

署名付き URL の中身と、守りのための決めごと

Web サーバー（Node.js）で署名付き URL を作るコードは、図の上の板のくらいの短さです。

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";

const s3 = new S3Client({ region: "ap-northeast-1" });
const key = `uploads/${userId}/${crypto.randomUUID()}.jpg`;
const url = await getSignedUrl(
  s3,
  new PutObjectCommand({ Bucket: "photolog-photos", Key: key, ContentType: "image/jpeg" }),
  { expiresIn: 300 }, // 5分で無効
);

署名付き URL は「持っている人なら誰でも使える」許可証です。だから、発行のしかたで守ります。

CORS は、ブラウザが「別の名前のサイトへ送ってよいか」を相手に確かめる仕組みです。フォトログの画面（example.com）から S3 へ送るので、S3 側で https://example.com からの PUT を許す設定を書きます。

ストレージクラス：読む頻度で置き場を分ける

S3 には、料金と性質の違うストレージクラスがあります。オブジェクトごとに選べます。

IA は Infrequent Access（まれにしか読まない）の略です。

考え方は「保管料が安いほど、取り出しが高い・遅い」の天秤です。よく読むものを安いクラスに置くと、取り出し料でかえって高くなります。

どれを選ぶか迷ったら、まず Standard で始め、Cost Explorer（第4章）で S3 の料金が目立ってから見直すので十分です。

ライフサイクル：日数で自動的に移し替え、要らなくなれば消す

ストレージクラスを手で移し替えるのは大変です。S3 にはライフサイクルという規則を書けます。

最後の「途中物」は見落としがちです。大きなファイルは何回かに分けて送る（マルチパートアップロード）ことがあり、途中で止まると、画面の一覧には出ない破片が残って課金され続けます。どのバケットにも付けておくとよい規則です。

図の下の板は、ライフサイクルの規則を JSON で書いた例です。コンソールでは「管理」の画面から同じことを設定できます。

{
  "Rules": [
    { "ID": "originals-to-ia", "Status": "Enabled",
      "Filter": { "Prefix": "uploads/" },
      "Transitions": [ { "Days": 30, "StorageClass": "STANDARD_IA" } ] },
    { "ID": "abort-mpu", "Status": "Enabled",
      "Filter": { "Prefix": "" },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 } }
  ]
}

小さなファイル（目安として128KB 未満）は IA に移しても安くならない決まりがあるので、縮小画像のような小さなものは移さないのが一般的です。

S3 は東京にある。パリの利用者には、遠くて遅い

写真の置き場はできました。次は配り方です。

フォトログの S3 バケットは東京リージョンにあります。東京の利用者にはすぐ届きますが、パリの利用者はどうでしょう。

通信は光の速さで進みますが、地球の反対側まで行って戻るには、どうしても時間がかかります。この往復の時間をレイテンシー（遅延）と呼びます。1回の差は一瞬でも、写真が何十枚も並ぶタイムラインでは、その遅さが積み重なり、「重いサイト」になります。

解決策は、利用者の近くに写しを置いておくことです。1度パリまで運んだら、パリに置いておけば、次のパリの利用者にはすぐ渡せます。

これを世界規模でやってくれる仕組みを CDN（コンテンツ配信ネットワーク）と呼び、AWS の CDN が CloudFront です。

CloudFront：世界中の「エッジ」に写しを置き、近くから配る

Amazon CloudFront は、世界中の数百か所にエッジロケーション（配送の拠点）を持っています。利用者は、自動的に近くのエッジにつながります。

図の流れはこうです。

CloudFront を挟むと、次のことが一度に良くなります。

OAC：S3 は閉じたまま、CloudFront だけに読ませる

CloudFront を通しても、S3 のバケットが公開されていたら、S3 の URL を直接叩けば写真が読めてしまいます。それでは CloudFront の守りも、キャッシュも迂回されます。

そこで OAC（Origin Access Control、オリジンへのアクセスの制御）を使います。

図の下の板は、バケットポリシーの中心部分です。

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::photolog-photos/*",
  "Condition": { "StringEquals": {
    "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEFGHIJKL"
  } }
}

Condition で自分のディストリビューションだけに絞っているのが大事です。これが無いと、他人の CloudFront からでも読めることになります。コンソールで OAC を選ぶと、このポリシーをコピーできるように表示してくれます。

以前は OAI という似た仕組みが使われていました。新しく作るなら OAC を選びます。

キャッシュの期限と、「中身を変えたら名前も変える」

エッジは、写しをいつまで覚えておくのでしょうか。

困るのは、同じ名前のまま中身を変えたときです。エッジは TTL の間、古い写しを返し続けます。無効化すれば消えますが、毎回それをするのは面倒で、お金もかかります。

よい方法は、中身を変えたら名前も変えることです。

フォトログは、投稿ごとに crypto.randomUUID() で新しいキーを作っているので、同じ名前が別の中身になることがありません。だから TTL を長くしても困りません。

なお、特定の人にだけ見せたい写真（鍵付きのアカウントなど）は、CloudFront の署名付き URL・署名付きクッキーで、見てよい人にだけ許可証を渡す方法があります。

作り方：6つの手順で、置き場と配り口ができる

図の番号の順に作ります。

バケットを CLI で作る例です。東京リージョンに作るときは、場所の指定が要ります。

aws s3api create-bucket --bucket photolog-photos \
  --region ap-northeast-1 \
  --create-bucket-configuration LocationConstraint=ap-northeast-1
aws s3api put-bucket-lifecycle-configuration --bucket photolog-photos \
  --lifecycle-configuration file://lifecycle.json

作り終わったら、S3 の URL を直接開くと拒否されること、https://img.example.com/uploads/… なら写真が表示されることを確かめます。CloudFront の設定の変更は、世界中のエッジに行き渡るまで数分かかります。

フォトログでは：投稿は S3 へ直接、表示は CloudFront から

ここまでで、フォトログの通り道は3本に分かれました。

キーの付け方も決めておきます。

一覧の画面では、RDS から写真の s3_key を読み、https://img.example.com/ を頭に付けて画像の URL にします。

これで、写真の出入りから Web サーバーが外れました。Web サーバーは小さな文字のやり取りだけを受け持てばよくなり、少ない台数で多くの利用者をさばけます。Auto Scaling で入れ替わっても、写真は S3 にあるので何も失いません。第12章の「サーバーは使い捨て」が、ようやく完全に成り立ちました。

お金：置いた量、呼んだ回数、外へ出した量

S3 と CloudFront の料金は、主に次のものに対してかかります。

2025年からは、CloudFront に定額プラン（Free・Pro など）も選べるようになりました。CDN・WAF・DNS などがまとめて月額に含まれ、アクセスが急に増えても追加料金が出ない形です。趣味や小さなサービスでは、料金を読みやすくする選択肢になります。

いちばん気をつけるのは外への転送です。写真や動画のサービスでは、保管料より配信の料金が大きくなりがちです。CloudFront でキャッシュを効かせ、縮小画像を使って運ぶ量そのものを減らします。

単価・無料枠・定額プランの中身は変わるので、料金ページで確かめてください。

よくある落とし穴

S3 の事故の多くは、「公開してしまった」と「消えるはずのものが残った」のどちらかです。

もう1つ、S3 のバケットを同じ名前で作り直そうとして作れない、という戸惑いもよくあります。従来のバケット名は世界で1つなので、消した直後の名前がしばらく使えなかったり、他人に取られたりします。名前はあまり使い回さないのが無難です。

片付け：CloudFront を止めて消し、バケットは空にしてから消す

片付けにはそれぞれ順番があります。

CLI で中身ごと消す例です（本当に消えてよいか、バケット名を必ず確かめてから）。

aws s3 rm s3://photolog-photos --recursive
aws s3api delete-bucket --bucket photolog-photos

バージョニングを有効にしていた場合、ふつうの削除では古い版が残るので、コンソールの「空にする」を使うか、古い版も消します。

最後に確かめること。