【AWS】速くなるCDN、で結局いつ使うの？をS3とCloudFrontで整理してみた

はじめに

AWSをTerraformで触るハンズオンをやっていて、S3のところで「バケットにHTMLファイルを置いたら、そのままインターネットに公開できるの？」という素朴な疑問が湧きました。調べていくと芋づる式に出てくるのが CloudFront、いわゆる CDN です。名前はよく聞くけれど、自分の解像度は「なんか速くなるやつ」くらい。この記事は、そこから「で、結局いつ使うの？」に自分の言葉で答えられるようになるまでを整理したものです。

参考リンク

3行でまとめると（忙しい人向け）

問い	答え
CDNって何？	世界中に置いたキャッシュ拠点から、ユーザーに一番近い場所で配信して速くする仕組み
いつ使う？	「同じ・重い・よく見られる」コンテンツを配るとき。静的サイト／画像／動画が典型
いつ要らない？	ユーザーごとに毎回中身が変わる・リアルタイム性が命・小規模で一拠点、のとき

読了目安は6〜7分です。AWSの用語は出てきますが、CDNの考え方そのものはどのクラウドでも共通なので、AWSを触っていない人でも読めるようにしています。

対象読者

• S3やCloudFrontの名前は知っているけれど、両者の関係がふわっとしている人
• 「CDN＝速くなるやつ」で理解が止まっている人
• いつCDNを入れるべきか、自分で判断できるようになりたい人

発端は「S3にHTMLを置いたら公開できるの？」

結論から言うと、できます。S3はHTML・CSS・JS・画像といった静的ファイルなら、サーバーを立てずにWebサイトとして公開できます。「静的ウェブサイトホスティング」という機能で、S3の代表的な使い方のひとつです。

S3はデフォルトで全部が非公開。公開したいなら、こちらから明示的に許可してあげる必要があります。

S3だけで公開する方法と、その"限界"

S3だけで公開する場合、許可は2段構えになっています。ここが最初の小さなハマりどころでした。設定が1か所だと思い込んでいたので、「なんで2回も許可するの？」と混乱したんです。

設定	役割
ブロックパブリックアクセス	バケット単位の「そもそも公開を禁止するガード」。まずこれを外す
バケットポリシー	「どのファイルを誰に公開するか」を実際に許可するJSONルール

たとえば「全員に読み取りを許可する」バケットポリシーはこんな形です。

bucket-policy.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicRead",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-public-bucket/*"
    }
  ]
}

Principal が *、つまり「世界中の誰でも」です。この2つが揃ってはじめて公開されます。片方だけだとアクセスしても 403 Forbidden で弾かれます。

公開バケットは世界中の誰でも読めます。Principal: "*" は本当に公開してよい静的ファイル専用のバケットにだけ使ってください。うっかり機密ファイルを同じバケットに置くと、それも全世界に見えます。S3の情報漏洩事故の典型がこれです。

そして、この「S3だけ公開」方式には限界があります。

• 独自ドメインでのHTTPS配信ができない（静的ウェブサイトホスティングのエンドポイントはHTTPS非対応。独自ドメインでHTTPS化したいならCloudFrontが要る）
• キャッシュがないので、遠い地域からのアクセスは遅い
• S3そのものがインターネットに直接さらされる

この「もっと速く、HTTPSで、S3は隠したまま配りたい」という欲が出てきたところで登場するのが CloudFront、CDNです。

CDNって結局なに？

CDN（Content Delivery Network）は、オリジン（大元の配信元。今回はS3）のコピーを世界中の拠点にキャッシュしておき、ユーザーに一番近い拠点から返す仕組みです。CloudFrontはAWSのCDNサービスで、この「世界中の拠点」を750カ所以上持っています。

言葉より図が早いので描きました。同じ「東京のS3にある画像を、ブラジルのユーザーが見る」状況を、CDNなし／ありで並べたものです。

CDNなしだと、リクエストのたびに地球の裏側まで往復します。重い画像や動画ほど、この距離がそのまま遅さになります。

CDNありだと、ユーザーの近くにあるエッジロケーション（キャッシュ拠点）が返してくれます。初回だけオリジンから取ってきてキャッシュし、2回目以降はエッジが即座に返す。だから速いし、オリジンへのアクセスもごっそり減ります。

Netflixの動画が地球の裏側でも普通に再生できるの、なんでだと思いますか？ 答えのかなりの部分がこれです。各国のエッジに動画を配ってあるから、ユーザーは「近所のコンビニ」から受け取っているようなものなんです。

CDNが解決してくれること

キャッシュによる高速化がまず目立ちますが、CloudFrontがやってくれるのはそれだけではありません。

できること	ざっくり中身
高速化	ユーザーに近いエッジ＋キャッシュで応答が速い
HTTPS対応	S3単体では難しいHTTPS配信ができる（ACM証明書1と連携）
独自ドメイン	www.example.com のような自分のドメインで配れる
オリジン保護	S3を非公開のままにして、CloudFront経由だけに絞れる
オリジン負荷の軽減	エッジがキャッシュで肩代わりし、オリジンへのアクセス回数が減る
セキュリティ	AWS WAFやDDoS防御（AWS Shield）と組み合わせられる

