CloudFront講座

この講座では、AWSのCDNサービスであるCloudFrontについて学びます。

• CDN（コンテンツ配信ネットワーク）の仕組みとメリット
• Amazon CloudFrontの特徴
• エッジロケーションとキャッシュの仕組み
• オリジン（S3・EC2・ALB）との連携
• OAC（Origin Access Control）によるセキュアな配信
• エッジでの処理実行（CloudFront Functions・Lambda@Edge）
• 他サービスとの連携（ACM・WAF）

1. CloudFrontとは

1.1 CDN (Content Delivery Network) の仕組み

一般的なWeb配信の課題

通常、Webサイトや動画配信を行う場合、データは特定の場所にあるサーバ（これを「オリジンサーバ」と呼びます）に保存されています。

しかし、この従来の方式には、主に2つの大きな課題がありました。

1つ目は「物理的な距離による遅延」です。例えば、東京にあるサーバにブラジルやロンドンからアクセスしようとすると、地球の裏側まで通信を行うため、データの表示に時間がかかってしまいます。

2つ目は「アクセス集中によるダウン」です。SNSで拡散されるなどして急激にアクセスが増えた場合、すべてのリクエストが1台のサーバに集中してしまい、処理しきれずにサイトが閲覧できなくなるリスクがあります。

CDNによる解決

これらの課題を鮮やかに解決するのが、CDN（Content Delivery Network）です。

CDNがキャッシュを活用してコンテンツを配信する流れを以下に示します。

flowchart TD
    User["ユーザ"] --> Edge["エッジロケーション"]
    Edge --> Check{"キャッシュあり?"}
    Check -- "ヒット" --> Return1["キャッシュから返却"]
    Check -- "ミス" --> Origin["オリジンサーバ"]
    Origin --> Cache["エッジにキャッシュ保存"]
    Cache --> Return2["ユーザに返却"]

CDNを利用すると、世界中に配置された多数のエッジサーバ（キャッシュサーバ）に、オリジンサーバのデータのコピーが一時保存（キャッシュ）されます。

これにより、ユーザは物理的に一番近い場所にあるエッジサーバからデータを受け取ることができるため、世界中どこからでも高速にWebサイトを表示できます。

また、ほとんどのアクセスをエッジサーバが肩代わりしてくれるため、大元のオリジンサーバへの負荷が激減し、急なアクセス集中があっても安定した稼働を続けることができます。

1.2 Amazon CloudFrontの特徴

Amazon CloudFrontは、AWSが提供する高速で高機能なCDNサービスです。

先ほど説明した「世界中のキャッシュサーバ」にあたるものが、CloudFrontではエッジロケーションと呼ばれ、世界中の主要都市に数百箇所以上展開されています。

CloudFrontを利用することで、S3やEC2にあるデータを、利用者の最寄りの拠点から配信できるため、動画や画像などの大容量データであっても、驚くほど高速に表示させることができます。

また、CloudFrontは単に速くするだけではありません。セキュリティの観点でも非常に重要な役割を果たします。

例えば、S3の静的ウェブサイトホスティング機能単体ではできなかった「HTTPS（暗号化）通信」に対応させたり、AWS Shieldという機能と連携してDDoS攻撃（大量のアクセスによる攻撃）からシステムを守ったりすることができます。

つまり、AWSでWebサービスを公開する場合、「S3やEC2で作って、CloudFront経由で配信する」というのが、パフォーマンスとセキュリティを両立させるための最も標準的な構成（ベストプラクティス）となっています。

2. CloudFrontの構成要素

2.1 エッジロケーション

エッジロケーションは、CloudFrontがコンテンツを一時保存（キャッシュ）し、ユーザへ配信するための物理的な拠点のことです。

AWSには「東京リージョン」や「大阪リージョン」といった大規模なデータセンター群がありますが、エッジロケーションはそれらよりも遥かに数が多く、世界中の主要都市に数百箇所以上展開されています。

ユーザがWebサイトにアクセスすると、自動的に物理的距離が最も近いエッジロケーションへと誘導されます。そこにデータがあれば即座に返却されるため、ユーザは地球の裏側にあるサーバと通信していることを意識することなく、まるで隣にあるサーバからデータを受け取っているかのような快適な速度でコンテンツを利用できます。

2.2 ディストリビューション (Distribution)

CloudFrontを利用する際の設定の「ひとかたまり（管理単位）」をディストリビューションと呼びます。

具体的には、「どこのデータを配信するのか（オリジン）」、「どのようなルールでキャッシュするのか（ビヘイビア）」といった設定をひとまとめにした箱のようなものです。

