AWSサービス解説
Amazon CloudFrontとは？CDNを初心者向けに解説
CloudFrontの基本、CDN、キャッシュ、S3配信、HTTPS、Invalidationを初心者向けに整理します。
Amazon CloudFrontは、AWSのCDNサービスです。静的サイト配信、画像配信、API高速化などで使われます。
結論
CloudFrontは、ユーザーに近いエッジロケーションからコンテンツを配信し、表示速度と可用性を高めるサービスです。
CDNとは
CDNはContent Delivery Networkの略です。コンテンツをユーザーの近くにキャッシュして配信する仕組みです。
たとえば日本のユーザーが米国のサーバーへ毎回アクセスすると遅くなります。CloudFrontを使うと、近いエッジ拠点からキャッシュを返せるため、表示速度が改善します。
S3との組み合わせ
静的サイトでは、S3にHTML、CSS、JavaScript、画像を置き、CloudFrontで配信する構成がよく使われます。
このとき、S3を直接公開せず、CloudFront OACでCloudFrontからのみアクセスできるようにすると安全です。
HTTPS配信
CloudFrontはHTTPS配信にも使います。独自ドメインを使う場合は、ACMで証明書を発行し、CloudFront Distributionに紐づけます。
CloudFront用のACM証明書は、リージョンの扱いに注意します。
Invalidationとは
CloudFrontはキャッシュを持つため、S3に新しいファイルをアップロードしても、すぐに反映されない場合があります。そのときに使うのがInvalidationです。
CI/CDでは、S3 sync後にCloudFront Invalidationを実行して、更新内容を反映します。
試験で問われるポイント
- CloudFrontはCDNサービス
- エッジロケーションから配信する
- S3と組み合わせて静的サイトを配信できる
- HTTPS配信やキャッシュ制御に使う
- 更新反映にはInvalidationを使う
まず判断したいこと
CloudFrontを初めて使う人、S3に置いた静的サイトを公開しようとしている人、試験で配信サービスの選択肢を整理したい人に向けた記事です。読み終えたら、画像やHTMLを世界中へ配る場面でCloudFrontを選ぶ理由、APIの入口にAPI Gatewayを置く理由、S3を直接公開しない理由を説明できるようになります。
設計では「CloudFrontを入れるか」だけでなく、「キャッシュしてよい内容か」「オリジンに誰が到達できるべきか」を先に決めます。更新頻度が高い管理画面や、利用者ごとに内容が変わるレスポンスまで長くキャッシュすると、意図しない表示につながります。公式の位置付けはAmazon CloudFront とはでも確認できます。
ALB、API Gateway、S3との役割分担
CloudFrontは配信とキャッシュの前段です。アプリケーションを実行するターゲットへリクエストを分散するALB、HTTP APIを公開するAPI Gateway、ファイルを保存するS3とは担当が異なります。画像、JavaScript、HTMLの配信はCloudFrontとS3の組み合わせが分かりやすく、ログイン後の動的画面はCloudFrontの背後にALBを置く構成もあります。Lambdaを呼ぶ問い合わせAPIは、API Gatewayを入口にするのが自然です。
いずれか一つが他を完全に置き換えるわけではありません。常駐アプリへリクエストを振り分けるならALB、APIの認証やルートを扱うならAPI Gateway、オブジェクトを保管するならS3、利用者に近い場所で配信を最適化するならCloudFrontです。ALB・NLB・CloudFrontの違いも併せて読むと境界が明確になります。
ビューアからオリジンまでの流れ
ブラウザなどのビューアがCloudFrontのドメインへアクセスすると、CloudFrontはリクエストに合うビヘイビアを選びます。エッジに有効なキャッシュがあればその場で返し、なければオリジンへ問い合わせます。オリジンはS3、ALB、API Gatewayなどです。取得したレスポンスは設定に応じてキャッシュされ、次回以降の同じ条件のリクエストで利用されます。
この順序を理解しておくと、障害時にも切り分けやすくなります。CloudFrontのURLで再現するか、オリジンで同じ問題が起きるか、古いキャッシュが返っていないかを分けて確認できます。オリジンを変えずに配信規則だけを調整できる点は、複数のコンテンツ種別を扱うサイトで役立ちます。
キャッシュキーとInvalidationの考え方
キャッシュキーは、CloudFrontが同じキャッシュとして扱うリクエストの単位です。URLのパスだけで判定するのか、クエリ文字列、特定のヘッダー、Cookieも区別に使うのかで結果が変わります。たとえば言語をCookieで出し分けるのにCookieをキーへ含めなければ、別の利用者向けの内容を返すおそれがあります。
逆に不要な値を多数含めるとキャッシュが細かく分かれ、ヒットしにくくなります。静的アセットなら内容のハッシュをファイル名へ入れ、更新時に新しいURLを配信する方法が扱いやすいことがあります。HTMLのように同じURLを更新する必要がある場合はTTLとInvalidationを使い分けます。Invalidationは有効な手段ですが、毎回無条件に実行する前にキャッシュ方針を見直します。
HTTPS、ACM、OACの防御範囲
利用者からCloudFrontまでの通信はHTTPSを前提にし、HTTPで来たリクエストをどう扱うかもビヘイビアで決めます。独自ドメインにはACMの証明書を関連付けますが、CloudFront用証明書を作成するリージョンの要件は設定前に公式ドキュメントで確認してください。HTTPSだけではS3オリジンの公開を防げない点が重要です。
OACはCloudFrontがS3オリジンへアクセスする際の制御です。Origin Access Control で S3 オリジンへのアクセスを制限するに沿って、バケットポリシーをCloudFront Distributionに限定します。CloudFront経由のURLは公開しつつS3のオブジェクトURLを直接読ませない設計は、S3とCloudFront OACで安全に静的サイトを配信する設計で確認できます。
料金と運用の注意
CloudFrontでは配信量、リクエスト、利用する機能などが費用へ影響します。無料枠や単価、利用条件は変わり得るため、設計時点の公式料金ページと請求画面を確認してください。転送量が増える画像や動画、キャッシュを効かせにくいURL設計、無差別なInvalidationは確認対象です。
運用ではキャッシュヒット率だけを追って終わりにしません。オリジンのエラー、4xx/5xx、配信ログを対応付け、必要に応じてWAFも組み合わせます。障害調査のためにオリジンを直接確認する経路を残す場合も、公開範囲を広げないアクセス制御を考えます。
試験で混同しやすい点
CloudFrontは特定リージョンに置くサーバーではなく、エッジロケーションを使う配信サービスです。S3はオブジェクトを保存するサービスであり、CloudFrontのキャッシュそのものではありません。またCloudFrontはHTTPSの構成要素になり得ますが、認可設計やオリジン保護を自動的に完結させるものではありません。
「世界中の利用者へ静的コンテンツを低遅延で配信」「オリジンの負荷を下げたい」という設問ならCloudFrontが候補です。「EC2上のアプリへパスベースで振り分ける」ならALB、「HTTP APIの認証と公開」が中心ならAPI Gatewayを優先して考えます。
よくある失敗と次の一歩
S3を全面公開してCloudFrontを別URLとして使う、Cookieやクエリを考えずにキャッシュする、更新直後の表示だけを見てキャッシュの影響を確認しない、といった失敗が起きがちです。まずS3を非公開にしてOACを設定し、静的アセットと動的レスポンスでキャッシュ方針を分けてください。
次はCloudFrontとS3で小さな静的サイトを公開し、ブラウザの開発者ツールでレスポンスヘッダーと更新反映を観察します。その後にALBやAPI Gatewayをオリジンに加えると、各サービスの境界を実感できます。
構成を確認するときのチェック項目
実際にDistributionを作ったら、オリジンが想定のS3バケットまたはエンドポイントを指しているか、各パスに適切なビヘイビアが選ばれるかを確認します。/images/*は長くキャッシュしてよい一方、/index.htmlは更新方針を別にしたい、といった区別を設定へ反映します。リダイレクト、404ページ、デフォルトルートも利用者が最初に触れる部分です。
アクセス制御は設定画面だけで判断せず、S3の公開ブロックとバケットポリシーを見直します。CloudFront経由では取得できるが、S3 URLへ直接アクセスすると拒否される、という実際の挙動まで確認して初めてOACの設定を検証できます。変更後にはキャッシュのため古い結果が残ることもあるので、テスト用の固有URLやレスポンスヘッダーを使って観察します。
CDNの導入後も、オリジンの障害時に何を返すか、キャッシュ済みのコンテンツをどこまで許容するかは設計上の判断です。配信が速くなったことだけで満足せず、更新、障害、アクセス制御の三つを運用手順に残してください。
本番切替の直後は、独自ドメイン、証明書、リダイレクト、主要な静的ファイルを利用者目線で確認します。キャッシュヒットの確認には、同じURLを繰り返し開くだけでなく、更新前後のバージョンを区別できるようにしておくと安全です。配信経路を一枚の図にしておくと、試験問題でも実運用でもサービスの役割を取り違えにくくなります。
複数のオリジンを使う場合は、どのパスがどのオリジンへ向かうかを明文化します。静的ファイルはS3、/api/*はAPI Gateway、アプリ画面はALBというように分けると、キャッシュポリシーとセキュリティポリシーを個別に調整できます。オリジン障害を隠す目的だけで古い内容を配り続けるのではなく、利用者にとって正確な情報が必要なページかも考えます。
CloudFrontの設定変更は即時に全利用者へ同じように見えるとは限りません。設定反映とキャッシュの反映を区別し、変更日時、対象パス、確認結果を記録します。画像のように更新頻度が低いものと、利用規約や価格案内のように正確な最新版が必要なものを同一のTTLで扱わないことが、配信品質と運用負荷の両方を整えます。
利用者へ返す内容の鮮度と、オリジンを守る効果の間には常に調整があります。ページ種別ごとに期待する更新速度を書き出し、キャッシュ設定の理由を残すと、後の変更でも判断を再利用できます。
関連用語
次に読む記事
次に学ぶ内容
ブログ記事だけでなく、AWS用語集・サービス比較・模擬問題・構成図を組み合わせると、資格知識と実装イメージをつなげて理解できます。