腹落ちした瞬間 ―― デジタルサイネージはCDNの塊だった

ここまでで仕組みは分かったものの、「で、自分がいつ使うのか」はまだピンときていませんでした。腑に落ちたのは、身近な例に引きつけて考えたときです。

駅や店頭にあるデジタルサイネージ（電子看板）。あれを管理するCMSって、全国・世界中に散らばった大量の表示端末に、同じ画像や動画を配り続ける仕組みですよね。……これ、CDNの説明そのままじゃないか、と一人で膝を打ちました。

• 配るものは全端末で同じ（＝キャッシュがめちゃくちゃ効く）
• 端末は地理的にバラバラ（＝近くのエッジから配りたい）
• 画像や動画で重い（＝距離が遅さに直結する）
• 台数ぶんアクセスが来る（＝オリジンに直で来たら負荷で潰れる）

CDNが得意な条件が、全部そろっているんです。逆に言うと、サイネージCMSをCDNなしで作ったら、端末台数ぶんのアクセスがオリジンに集中して、コストも遅延も跳ね上がる。「CDNを使わないと厳しい」という発想に、ようやく自分の中でつながりました。

同じ理屈で、動画配信・ゲームやアプリの配布・地図タイル・eラーニング教材なども、軒並みCDN前提です。「多数のクライアントに、共通の重いコンテンツを、繰り返し配る」――このパターンを見たらCDN、と覚えておくと応用が効きます。

じゃあ、どんなときに使う？

腹落ちした条件を、もう少し一般化してユースケースの表にしてみます。

向いている配信	なぜ効くか
静的サイト・LP	全員が同じ中身＝キャッシュしやすい
画像・動画・大容量ファイル	重いものを近くから返せて、効果が最大
グローバル展開したサービス	各地のエッジで遅延を抑えられる
アクセス集中・急増（バズ・キャンペーン）	エッジが肩代わりしてオリジンを守る
アプリ・ソフトの配布	同じ大容量を世界中へ配れる
SPA（React／Vueなど）	ビルド済みの静的アセット配信の定番構成

動画について少しだけ補足すると、実は「1本の巨大ファイルをそのまま配る」わけではありません。数秒ごとの小さなセグメントに分割して順に配信します（HLSやDASHという方式）。この小さなセグメントは一つひとつが静的ファイルなので、CDNでキャッシュし放題。つまり動画配信の実体は「大量の小さな静的ファイル配信」で、CDNと本質的に相性がいいんです。

逆に、CDNが向かないケース

万能ではありません。むしろ「入れても効かない」場面を知っておくほうが、判断がぶれなくなります。

次のようなケースは、CDNの主役である「キャッシュ」が効きにくい（場合によっては足かせになる）ので注意。

• ユーザーごとに毎回中身が変わる：ログイン後のマイページ、口座残高など。キャッシュがほぼ効かない
• リアルタイム性が命：株価のtick、チャットのメッセージなど。古いキャッシュを返すと事故になる
• 小規模で利用者も一拠点に固まっている社内ツール：効果が薄く、コストと手間に見合わないことがある

ただ実務では「全部CDN」か「全部オリジン」かの二択ではありません。動的なサイトでも、画像・CSS・JSといった静的な部分だけCDNに乗せる使い分けが一般的ですし、キャッシュが効かない動的リクエストでも、TLSの終端やWAF・DDoS対策、AWSバックボーン経由の接続最適化をねらってCloudFrontを前段に置くこともあります。「キャッシュ目的では向かないが、CDNそのものが無意味というわけではない」くらいの温度感が正確です。全か無かで考えなくて大丈夫、というのは自分にとって安心材料でした。

まとめ：CDNは「速くて安全な受付係」

長くなったので、自分の頭に残った形でまとめます。

CDN＝「同じ重いファイルを、世界中に、何度も」届けるための、速くて安全な受付係。

• S3だけでも静的サイトは公開できる。ただしHTTPSや速度、セキュリティに限界がある
• CloudFront（CDN）は、近くのエッジ＋キャッシュで速くし、HTTPS・独自ドメイン・オリジン保護までまとめて面倒を見てくれる
• 効くのは「同じ・重い・よく見られる」コンテンツ。サイネージCMSや動画配信はその典型
• 向かないのは「ユーザーごとに変わる／リアルタイム／小規模一拠点」
• AWSの定番は S3（非公開）＋ CloudFront ＋ OAC

次は実際にTerraformで S3 + CloudFront を組んで、レスポンスヘッダの X-Cache: Hit from cloudfront でキャッシュが効いている様子を確認してみるつもりです。組めたら続編を書きます。

あなたがいま触っているサービス、「同じ重いものを、たくさんの人に、繰り返し」配っていませんか？ もしそうなら、それはCDNの出番かもしれません。もし試したら、どんな構成にしたか教えてもらえると嬉しいです。

1. AWS Certificate Manager。SSL/TLS証明書を発行・自動更新してくれるサービス。CloudFrontと組み合わせるとHTTPS化が驚くほど簡単になります。 ↩