1つのWebサイトやアプリケーションにつき、通常1つのディストリビューションを作成して管理します。

ディストリビューションを作成すると、d111111abcdef8.cloudfront.net のようなCloudFront専用のドメイン名が発行されます。

ユーザはこのドメインにアクセスすることで、CloudFrontを経由した高速な配信を受けられるようになります。

なお、通常は、このドメインに独自ドメインを割り当てて運用します。

2.3 オリジン (Origin)

オリジンとは、CloudFrontが配信するデータの「大元（オリジナル）」が保存されている場所のことです。

ユーザがアクセスした際、もし最寄りのエッジロケーションにデータが保存されていれば（キャッシュヒット）、そのままエッジから返却されます。しかし、まだデータがない場合（キャッシュミス）、CloudFrontは自動的にこのオリジンへデータを取りに行き、それをエッジに保存してからユーザへ届けます。

オリジンとして指定できるのは、Amazon S3バケットだけでなく、Webサーバが稼働しているEC2インスタンスやELB（ロードバランサー）、あるいはAWS外部のオンプレミスサーバなども指定することが可能です。

2.4 ビヘイビア (Behavior)

ビヘイビアは、ユーザがアクセスしてきたURLのパス（ファイルパス）に応じて、CloudFrontが「どのように振る舞うか」を定義する設定です。

