2026年9月12日

AWS CloudFrontでCDNを設定する方法：S3オリジン・独自ドメイン・キャッシュ設定

VPS・クラウド

Amazon CloudFrontは、AWSのCDN（コンテンツ配信ネットワーク）です。世界各地のエッジロケーションにファイルをキャッシュし、利用者に近い場所から返すことで、表示を速くし、元のサーバー（オリジン）の負荷を減らします。この記事では、S3バケットに置いた画像やCSSなどの静的ファイルをCloudFrontで配信する構成を例に、ディストリビューションの作成から独自ドメインの設定、キャッシュの管理までを説明します。

AWSの画面の項目名や作成画面の構成は、ときどき変わります。この記事の内容は2026年10月時点のAWS公式ドキュメントに基づいています。料金はデータ転送量やリクエスト数などで決まるため、AWSの料金ページで確認してください。

全体の構成

オリジン：CloudFrontがファイルを取りに行く元。ここではS3バケット
ディストリビューション：CloudFrontの配信設定の単位。作成すると d111111abcdef8.cloudfront.net のようなドメイン名が割り当てられる
キャッシュビヘイビア：URLのパスごとに、どのオリジンを使い、どうキャッシュするかを決める設定
オリジンアクセスコントロール（OAC）：S3バケットを公開せず、CloudFrontからだけ読めるようにする仕組み

S3バケットは、ブロックパブリックアクセスを有効にした非公開のまま使います。バケットの作り方は AWS S3でファイルストレージを設定する方法を参照してください。

ステップ1：ディストリビューションを作成する

CloudFrontコンソールで「ディストリビューションを作成」を選び、次の項目を設定します。

項目	設定
オリジンドメイン	一覧からS3バケットを選ぶ（`バケット名.s3.リージョン.amazonaws.com` の形）
オリジンアクセス	「Origin access control settings (recommended)」を選び、OACを作成または選択する
ビューワープロトコルポリシー	「Redirect HTTP to HTTPS」（HTTPのアクセスをHTTPSに転送）
許可されたHTTPメソッド	静的ファイルの配信なら「GET, HEAD」
キャッシュポリシー	`CachingOptimized`（後述）
代替ドメイン名（CNAME）	独自ドメインで配信する場合に設定（ステップ3）
カスタムSSL証明書	独自ドメインを使う場合に、ACMの証明書を選ぶ（ステップ3）

S3の「静的ウェブサイトホスティング」のエンドポイント（s3-website を含むドメイン）をオリジンにすると、カスタムオリジン扱いになり、OACは使えません。非公開のバケットから配信する場合は、通常のS3のドメインを選びます。

作成が終わると、状態が「デプロイ中」になり、すべてのエッジロケーションに設定が反映されると、最終更新日時が表示されます。

ステップ2：S3バケットにCloudFrontからの読み取りを許可する

OACを使う場合、S3バケットのバケットポリシーで、そのディストリビューションからの読み取りだけを許可します。コンソールの作成画面に、コピー用のポリシーが表示されることがあります。公式ドキュメントの例は次のとおりです。バケット名、AWSアカウントID（12桁）、ディストリビューションIDは自分のものに置き換えます。

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

このポリシーは「CloudFrontのサービスが、指定したディストリビューションのためにアクセスする場合だけ」読み取りを許可します。バケットそのものは公開されないため、S3のURLを直接開いてもファイルは表示されません。

OACの署名の設定は、既定の「Sign requests (recommended)」のままにします。公式ドキュメントでは、OACを使うにはS3のオブジェクト所有者を「バケット所有者の強制」（ACL無効。新しいバケットの既定値）にする必要があると説明されています。以前の方式であるオリジンアクセスアイデンティティ（OAI）は、新しく設定する場合は使わず、OACを選びます。

設定後、CloudFrontのドメインで表示を確かめます。

curl -I https://d111111abcdef8.cloudfront.net/images/sample.png

HTTP/2 200 と、x-cache: Miss from cloudfront（1回目）、x-cache: Hit from cloudfront（2回目以降）のような応答ヘッダーが返れば、CloudFront経由で配信されています。403 が返る場合は、バケットポリシーの AWS:SourceArn のディストリビューションIDとアカウントID、オリジンにOACが設定されているかを確認します。

ステップ3：独自ドメインとSSL証明書を設定する

static.example.com のような独自ドメインで配信するには、証明書と代替ドメイン名、DNSの3つを設定します。

1. ACMで証明書を取得する

AWS Certificate Manager（ACM）で、公開証明書をリクエストします。CloudFrontで使う証明書は、米国東部（バージニア北部）リージョン（us-east-1） でリクエストする必要があります。東京リージョンで取得した証明書は、CloudFrontの選択肢に表示されません。

検証方法にDNS検証を選ぶと、ACMが指定するCNAMEレコードを、ドメインのDNSに追加することで発行されます。ACMで発行した証明書は、ACMが自動で更新します。

2. ディストリビューションに代替ドメイン名と証明書を設定する

ディストリビューションの「一般」タブの設定を編集し、「代替ドメイン名（CNAME）」に static.example.com を、「カスタムSSL証明書」にACMの証明書を設定します。CloudFrontは、追加する代替ドメイン名が証明書の対象（サブジェクト代替名）に含まれているかを確認するため、証明書がそのドメイン名か、同じ階層のワイルドカード（*.example.com）を含んでいる必要があります。

3. DNSでCloudFrontに向ける

DNSに、独自ドメインからCloudFrontのドメインへのレコードを作ります。

