オンプレミスの環境で運用しているWebサーバーが、突然のアクセス集中でレスポンスが遅くなった経験はないでしょうか。「ロードバランサーの後ろにWebサーバーを増やして……」と対処してきたエンジニアにとって、CDN（Content Delivery Network）は馴染みのある概念のはずです。ただ、Akamaiなどの商用CDNは導入コストや契約の敷居が高く、結局キャッシュサーバーを自前で立てていた、という方も多いのではないでしょうか。

AWSのCDNサービスであるAmazon CloudFrontは、世界600か所以上のエッジロケーションにコンテンツをキャッシュし、ユーザーに最も近い場所からレスポンスを返す仕組みです。S3やEC2、ALBなどAWSサービスとの連携が特に強力で、数クリックでグローバル配信を始められます。

この記事では、Amazon CloudFrontの基本概念からディストリビューションの作成手順、キャッシュ戦略、料金体系まで、オンプレ経験者の視点で体系的に解説します。CDNの導入を検討している方はもちろん、すでにCloudFrontを使っているがキャッシュ設計を見直したい方にも役立つ内容です。

Amazon CloudFrontとは？オンプレのキャッシュサーバーとの違い

Amazon CloudFrontは、AWSが提供するCDN（Content Delivery Network）サービスです。オンプレミスでいえば、Varnishやnginxリバースプロキシをデータセンターに設置していたのと同じ役割ですが、そのキャッシュサーバーが世界中に分散配置されていると考えてください。

オンプレのキャッシュ構成との違いを整理しておきましょう。

CloudFrontの大きなメリットは、オリジンサーバー（S3やEC2）への負荷を劇的に減らせる点です。静的コンテンツ（画像、CSS、JavaScript）をエッジにキャッシュすれば、オリジンへのリクエストは初回アクセス時だけ。あとはエッジロケーションがレスポンスを返すため、オリジンサーバーのスペックを抑えてコスト削減にもつながります。

CloudFrontの基本的な仕組み

CloudFrontの動作を理解するために、主要な構成要素を押さえておきましょう。

1. ディストリビューション

ディストリビューションは、CloudFrontの設定単位です。「どのオリジンから」「どんなルールで」「どこに配信するか」を定義します。1つのWebサイトやアプリケーションに対して1つのディストリビューションを作成するのが基本です。

2. オリジン

コンテンツの配信元となるサーバーやストレージです。CloudFrontでよく使われるオリジンは以下のとおりです。

・Amazon S3バケット: 静的サイトホスティング、画像・動画・ダウンロードファイルの配信
・ALB（Application Load Balancer）: 動的コンテンツを生成するWebアプリケーション
・EC2インスタンス: ALBを経由せず直接EC2をオリジンにする構成（小規模向け）
・カスタムオリジン: AWS外の任意のHTTPサーバー（オンプレのサーバーも指定可能）

オンプレのリバースプロキシでいう「proxy_pass」や「backend」の設定先がオリジンに相当します。

3. エッジロケーションとリージョナルエッジキャッシュ

ユーザーからのリクエストは、まず最寄りのエッジロケーションに到達します。キャッシュがあればそこから直接レスポンスを返し（キャッシュヒット）、なければリージョナルエッジキャッシュを確認、それでもなければオリジンに取りに行きます。

この2層キャッシュ構造により、オリジンへのリクエストが大幅に減ります。日本のユーザーがアクセスした場合、東京のエッジロケーションまたは大阪のエッジロケーションからレスポンスが返るため、レイテンシーも最小限です。

ディストリビューションの作成手順

S3バケットに静的ファイルを置いてCloudFrontで配信する、最も基本的な構成を作ってみましょう。

1. S3バケットの準備

まず、配信するコンテンツを格納するS3バケットを作成します。CloudFront経由でアクセスする場合、S3の「静的ウェブサイトホスティング」を有効にする必要はありません。OAC（Origin Access Control）を使えば、S3バケットへの直接アクセスをブロックしつつ、CloudFront経由のみ許可する構成が作れます。

# S3バケットの作成（東京リージョン）
aws s3 mb s3://my-website-assets-2026 --region ap-northeast-1

# テスト用のHTMLファイルをアップロード
echo "
Hello from CloudFront
" > index.html
aws s3 cp index.html s3://my-website-assets-2026/index.html \
  --content-type "text/html"

2. CloudFrontディストリビューションの作成

AWS CLIでディストリビューションを作成する場合、設定をJSONファイルで定義します。

# AWS CLI でディストリビューションを作成
aws cloudfront create-distribution \
  --origin-domain-name my-website-assets-2026.s3.ap-northeast-1.amazonaws.com \
  --default-root-object index.html

実際の運用では、AWSマネジメントコンソールから作成するのが最も手軽です。手順を整理しておきましょう。

・手順1: CloudFrontコンソールを開き「ディストリビューションを作成」をクリック
・手順2: オリジンドメインにS3バケットを選択
・手順3: OAC（Origin Access Control）を新規作成してS3へのアクセスを制限
・手順4: デフォルトルートオブジェクトに「index.html」を入力
・手順5: キャッシュポリシーは「CachingOptimized」を選択（静的コンテンツ向け）
・手順6: 「ディストリビューションを作成」をクリック

