最終更新日: 2026-07-30
TOP(About this memo)) > 一覧(AWS) > CloudFrontの構成パターン
CloudFrontはAWSのCDN（Content Delivery Network）であり、ユーザーからのリクエストを受けて適切な配信元（Origin）へ転送し、必要に応じてコンテンツをキャッシュするサービス。
CloudFrontがコンテンツを取得する配信元。 例：ALB、S3、EC2、API Gateway
1つのDistributionに複数のOriginを登録できる。
どのパスをどのOriginへ転送するかを決めるルール。
例：
/api/* → ALB/cdn/* → S3CloudFrontはURLのパスを見て転送先を判断する。
CloudFrontは「画像だからキャッシュする」のではなく、Behaviorに設定されたCache Policyによってキャッシュするかどうかを決める。
代表的なManaged Policy
OriginがALBでもS3でもキャッシュ可能。CloudFrontはOriginの種類ではなく、BehaviorとCache Policyによってキャッシュを制御する。
例えばAPIのようにキャッシュ自体はしない（CachingDisabled）が、認証ヘッダーやCookieはOriginへそのまま転送したい、というケースではOrigin Request Policy側で転送対象を指定する。AWSは両方について代表的な設定をマネージドポリシーとして用意しており、自前で作らずそれらを選ぶだけで利用できることが多い。
CloudFrontからのみS3へアクセスできるようにする仕組み。
Browser
↓
CloudFront
↓
S3
S3への直接アクセスを防ぎ、安全にコンテンツを配信できる。
S3側のバケットポリシーでOACを許可する際は、許可対象を特定のCloudFront Distributionに限定する条件（そのDistributionのARNと一致するかどうか）を付けておくと安全。単にCloudFrontのサービスプリンシパルを許可するだけだと、同じアカウント内の別のDistributionからも誤ってアクセスできてしまう。
Browser
↓
CloudFront
↓
S3
HTML・CSS・JS・画像など、すべてS3から配信する。
CloudFront
│
┌──┴──┐
│ │
▼ ▼
S3 ALB
│
▼
API
例：
/ → S3/api/* → ALBReactやVueなどのSPAでよく採用される構成。
CloudFront
│
┌──┴──┐
│ │
▼ ▼
ALB S3
例：
/ → ALB/api/* → ALB/cdn/* → S3SSRアプリケーション（Next.jsなど）では画面表示をサーバーで生成するため、Web画面はALBへ転送する。一方で、動画や画像などの静的コンテンツのみS3へ振り分ける構成もよく採用される。
Behaviorを追加するだけでキャッシュ可能。
例：
/_next/static/*/logo.png/favicon.icoBrowser
↓
CloudFront（キャッシュ）
↓
ALB
構成を変えずに導入できるため、(IMO) 小〜中規模のシステムではよく採用される。
CloudFront
│
┌──┴────────┐
│ │
▼ ▼
ALB S3
│
▼
Next.js
例：
/ → ALB/api/* → ALB/_next/static/* → S3/images/* → S3Next.jsでは/_next/staticのファイル名にハッシュが付くため、長期間キャッシュしやすい。(IMO) 大規模サービスではこちらの構成が多い。