static.example.com.  CNAME  d111111abcdef8.cloudfront.net.

example.com のようなルートドメイン（ゾーンの頂点）にはCNAMEを置けないため、Route 53のエイリアスレコードや、DNS事業者のALIAS・CNAMEフラット化の機能を使います。詳しくは CDN導入時のDNS設定：ルートドメインのCNAME問題を参照してください。

ステップ4：キャッシュポリシーを選ぶ

キャッシュポリシーは、何をキャッシュのキー（同じファイルとみなす条件）にするか、どれくらいの時間キャッシュするか（TTL）を決めます。AWSが用意している管理ポリシーのうち、よく使うものは次のとおりです。

ポリシー名	内容	向いている用途
`CachingOptimized`	クエリ文字列・Cookieをキーに含めない。既定TTL 24時間、最小1秒、最大365日。圧縮に対応	S3の画像・CSS・JavaScriptなどの静的ファイル
`CachingDisabled`	キャッシュしない（TTLはすべて0）	管理画面やログイン後のページなど動的な内容
`UseOriginCacheControlHeaders`	オリジンの `Cache-Control` ヘッダーに従う。既定TTL 0	キャッシュ時間をオリジン側で決めたい場合
`UseOriginCacheControlHeaders-QueryStrings`	上に加えて、クエリ文字列をキーに含める	クエリ文字列で内容が変わるオリジン

CachingOptimized は最小TTLが1秒のため、オリジンが Cache-Control: no-cache などを返しても、最低1秒はキャッシュされます。キャッシュしてはいけない内容には CachingDisabled を使います。

パスごとに扱いを変えたい場合は、「ビヘイビア」タブでキャッシュビヘイビアを追加します。たとえば、/images/* は CachingOptimized、/api/* は CachingDisabled のように、パスパターンごとにポリシーを設定できます。オリジンに転送するヘッダーやCookie、クエリ文字列は、キャッシュポリシーとは別の「オリジンリクエストポリシー」で指定します。

ステップ5：ファイルを更新したときのキャッシュの削除

S3のファイルを差し替えても、CloudFrontのキャッシュはTTLが切れるまで古いまま残ります。すぐに反映したい場合は、キャッシュを無効化（インバリデーション）します。

# 特定のファイル
aws cloudfront create-invalidation --distribution-id EDFDVBD6EXAMPLE --paths "/css/style.css"

# /images/ 以下すべて（* はパスの最後にだけ書ける）
aws cloudfront create-invalidation --distribution-id EDFDVBD6EXAMPLE --paths "/images/*"

無効化は、月ごとに一定数のパスまでは無料で、それを超えると料金がかかります。公式ドキュメントでは、頻繁に更新するファイルには、無効化よりも style.v2.css や style.css?ver=2 のように名前やURLを変える方法（バージョン付きのファイル名）が推奨されています。ブラウザや社内のプロキシに残ったキャッシュにも影響されないためです。なお、クエリ文字列で区別する方法は、キャッシュポリシーでクエリ文字列をキーに含めている場合にだけ効きます。

ステップ6：ログと監視

メトリクス：CloudFrontコンソールの「モニタリング」で、リクエスト数、転送量、4xx・5xxのエラー率を確認できます。CloudWatchで見る場合、CloudFrontのメトリクスは米国東部（バージニア北部）リージョンにあります
アラーム：CloudWatchアラームで、5xxのエラー率が一定を超えたら通知するように設定できます
アクセスログ：標準ログ（v2）では、ログの送信先としてCloudWatch Logs、Amazon Data Firehose、S3を選べます。以前からの標準ログ（レガシー）はS3にだけ送れます。公式ドキュメントでは、標準ログはベストエフォートで配信され、まれに欠けることがあるとされています。数秒で届くリアルタイムログもあります

エラーが増えたときは、ログの x-edge-result-type（Hit・Miss・Error など）やステータスコードを見て、CloudFront側の問題か、オリジン側の問題かを切り分けます。カスタムオリジンのSSL証明書に、CloudFrontに設定したオリジンのドメイン名が含まれていないと 502 が返るなど、ステータスコードから原因の見当がつくこともあります。

WordPressのサイト全体をCloudFrontで配信する場合

WordPressのサーバーをカスタムオリジンにしてサイト全体を配信する場合は、静的ファイルとは考え方が変わります。

管理画面（/wp-admin/*）やログイン画面（/wp-login.php）は CachingDisabled にし、Cookieやヘッダーをオリジンに転送する
公開ドメインをCloudFrontに向けるため、オリジンには origin.example.com のような別のホスト名を用意する
ログイン中のユーザーやコメント投稿者に、キャッシュしたページを返さないようにする

具体的なビヘイビアの組み方は WordPressのCloudFront設定：キャッシュ動作とカスタムオリジンの組み立て方で、導入後によくある不具合は AWS CloudFront導入後にWordPressで起きやすいトラブル事例で説明しています。

まとめ

S3バケットは非公開のまま、オリジンアクセスコントロール（OAC）とバケットポリシーでCloudFrontからだけ読めるようにする
独自ドメインには、us-east-1 で取得したACMの証明書、代替ドメイン名、DNSのCNAME（ルートドメインはエイリアスなど）が必要
静的ファイルは CachingOptimized、動的な内容は CachingDisabled を基本に、パスごとにビヘイビアを分ける
更新の反映は、頻繁なものはバージョン付きのファイル名、急ぎのものはインバリデーションで行う
メトリクス、アラーム、標準ログで、エラー率とキャッシュのヒット状況を確認する