例えば、「/images/*（画像フォルダ）へのアクセスはS3のオリジンへ転送し、長くキャッシュする」、「/api/*（プログラム処理）へのアクセスはEC2へ転送し、キャッシュしない」といったように、パスのパターンごとに異なるルールを適用することができます。

この機能により、1つのディストリビューション（1つのドメイン）の中で、静的なコンテンツと動的なアプリケーションを同居させ、柔軟に使い分けることが可能になります。

3. キャッシュの制御 (Cache Control)

3.1 TTL (Time To Live) と有効期限

TTL（Time To Live）は、エッジロケーションに保存されたキャッシュデータが「いつまで有効か」を定める有効期限の設定です（単位は秒）。

一度エッジに保存されたデータは、このTTLの時間が経過するまでは、たとえオリジン側でデータが更新されていても、エッジにある古いデータ（キャッシュ）がユーザに返され続けます。TTLが切れると、CloudFrontは再びオリジンへデータを取りに行き、キャッシュを最新の状態に更新します。

TTLを長くすればするほど、オリジンへのアクセスが減り、配信性能は上がりますが、サイトの更新がユーザに反映されるまでに時間がかかるようになります。逆に短くすれば、情報の鮮度は保たれますが、その分オリジンへの負荷が増えます。

そのため、変更が少ない画像は長く、頻繁に変わるニュース記事は短くするなど、コンテンツの性質に合わせて適切に設定する必要があります。

3.2 キャッシュポリシー (Cache Policy)

キャッシュポリシーは、TTL（有効期限）や、キャッシュキー（どの要素が違えば「別のデータ」として保存するか）に関する設定をひとまとめにした「ルールのテンプレート」です。

このポリシーには、大きく分けて2つの種類があります。

1つ目は「AWS管理ポリシー（Managed Policy）」です。

これはAWSがあらかじめ作成・提供しているもので、「汎用的なキャッシュ設定（CachingOptimized）」や「キャッシュを無効化する設定（CachingDisabled）」など、よく使われるパターンが網羅されています。利用者はこれらを選ぶだけで、推奨される設定をすぐに適用できます。

2つ目は「カスタムポリシー」です。

管理ポリシーでは要件を満たせない場合に、利用者が独自に作成するものです。「特定のクエリパラメータだけを区別したい」「特定のヘッダーに基づいてキャッシュを分けたい」といった、アプリケーション固有の細かい制御が必要な場合に作成して利用します。

以前はこれらをビヘイビアごとに個別に設定していましたが、ポリシーとして独立したことで、作成したルールを複数のディストリビューションで使い回すことができるようになり、管理が非常に効率的になりました。

3.3 キャッシュ無効化 (Invalidation)

キャッシュ無効化（Invalidation）は、設定されたTTLの経過を待たずに、エッジロケーションにあるキャッシュデータを強制的に削除する機能です。

通常、Webサイトの画像を差し替えたり、不具合修正でプログラムを更新したりしても、古いキャッシュが残っている間は、ユーザには古い内容が表示され続けてしまいます。

しかし、この機能を使って特定のファイル（パス）を指定すると、世界中のエッジロケーションから即座にそのキャッシュが削除されます。その結果、次のアクセスでは必ずオリジンから最新のデータが取得されるようになります。

ファイルの指定は、個別のファイル名（例：/images/logo.png）だけでなく、ワイルドカードを使ってディレクトリごと（例：/images/*）指定することも可能です。

非常に便利ですが、頻繁に行うとオリジンへの負荷が高まりCDNの恩恵が薄れるほか、実行回数によっては追加料金が発生する場合があるため、基本的には「緊急時」や「デプロイ（更新）直後」に限定して利用するのが一般的です。

4. セキュリティと配信設定

4.1 OAC (Origin Access Control)

OAC（Origin Access Control）は、S3バケットへのアクセスを「CloudFront経由のみ」に厳密に制限するためのセキュリティ機能です。

CloudFrontを導入しても、オリジンであるS3バケット自体がインターネットに公開されたままでは、悪意のあるユーザがCloudFront（WAFや地理的制限など）を回避して、S3のURLへ直接アクセスしてしまうリスクがあります。

そこでOACを設定すると、CloudFrontがS3へアクセスする際に特別な「署名」を行うようになります。S3側では「CloudFrontからの署名があるリクエストだけを通す」という設定を行うことで、S3への直接アクセスを完全にブロックし、必ずCloudFrontという正規の入り口を通らせる構成が可能になります。

なお、以前は「OAI (Origin Access Identity)」という機能が使われていましたが、現在はよりセキュリティ強度が高く、機能も豊富なOACの使用が推奨されています（Restrict access to an Amazon S3 origin（AWS公式ドキュメント）に「We recommend that you use OAC instead」と明記されています）。そのため、OAIについては説明を割愛します。

4.2 構成例：S3とCloudFrontのセキュアな接続

OACを利用することで、S3への「裏口」を完全に塞いだ堅牢な配信構成を実現できます。

OACによるS3への直接アクセスのブロックと、CloudFront経由の正規アクセスの流れを以下に示します。

graph LR
    User["ユーザ"]
    CF["CloudFront<br>（OAC設定済み）"]
    S3["S3バケット<br>（非公開）"]

    User -- "正規アクセス" --> CF
    CF -- "署名付きリクエスト" --> S3
    User -. "直接アクセス<br>（403 Forbidden）" .-> S3

まず、オリジンとなるS3バケットは「ブロックパブリックアクセス」をすべて有効にし、インターネットからの直接アクセスを一切遮断した状態にします。その上で、バケットポリシー（S3側の許可ルール）を使って、「特定のCloudFrontディストリビューションからのリクエストのみを許可する」という設定を行います。

一方、CloudFront側ではOACの設定を有効化し、S3へデータを要求する際に、正しい権限を持っていることを証明する署名をリクエストに含めるようにします。

この構成にしておけば、正規のルートであるCloudFront経由でアクセスしたユーザには正常にコンテンツが表示されますが、悪意を持ってS3のURLへ直接アクセスしようとしたユーザは「403 Forbidden（アクセス拒否）」となり、データを閲覧することはできません。これにより、CloudFrontで設定したセキュリティ機能（WAFなど）を強制的に適用させることができます。

4.3 地域制限 (Geo Restriction)

CloudFrontには、ユーザがアクセスしてきている国に基づいてコンテンツの配信を許可/拒否する地域制限（Geo-Restriction）という機能があります。

この機能は、ユーザのIPアドレスを解析して国を特定し、あらかじめ設定した「ホワイトリスト（許可）」または「ブラックリスト（拒否）」に基づいてアクセスを制御します。

主な利用シーンは2つあります。

1つ目は「ビジネス上の制約」です。例えば、動画配信サービスなどで、著作権やライセンス契約の都合上、「日本国内のユーザにのみ配信を許可したい」といった場合に利用されます。

2つ目は「セキュリティ対策」です。特定の国からの不正アクセスやサイバー攻撃が急増した場合に、その国からのアクセスを丸ごとブロックすることで、簡易的な防御策として機能します。

なお、設定は国単位で非常に簡単に行えますが、VPNやプロキシサーバを経由して位置情報を偽装したアクセスまでは完全に防ぐことができない点には留意が必要です。

5. エッジでの処理実行

CloudFrontは、管理画面での設定だけでなく、実際にプログラムコードを実行して、ユーザへの配信挙動をより柔軟にカスタマイズすることができます。そのための機能として、軽量・高速な「CloudFront Functions」と、高機能な「Lambda@Edge」の2つが用意されています。

5.1 CloudFront Functions

CloudFront Functionsは、JavaScriptで記述された非常に軽量なプログラムを、世界中に数百あるすべてのエッジロケーションで実行する機能です。

最大の特徴は「爆速」であることです。実行時間は1ミリ秒以下という制約があり、ネットワーク通信やファイルシステムへのアクセスもできません。その代わり、アクセス数がどれだけ増えても超低遅延で処理をさばくことができます。主に、URLの書き換え（リライト）、HTTPヘッダーの操作、シンプルな認証トークンの検証など、外部との通信を必要としない「軽い処理」に向いています。

5.2 Lambda@Edge

Lambda@Edgeは、AWSのサーバレスコンピューティングサービスである「AWS Lambda」を、CloudFrontの配下（リージョナルエッジキャッシュ）で実行できるように拡張した機能です。

こちらはNode.jsやPythonが利用でき、一般的なLambdaと同様に、外部のデータベースへアクセスしたり、複雑な計算処理を行ったりすることが可能です。その分、CloudFront Functionsに比べると実行にかかる時間やコストは大きくなりますが、ユーザごとの動的な画像の生成（リサイズ）、外部認証基盤を使った複雑な認可処理、A/Bテストの振り分けなど、「重い処理」や「外部連携が必要な処理」を実現できます。

5.3 比較

最後に、この2つの違いを表にまとめておきます。

6. 他サービスとの連携

CloudFrontは単体で使うだけでなく、他のAWSサービスと組み合わせることで、より実用的で強力な配信環境を作ることができます。ここでは、特に連携する頻度が高い2つのサービスについて解説します。

6.1 ACMとの連携

Webサイトを公開する際、初期状態の d12345.cloudfront.net というドメインではなく、自社のブランドドメイン（例: www.example.com）を使いたいケースがほとんどです。そのために必要なのが、AWS Certificate Manager（ACM）です。

ACMは、SSL/TLS証明書（通信を暗号化するためのデジタル証明書）を発行・管理するサービスです。CloudFrontと連携させるメリットは主に2つあります。

1つ目は「コストと管理の手間」です。通常、SSL証明書は年間数千円〜数万円の費用がかかり、1年ごとの更新作業も必要ですが、ACMを使えば証明書の発行は無料、かつ更新も自動で行われます。

2つ目は「独自ドメインでのHTTPS配信」です。CloudFrontの設定画面で、ACMで発行した証明書を選択するだけで、簡単に自分のドメインで安全なHTTPS通信を実現できます。

6.2 WAFとの連携

AWS WAF (Web Application Firewall) セキュリティをさらに強化するために連携するのが、AWS WAFです。CloudFrontは標準でも、AWS Shield Standardという機能によって、DDoS攻撃（大量の通信を送りつける攻撃）からは守られています。しかし、Webアプリケーションの脆弱性を突くような攻撃（SQLインジェクションやクロスサイトスクリプティングなど）は防ぐことができません。

そこで、CloudFrontにWAFを関連付けることで、これらの攻撃をエッジロケーション（入り口）でブロックできるようになります。不正な通信がオリジンサーバやアプリケーションに届く前に、CloudFrontの段階で遮断してしまうため、サーバへの負荷やリスクを最小限に抑えることができます。

7. 主なユースケース

CloudFrontは、Webコンテンツの高速配信とセキュリティ強化に欠かせないサービスです。以下に代表的なユースケースを紹介します。

7.1 静的Webサイトの高速配信

S3に保存した静的コンテンツをCloudFront経由で配信することで、世界中のユーザに対して低遅延でコンテンツを届けることができます。OACを使用してS3への直接アクセスを遮断し、セキュリティも確保できます。

7.2 動的コンテンツとAPIの高速化

EC2やALB、API Gatewayをオリジンに設定することで、動的なアプリケーションやAPIレスポンスも高速化できます。エッジロケーションとオリジン間の接続最適化により、動的コンテンツでもレイテンシーを削減できます。

7.3 動画・ライブストリーミング配信

大容量の動画ファイルや、ライブ配信のストリームをCloudFront経由で配信することで、視聴者に対して安定した高品質な映像体験を提供できます。署名付きURLやCookieを使用した視聴制限も可能です。

8. 設計のポイント

CloudFrontを設計する際の主要な検討項目を以下にまとめます。

9. まとめ

この講座では、AWSのCDNサービスであるCloudFrontについて学びました。

• CDNは世界中のエッジサーバにコンテンツをキャッシュし、ユーザに最も近い場所から高速配信する仕組み
• CloudFrontはディストリビューション、オリジン、ビヘイビアという構成要素で設定を管理する
• TTLやキャッシュポリシーでキャッシュの有効期限を制御し、キャッシュ無効化で緊急時に即座に更新できる
• OACを使ってS3への直接アクセスをブロックし、CloudFront経由のみに制限できる
• CloudFront FunctionsやLambda@Edgeでエッジでの処理を実行し、ACMやWAFと連携してセキュリティを強化できる