Amazon CloudFrontによるCDN配信とアクセス制御
CloudFrontのエッジ配信、キャッシュとTTL、料金、TLS、DDoS対策、S3やロードバランサーへのアクセス制限、署名付きURLとCookieを解説します。
Amazon CloudFrontによるCDN配信とアクセス制御
Amazon CloudFrontは、利用者に近いエッジネットワークからWebサイト、画像、動画、APIレスポンスなどを配信するCDN（Content Delivery Network）です。オリジンは配信元のサーバーやストレージを指し、Amazon S3バケット、Application Load Balancer（ALB）、EC2上のWebサーバー、オンプレミスのHTTPサーバーなどを指定できます。
利用者からのリクエストが繰り返し発生する場合、毎回オリジンまで取りに行く構成では、オリジンの処理負荷やネットワーク転送量が増えます。CloudFrontにキャッシュを設けると、既に取得済みで有効期限内のコンテンツをエッジから返せます。結果として利用者への応答が速くなり、オリジンへの要求回数も抑えられます。
CDN、POP、エッジロケーション
**POP（Point of Presence）**は、AWSのグローバルネットワーク上で利用者の通信を受け付ける拠点です。CloudFrontは世界各地のPOPとエッジロケーションを使って配信します。拠点の数や配置はAWSが継続的に拡張するため、固定の数をサービス仕様として覚えるよりも、利用者の近くからコンテンツを配信する仕組みを理解しましょう。
エッジロケーションでは、利用者に近い場所でコンテンツをキャッシュし、キャッシュが有効であればオリジンまでの往復を省いて応答します。POPにキャッシュがなければ、CloudFrontはより上位のキャッシュ層やオリジンへコンテンツを取りに行きます。
リージョナルエッジキャッシュは、複数のエッジロケーションからの要求を集約する中間のキャッシュ層です。個々のエッジロケーションではアクセス頻度が低く、キャッシュから消えたコンテンツでも、リージョナルエッジキャッシュに残っていればオリジンへの再取得を減らせます。POP、エッジロケーション、リージョナルエッジキャッシュはいずれもCloudFrontのグローバル配信ネットワークを構成しますが、利用者への近さとキャッシュ階層の役割が異なります。
リージョナルサービスとグローバルサービス
AWSのサービスは、リソースが特定リージョンに配置されるものと、リージョンをまたいで提供されるものがあります。EC2インスタンスやVPCはリージョンとアベイラビリティゾーンに結び付いています。S3はAWS全体で利用できるサービスですが、個々のバケットとそのデータは作成時に選んだリージョンに存在します。
CloudFrontとRoute 53はグローバルなサービスです。CloudFrontディストリビューションは単一リージョン内にだけ配置されるものではなく、エッジネットワークを通じて世界各地へ配信します。そのため、管理コンソールでリージョンを選択して各リソースを管理する一般的なリージョンサービスと画面の見え方が異なる場合があります。サービス画面にリージョン選択がないことと、関連するすべてのリソースがグローバルであることは同じ意味ではありません。たとえば、CloudFrontのオリジンにするS3バケットはリージョンを持ちます。
CloudFrontの配信設定とリクエストの流れ
CloudFrontの配信単位はディストリビューションです。ディストリビューションには、コンテンツの取得先であるオリジン、受け付けるビューワープロトコル、キャッシュ動作、独自ドメイン、アクセス制御などを設定します。
- 利用者がディストリビューションのドメイン名または独自ドメインへリクエストを送ります。
- DNSによって利用者に近いCloudFrontのエッジへ接続します。
- エッジはリクエストに対応するキャッシュを確認します。
- キャッシュが有効なら、CloudFrontはそのコンテンツを返します。これがキャッシュヒットです。
- 有効なキャッシュがなければ、CloudFrontは設定に応じて上位のキャッシュ層またはオリジンへ問い合わせます。オリジンから受け取った応答を利用者に返し、キャッシュ可能な応答なら設定された期間保持します。これがキャッシュミスに続くオリジンフェッチです。
この流れを踏まえると、CloudFrontの利用効果はキャッシュ可能性、コンテンツの更新頻度、利用者のアクセス分布に左右されます。頻繁に要求される静的ファイルを長くキャッシュする構成と、利用者ごとに応答が変わるAPIを短くキャッシュする構成では、適切な設定が異なります。
キャッシュキーとTTLの設計
**TTL（Time To Live）**は、CloudFrontが取得したコンテンツをキャッシュに保持する時間です。TTLが長いほどオリジンへの再問い合わせを抑えられますが、オリジンで更新した内容が利用者に届くまで時間がかかります。TTLが短いほど新しい内容が反映されやすくなりますが、オリジンへの問い合わせが増え、応答時間やオリジンの負荷が上がることがあります。
キャッシュポリシーでは、最小TTL、デフォルトTTL、最大TTLを設定します。オリジンの応答にCache-ControlやExpiresなどの指示がある場合は、これらのTTL上限・下限とキャッシュポリシーに従って保持期間が決まります。最小TTLを0にしておけばオリジンのキャッシュ指示に従わせられますが、最小TTLが0より大きい設定では、オリジンがキャッシュしないよう指示してもCloudFront側に最低期間キャッシュされる場合があります。個人情報や利用者ごとに内容が変わる応答を誤って共有キャッシュしないよう、TTLとキャッシュキーを合わせて設計してください。
キャッシュキーは、どのリクエスト同士を同じキャッシュコンテンツとして扱うかを決めます。URLのパスに加え、必要に応じてクエリ文字列、HTTPヘッダー、Cookieを含めます。たとえば同じ画像URLでも、format=webpというクエリで画像形式を切り替えるなら、その値をキャッシュキーに含めないと、別形式の応答が誤って再利用される可能性があります。一方、応答に影響しないヘッダーやパラメーターまで含めると、同じコンテンツが多数のキャッシュ項目に分かれ、ヒット率が下がります。
キャッシュヒット率とは、CloudFrontが要求をキャッシュから返せた割合です。実際のリクエストの種類、各コンテンツの更新頻度、ヒット率、オリジンの負荷を確認しながら、TTLとキャッシュキーを調整します。キャッシュできない応答や、利用者ごとに異なるデータを含む応答では、誤配信の防止を優先し、キャッシュしないか、共有可能な部分だけをキャッシュする設計を選びます。
圧縮と更新反映
テキストや対応する形式のコンテンツは、CloudFrontの自動圧縮を利用できます。ビューワーが圧縮形式に対応していることをリクエストで示すと、対応コンテンツをGzipやBrotliで圧縮して配信し、転送サイズと応答時間を抑えられる場合があります。圧縮設定は対象となるファイル形式やサイズ条件を確認し、オリジンが返すコンテンツの種類に合わせます。
キャッシュ中のファイルをすぐ差し替えたい場合は、ディストリビューションの**キャッシュ無効化（invalidation）**を実行して、対象パスのキャッシュを削除できます。無効化が行われると、次の要求ではCloudFrontが新しいコンテンツを取得します。頻繁に無効化する運用は反映待ちや追加コストにつながる場合があるため、更新のたびにファイル名へバージョンを含める方法とTTLを組み合わせる設計も検討します。
料金の考え方
CloudFrontには、利用量に応じて課金する方式のほか、一定の利用枠や機能を含む月額固定プランがあります。従量課金では主に利用者へ配信するデータ量、HTTP／HTTPSリクエスト数、利用するエッジ機能が料金要素になります。固定プランは含まれる転送量、リクエスト数、機能や超過時の条件がプランごとに異なります。どちらの方式でも、利用地域や機能、選択プランによって条件が変わるため、固定の単価を前提にせず、CloudFront料金ページで現在の課金単位とプラン条件を確認してください。
AWSオリジンとCloudFrontの間のデータ転送は、CloudFront経由で配信する場合、現行料金ページに記載された条件に従いデータ転送料金が免除されます。ただし、EC2、ALB、S3などオリジン側のコンピューティングやストレージの利用料金まで免除されるわけではありません。外部事業者のオリジンを使う場合は、その事業者が課すCloudFrontまでの転送料金も確認します。
キャッシュヒットを増やすとオリジンフェッチやオリジン側の処理を減らせる可能性があります。コンテンツの圧縮は配信データ量を抑えるのに役立ちます。料金を最適化する場合は、ヒット率だけでなく、リクエスト数、無効化、利用プラン、関数実行などの料金要素を一緒に確認します。
エッジ関数と配信状況の確認
CloudFrontでは、エッジでリクエストや応答を処理する関数を実行できます。CloudFront Functionsは、ビューワーから届いた要求やビューワーへ返す応答に対する軽量な処理に向きます。URLの書き換え、リダイレクト、ヘッダー調整など、短時間で実行する処理に使います。Lambda@EdgeはLambda関数をCloudFrontに関連付け、ビューワー側またはオリジン側の要求・応答に対して処理を行います。より幅広い実行環境や処理が必要な場合に選択肢になります。実行できるイベント、言語、実行時間などの制約と料金条件は異なるため、用途に合う機能を選びます。
CloudFrontはアクセスログ、メトリクス、使用量レポートなどを使って配信状態を確認できます。標準ログでリクエストの記録をS3に保存し、必要に応じてリアルタイムログで要求を分析基盤へ送る構成も選べます。ログやレポートからリクエスト数、応答コード、転送量、キャッシュヒットの状況を調べ、キャッシュ戦略やセキュリティ設定を見直します。ログの保存先や分析サービスの料金・権限も別途設計してください。
HTTPSとTLS証明書
CloudFrontではビューワー（ブラウザーやクライアント）からCloudFrontまでと、CloudFrontからオリジンまでを別々の通信区間として扱います。
- ビューワーからCloudFront：CloudFrontの既定ドメインを使う場合は、CloudFrontが提供するドメインと証明書を利用できます。独自ドメインをHTTPSで配信する場合は、そのドメインをディストリビューションに関連付け、ACMまたは適切な証明書を設定します。CloudFrontで使うACM証明書は**米国東部（バージニア北部、
us-east-1）**に置きます。 - CloudFrontからオリジン：オリジンプロトコルポリシーでHTTPまたはHTTPSを選びます。HTTPSを選ぶ場合、オリジンはCloudFrontが検証できる証明書を提示し、証明書の名前、有効期限、証明書チェーンなどの条件を満たす必要があります。
ビューワーとの接続をHTTPSにしただけでは、CloudFrontからオリジンまでが暗号化されるとは限りません。逆にオリジン接続をHTTPSにしても、利用者からCloudFrontまでが自動的にHTTPSになるわけではありません。保護が必要な通信区間ごとにプロトコルを設定し、証明書の配置先と対象ドメインを確認してください。
セキュリティ機能とアクセス制御
CloudFrontは、TLS、AWS WAF、AWS Shield、地理的制限、オリジンアクセス制御、署名付きURL／Cookieなどを組み合わせて、コンテンツと配信経路を保護します。これらは同じ制御を重複させるものではなく、ネットワーク攻撃の緩和、HTTP要求の検査、オリジンを直接公開しない構成、特定利用者への配信など異なる役割を持ちます。
AWS WAF、AWS Shield、地域による制限
AWS WAFはHTTP／HTTPSリクエストの内容を調べ、ルールに応じて許可、遮断、記録します。SQLインジェクションやクロスサイトスクリプティングなどのWeb攻撃、送信元IP、リクエスト頻度などに基づく制御を行えます。CloudFrontに関連付けるWeb ACLはグローバルスコープで管理します。
AWS Shield StandardはCloudFrontなど対象となるAWSサービスに対する一般的なDDoS保護を提供し、AWS Shield Advancedはより高度な保護、可視性、サポートを必要とする構成で検討します。WAFはアプリケーション層のHTTP要求を評価し、ShieldはDDoS緩和を担います。どちらか一方だけですべての種類の攻撃を防ぐと捉えず、用途を分けて設定してください。
**地理的制限（Geo restriction）**は、要求元の国に基づいてディストリビューション全体または対象範囲へのアクセスを許可・拒否する機能です。国単位の制御であり、特定のIPアドレスやCIDR範囲を指定する機能ではありません。IP単位、HTTPヘッダー、URIパス、レートなど細かな条件が必要な場合はAWS WAFを使います。
S3オリジンをCloudFront経由だけにする
S3バケットを非公開のままCloudFrontから配信するには、**OAC（Origin Access Control、オリジンアクセスコントロール）**を設定し、S3バケットポリシーでCloudFrontディストリビューションのサービスプリンシパルに必要なアクセスを許可します。バケットポリシーには、許可するディストリビューションのARNなどの条件を加え、意図した配信経路に限定します。
この構成では、利用者にS3バケットへの公開アクセスを与えず、CloudFrontを通した要求だけがオブジェクトを読めるようにします。バケットを公開したままCloudFrontを前段に置く構成では、利用者がS3のURLへ直接アクセスしてCloudFrontのキャッシュやポリシーを迂回できるため、OACだけでなくバケット側の公開設定も確認してください。
従来の**OAI（Origin Access Identity）**も既存構成で見かけますが、新しい設計ではOACが推奨されます。OACはSSE-KMSで暗号化されたS3オブジェクトや、要件に応じた書き込み系HTTPメソッドにも対応します。読み取りだけでなくPUTなどをCloudFront経由で許可する場合には、CloudFrontのビヘイビア、S3バケットポリシー、KMSキー権限を必要な操作だけに絞ってください。OACを設定しても、S3側のポリシーやKMSキーのポリシーが不足すればアクセスは失敗します。
ALBなどのカスタムオリジンを保護する
ALBやEC2上のWebサーバーなどをカスタムオリジンにするときは、CloudFrontからオリジンへの要求にカスタムオリジンヘッダーを追加できます。オリジン側では、そのヘッダーが期待する値を持つ場合だけ要求を受け付けるルールを設定します。たとえば社内向けの帳票ポータルを配信する場合、CloudFrontが専用のヘッダーを付け、ALBのリスナールールでそのヘッダーを持つ要求だけをアプリケーションターゲットへ転送できます。
カスタムヘッダーはCloudFrontからの要求を識別する手段の一つであり、オリジンをインターネットへ公開したままでよいという意味ではありません。直接オリジンへ接続できる経路を残すと、ヘッダーを知らない要求を遮断できても、別の公開エンドポイントや設定ミスを通じてアクセスされる可能性があります。可能な構成では、ネットワークレベルでもCloudFrontからの到達だけを許し、ヘッダー値を十分な強度で管理・定期的に変更してください。認証認可の要件があるアプリケーションでは、CloudFrontの経路制限とは別に、利用者の認証と権限確認も実装します。
署名付きURLと署名付きCookie
非公開コンテンツを特定の利用者へ配信するときは、CloudFrontの署名付きURLまたは署名付きCookieを利用できます。アプリケーション側で信頼された署名者の秘密鍵を使ってポリシーへ署名し、CloudFrontはエッジで署名と有効条件を検証します。設定した条件を満たさなければ、キャッシュにコンテンツが残っていても要求を拒否できます。
CloudFrontでは、信頼されたキーグループに公開鍵を登録し、対応する秘密鍵をアプリケーションの安全な環境で管理する構成が推奨されます。秘密鍵をクライアントへ渡してはいけません。CloudFrontは署名を確認する公開鍵で検証します。キーをローテーションするときは、新旧の公開鍵を切り替える期間や既存の署名の有効期限を考慮します。
署名付きURL
署名付きURLは、特定のファイルやオブジェクトへの一時的なアクセスを許可する場合に向いています。URLにはディストリビューションのドメインと対象パスに加え、有効期限などの署名情報が含まれます。有効期限を過ぎるとCloudFrontはそのURLを拒否します。利用者がURLを他者へ転送できるため、URLを知っている人だけが使える一時的なアクセス資格情報として扱い、HTTPSで渡し、必要な期間だけ有効にしてください。
署名付きCookie
署名付きCookieは、利用者がアクセスする複数のファイルに対して共通のポリシーを適用する場合に向いています。アプリケーションが利用者へポリシーと署名を含むCookieを渡し、ブラウザーは対象ドメインへの以降の要求にCookieを付けます。CloudFrontはエッジでCookieの署名とポリシーを確認し、許可条件を満たす場合に保護されたコンテンツを返します。
ポリシーには、対象とするURLのパターン、有効期限を含められます。カスタムポリシーでは開始時刻や利用者のIPアドレス範囲など、追加の条件を指定できます。定型のポリシーは設定が簡単ですが、条件を細かく限定したい場合はカスタムポリシーを選びます。署名付きURLと署名付きCookieのどちらでも、署名を有効にして初めてアクセスを制限できます。保護対象のビヘイビアやキーグループの設定も合わせて確認してください。
| 選択肢 | 向いている要件 | クライアントへの渡し方 |
|---|---|---|
| 署名付きURL | ダウンロードリンクなど、個別のファイルへの期間限定アクセス | URL自体に署名と期限を含める |
| 署名付きCookie | 同一サイト内の複数ファイルや、URLを変えずに保護対象をまとめて配信 | 事前に署名済みCookieを設定し、対象要求に添付する |
署名付きCookieは、利用者が初回要求を送る前に有効なCookieを設定し、その後の要求を許可する目的に使えます。URLとCookieのどちらも、権限を持つ利用者の認証そのものを代替するのではなく、CloudFront上の保護コンテンツへのアクセス条件を表します。アプリケーションが利用者を認証したうえで、必要な対象と期限を持つ署名を発行してください。
試験で整理したい判断軸
- 利用者への応答を速め、オリジン負荷を下げる：CloudFrontを使い、利用頻度と更新頻度に応じてキャッシュキーとTTLを決める。圧縮やキャッシュヒット率も確認する。
- 最新の内容を早く反映する：TTLを短くするか、必要なパスを無効化する。長いTTLを使いたい場合は、ファイル名にバージョンを含める方法も検討する。
- S3を直接公開せず配信する：OAC、S3バケットポリシー、必要に応じてKMSキーの許可を設定し、ディストリビューションを限定する。
- ALBなどのHTTPオリジンをCloudFront経由に制限する：オリジンカスタムヘッダーやオリジン側ルールを組み合わせ、可能ならネットワーク上の到達元も限定する。
- 国単位で配信を制御する：CloudFrontの地理的制限を使う。個別IPやHTTP内容に基づいて制御するならAWS WAFを使う。
- 個別ファイルを短期間だけ配布する：署名付きURLを使う。複数の関連コンテンツをまとめて期間制限するなら署名付きCookieを使う。
- 通信を暗号化する：ビューワーからCloudFrontと、CloudFrontからオリジンを別々にHTTPS化する。独自ドメインのCloudFront用ACM証明書は
us-east-1に置く。 - DDoSとWeb攻撃に備える：ShieldでDDoS緩和、WAFでHTTP／HTTPSリクエストの検査を行い、目的に応じて組み合わせる。
公式ドキュメント
重要ポイント
- ▸CloudFrontは世界各地のエッジロケーションからコンテンツを配信するグローバルなCDNで、キャッシュヒット時はオリジンへの要求を減らし、利用者への応答を速める
- ▸POP／エッジロケーションは利用者に近い配信拠点、リージョナルエッジキャッシュは複数のエッジロケーションからの要求を集約する上位のキャッシュ層として働く
- ▸TTLを長くするとオリジンへの問い合わせや転送量を減らせるが、更新の反映は遅くなる。短くすると最新化しやすい一方でオリジン負荷が上がる
- ▸CloudFrontはデータ転送、HTTP／HTTPSリクエスト、エッジ機能の利用などに応じて課金される。料金条件はオリジンの種類や利用機能で異なるため、現行料金表を確認する
- ▸ビューワーとCloudFront、CloudFrontとオリジンのTLSは別々の通信区間として設定する。独自ドメインの証明書をCloudFrontに関連付ける場合、ACM証明書はus-east-1に用意する
- ▸非公開S3オリジンにはOACとバケットポリシーを使い、CloudFrontディストリビューションからのアクセスに限定する。ロードバランサーなどのカスタムオリジンではCloudFrontのカスタムヘッダーなどで到達経路を制限する
- ▸地理的制限、AWS WAF、Shield、署名付きURL／Cookieを要件に応じて組み合わせる。署名付きURLは個別のファイル、署名付きCookieは複数の保護対象ファイルへのアクセスに向く
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
VPC とネットワーク に関連するトピックを続けて確認できます。