作成後、数分でデプロイが完了し、「d1234abcdef.cloudfront.net」のようなドメイン名が割り当てられます。このURLにアクセスすれば、S3に置いたコンテンツがCloudFront経由で配信されます。

3. OAC（Origin Access Control）の設定

OACは、CloudFrontからS3へのアクセスを安全に制御する仕組みです。以前はOAI（Origin Access Identity）が使われていましたが、現在はOACが推奨されています。

OACを設定すると、S3バケットポリシーに以下のようなステートメントが追加されます。

# S3バケットポリシー（CloudFront OAC用）
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-website-assets-2026/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1234ABCDEF"
                }
            }
        }
    ]
}

これにより、S3バケットへの直接アクセス（S3のURLを叩くアクセス）はブロックされ、必ずCloudFront経由でのみコンテンツが配信されるようになります。

キャッシュ戦略の設計

CloudFrontのキャッシュ設計は、パフォーマンスとコンテンツの鮮度のバランスを取る作業です。オンプレでnginxのproxy_cache_validやVarnishのTTLを設定していたのと同じ考え方ですが、CloudFrontにはAWS独自の仕組みがあります。

1. キャッシュポリシー

CloudFrontでは「キャッシュポリシー」でTTL（キャッシュ保持期間）やキャッシュキーの構成を定義します。AWSが事前に用意しているマネージドポリシーを使うのが最も手軽です。

