CloudFront 入門 — CDN の基本と設定

概要

Amazon CloudFront は AWS が提供する CDN（Content Delivery Network）です。世界中に配置されたエッジロケーションを通じてコンテンツをユーザーに近い場所から配信し、レイテンシの削減とオリジンサーバの負荷軽減を実現します。本記事では、CDN の基本から CloudFront の主要な構成要素、S3 を使った最小構成の作成までを入門者向けに整理します。

CDN とは何か

CDN は、コンテンツの大元（オリジン）とユーザーの間に「キャッシュ用の中継サーバ群」を挟む仕組みです。

• オリジン（Origin）: コンテンツの大元。S3 バケットや ALB、独自の HTTP サーバなど
• エッジロケーション（Edge Location）: 世界各地に分散配置されたキャッシュサーバ
• キャッシュ（Cache）: 一度取得したコンテンツをエッジに保持し、次回以降はオリジンに問い合わせず返す

ユーザーは地理的に最も近いエッジロケーションに接続されるため往復距離が短くなり、体感速度が向上します。キャッシュヒット時はオリジンへリクエストが届かないため、オリジンの負荷とデータ転送量も抑えられます。

CloudFront の主要な構成要素

ディストリビューション（Distribution）

設定の最上位単位です。「どのオリジンから」「どのような条件で」「どう配信するか」をまとめて管理します。作成すると dxxxxxxxxxxxxx.cloudfront.net のようなドメイン名が払い出されます。

オリジン（Origin）

配信元の指定です。S3 バケット（静的サイトや画像・動画）、ALB / EC2 / 独自オリジン（動的コンテンツや API）などを指定できます。

ビヘイビア（Cache Behavior）

パスパターン（例: /images/*、/api/*）ごとに、振り分け先オリジン・キャッシュポリシー・許可する HTTP メソッドなどを設定します。デフォルトビヘイビアが1つ必ず存在し、追加のビヘイビアで細かく制御します。

キャッシュポリシー（Cache Policy）

キャッシュキーに含める要素（クエリ文字列・ヘッダー・Cookie）と TTL を定義します。AWS 管理のポリシー（CachingOptimized / CachingDisabled など）から始めるのが手軽です。

S3 + CloudFront の最小構成

1. バケットは公開しない

配信対象を S3 に置く際、バケットは公開せず、CloudFront だけがアクセスできるようにするのが推奨構成です。これを実現するのが OAC（Origin Access Control）です。従来の OAI は後継の OAC へ移行が推奨されています。

2. OAC で S3 を保護

S3 バケットポリシーで、特定の CloudFront ディストリビューションからのアクセスのみを許可します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipal",
      "Effect": "Allow",
      "Principal": { "Service": "cloudfront.amazonaws.com" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EXXXXXXXXXXXXX"
        }
      }
    }
  ]
}

3. ディストリビューション作成時の主な設定

• Origin domain: 対象の S3 バケット
• Origin access: Origin access control settings（OAC を新規作成）
• Viewer protocol policy: Redirect HTTP to HTTPS
• Cache policy: CachingOptimized
• Default root object: index.html

キャッシュ無効化（Invalidation）

ファイルを更新したのに古い内容が返るのは、エッジにキャッシュが残っているためです。強制的に破棄するには Invalidation を実行します。

# 全パスを無効化
aws cloudfront create-invalidation \
  --distribution-id EXXXXXXXXXXXXX \
  --paths "/*"

# 対象を絞る（推奨）
aws cloudfront create-invalidation \
  --distribution-id EXXXXXXXXXXXXX \
  --paths "/index.html" "/css/style.css"

Invalidation は月あたり一定数まで無料で、超過分は課金対象です。毎回 "/*" を打つより、更新パスを絞るか、ファイル名にハッシュを付ける運用（キャッシュバスティング）が定石です。

確認方法

レスポンスヘッダーでキャッシュの挙動を確認できます。

curl -I https://dxxxxxxxxxxxxx.cloudfront.net/index.html

HTTP/2 200
x-cache: Hit from cloudfront
age: 42

• Hit from cloudfront … エッジのキャッシュから返された
• Miss from cloudfront … オリジンまで取りに行った
• age … キャッシュされてからの経過秒数

初回は Miss、TTL の間は Hit になるのが基本の動きです。

注意点

• 設定変更の伝播に時間がかかる: 全エッジへの反映まで数分かかることがあります。即時反映を期待しないこと。
• ACM 証明書のリージョン: 独自ドメイン + HTTPS を使う場合、ACM 証明書は バージニア北部（us-east-1） で発行する必要があります。
• 動的コンテンツのキャッシュ事故: ログイン後ページや API を安易にキャッシュすると情報が混ざります。動的パスは CachingDisabled にするか、キャッシュキーにヘッダー/Cookie を適切に含めます。
• コスト: 主な課金対象はデータ転送量・リクエスト数・Invalidation 超過分です。

まとめ

• CloudFront はエッジロケーションからコンテンツを配信する CDN
• 構成の基本は「オリジン → ディストリビューション → ビヘイビア / キャッシュポリシー」
• S3 配信ではバケット非公開 + OAC が推奨構成
• 反映されないときはキャッシュ（TTL / Invalidation）を疑う
• HTTPS 用の ACM 証明書は us-east-1 で発行する

まずは S3 + OAC の最小構成で動かし、x-cache ヘッダーでキャッシュの挙動を観察するところから始めるのがおすすめです。