静的コンテンツと動的コンテンツを同じディストリビューションで配信する場合は、パスパターンごとにキャッシュポリシーを使い分けます。たとえば「/images/*」と「/css/*」にはCachingOptimized、「/api/*」にはCachingDisabledを設定する、という具合です。

2. キャッシュの無効化（Invalidation）

コンテンツを更新したのにユーザーに古いバージョンが表示される——これはCDN運用でよくある問題です。CloudFrontでは「Invalidation（無効化）」リクエストを送ることで、エッジのキャッシュを強制的にクリアできます。

# 特定ファイルのキャッシュを無効化
aws cloudfront create-invalidation \
  --distribution-id E1234ABCDEF \
  --paths "/index.html" "/css/style.css"

# ディレクトリ単位の無効化
aws cloudfront create-invalidation \
  --distribution-id E1234ABCDEF \
  --paths "/images/*"

# 全キャッシュの無効化（コストに注意）
aws cloudfront create-invalidation \
  --distribution-id E1234ABCDEF \
  --paths "/*"

ただし、Invalidationは月1,000パスまで無料、それ以降は1パスあたり/bin/bash.005が課金されます。頻繁にファイルを更新する場合は、ファイル名にバージョン番号やハッシュを含める「Cache Busting」戦略（例: style.v2.css、app.abc123.js）のほうがコスト効率が良く、運用も安定します。

3. カスタムヘッダーによるキャッシュ制御

オリジン側でCache-Controlヘッダーを設定することで、CloudFrontのキャッシュ動作を細かく制御できます。

・max-age=31536000, immutable: バージョニングされた静的ファイル（例: app.abc123.js）に最適。1年間キャッシュし、Revalidationリクエストも飛ばさない
・max-age=0, s-maxage=86400: ブラウザキャッシュは無効だがCDNには24時間キャッシュ。HTMLファイルに適している
・no-cache, no-store: キャッシュ完全無効。ログインページや個人情報を含むページ向け

S3のオブジェクトにCache-Controlヘッダーを付与するには、アップロード時にメタデータを指定します。

# S3オブジェクトにCache-Controlを設定してアップロード
aws s3 cp style.css s3://my-website-assets-2026/css/style.css \
  --cache-control "max-age=31536000, immutable" \
  --content-type "text/css"

# 既存オブジェクトのメタデータを更新
aws s3 cp s3://my-website-assets-2026/index.html \
  s3://my-website-assets-2026/index.html \
  --cache-control "max-age=0, s-maxage=86400" \
  --content-type "text/html" \
  --metadata-directive REPLACE

独自ドメインとSSL証明書の設定

本番運用では、「d1234abcdef.cloudfront.net」ではなく独自ドメイン（例: cdn.example.com）を使うのが一般的です。CloudFrontでの独自ドメイン設定は、ACM（AWS Certificate Manager）との連携で簡単に行えます。

1. ACMでSSL証明書を発行

CloudFrontで使うSSL証明書は、必ず「バージニア北部（us-east-1）」リージョンで発行する必要があります。これはCloudFrontの仕様上の制約で、東京リージョンで発行した証明書は使えません。

# バージニア北部でSSL証明書をリクエスト
aws acm request-certificate \
  --domain-name cdn.example.com \
  --validation-method DNS \
  --region us-east-1

# DNS検証用のCNAMEレコードを確認
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abc-123 \
  --region us-east-1 \
  --query "Certificate.DomainValidationOptions"

DNS検証用のCNAMEレコードをRoute 53（または利用中のDNSサービス）に追加すれば、数分で証明書が発行されます。ACMで発行した証明書は自動更新されるため、オンプレのように「証明書の有効期限が切れてサイトがダウン」という事故が起きません。

2. CloudFrontに独自ドメインを設定

・手順1: CloudFrontコンソールでディストリビューションの設定を開く
・手順2: 「代替ドメイン名（CNAME）」にcdn.example.comを追加
・手順3: 「カスタムSSL証明書」でACMから発行した証明書を選択
・手順4: Route 53でCNAMEレコード（cdn.example.com → d1234abcdef.cloudfront.net）を作成

Route 53を使っている場合は、CNAMEの代わりにエイリアスレコード（Aレコード）を作成できます。エイリアスレコードはDNSクエリ料金が無料になるため、Route 53を使っているなら必ずエイリアスレコードを選んでください。

料金の仕組みと見積もりのポイント

CloudFrontの料金は「データ転送量」「リクエスト数」「機能利用料」の3つで構成されます。オンプレのCDN契約と比べると、初期費用がゼロで従量課金という点が大きな違いです。

データ転送料金

CloudFrontからインターネットへのデータ転送料金は、リージョン（配信先）によって異なります。

※2026年4月時点。最初の1TB/月は無料枠（AWS無料利用枠）に含まれます。

重要なポイントとして、CloudFrontからオリジン（S3やEC2）へのデータ転送は無料です。つまり、S3からCloudFront経由でファイルを配信すると、S3からの直接配信よりもデータ転送料金が安くなるケースがあります。S3の東京リージョンからのデータ転送が/bin/bash.114/GBに対し、CloudFrontも同額ですが、キャッシュヒットによりオリジンへのリクエスト自体が減るため、トータルコストは下がります。

リクエスト料金

・HTTP リクエスト: /bin/bash.0090/10,000件（日本）
・HTTPS リクエスト: /bin/bash.0120/10,000件（日本）

※2026年4月時点。

コスト見積もりの具体例

月間PV 100万、平均ページサイズ 2MB（画像含む）、データ転送量 2TB/月の企業サイトで試算してみましょう。

・データ転送: 1TB（無料枠）+ 1TB × /bin/bash.114 = 14.00/月
・HTTPSリクエスト: 1,000,000 × /bin/bash.0120/10,000 = .20/月
・合計: 約15.20/月（約17,300円、1ドル=150円換算）

S3から直接配信した場合の2TBのデータ転送料金（28）と比較すると、キャッシュヒット率80%なら実質のオリジン転送は400GBに抑えられ、CloudFrontの配信料金と合わせてもトータルコストは下がる計算です。

よくあるトラブルと対処法

1. 「更新したのに古いコンテンツが表示される」

最も多い問い合わせです。CloudFrontのキャッシュTTLが残っている間は、オリジンを更新しても古いコンテンツが配信され続けます。対処法は2つです。

・即座に反映したい場合: Invalidationリクエストを送信（前述）
・今後の運用で防ぎたい場合: ファイル名にバージョンを含めるCache Busting戦略を導入

2. 「S3に直接アクセスするとエラーになる」

OACを正しく設定していれば、S3への直接アクセスは403 Forbiddenになります。これは意図した動作です。コンテンツの確認はCloudFrontのドメイン経由で行ってください。

3. 「カスタムドメインでSSLエラーが出る」

ACMの証明書をus-east-1以外のリージョンで発行していないか確認してください。CloudFrontで使う証明書は、バージニア北部（us-east-1）で発行する必要があります。また、DNS設定（CNAMEまたはエイリアスレコード）が正しいかも確認してください。

4. 「特定のページだけキャッシュしたくない」

ビヘイビア（Behavior）設定でパスパターンを追加し、該当パスにCachingDisabledポリシーを適用してください。たとえば「/api/*」や「/admin/*」にはキャッシュ無効のビヘイビアを設定し、それ以外にはCachingOptimizedを適用する構成が一般的です。

5. 「CloudFrontの料金が予想より高い」

Invalidationの多用（月1,000パス超過）や、Lambda@Edge/CloudFront Functionsの実行回数が原因であることが多いです。AWS Cost Explorerでサービス別の内訳を確認してください。また、配信対象を日本のみに限定する場合は、「料金クラス」をPrice Class 200に設定すると、使用するエッジロケーションが制限される代わりに料金が最適化されます。

本記事のまとめ

Amazon CloudFrontは、Webサイトやアプリケーションのパフォーマンス向上とオリジン負荷軽減を同時に実現するCDNサービスです。ポイントを整理しておきましょう。

オンプレミスでリバースプロキシやキャッシュサーバーを運用してきたエンジニアなら、CloudFrontの概念は難しくありません。むしろ、SSL証明書の自動更新やDDoS対策の標準装備など、運用負荷が大幅に軽減される点を実感できるはずです。

AWSのネットワーク構成（VPC、サブネット設計）の基礎については、当サイトのAmazon VPC入門の記事もあわせてご覧ください。また、Linuxサーバーでのnginxリバースプロキシ設定については、姉妹サイトLinuxMaster.JPで詳しく解説しています。