今日のグローバルWebアプリケーションにおいて、ミリ秒単位の配信パフォーマンス向上はユーザー体験の向上やコンバージョン率の維持に欠かせないビジネス要件となっています。AWSにおけるエッジ配信の中核を担うのがAmazon CloudFrontです。
本記事では、一歩進んだクラウド設計・開発を行う技術者の方向けに、CloudFrontを活用したセキュアなオリジン保護、エッジにおけるカスタムロジックの最適設計、およびトラブルシューティングのベストプラクティスを解説します。
1. オリジン保護の進化：OAIからOAC、そしてVPC Originsへ
静的コンテンツの配信やWebアプリケーションを保護する上で、最も重要な原則の一つが「オリジンへの直接アクセスを遮断し、必ずCloudFrontを経由させる」ことです。このオリジン隠蔽とアクセスコントロールの手法は、近年劇的な進化を遂げています。
S3オリジンの新標準：Origin Access Control (OAC)
かつてはOrigin Access Identity (OAI) が広く使用されていましたが、現在はその後継であるOrigin Access Control (OAC)の利用が強く推奨されています。OACは、OAIが抱えていた以下の制限をすべてクリアしています：
- すべてのAWSリージョンに対応：2022年12月以降に登場したオプトインリージョンを含む、すべてのAmazon S3バケットで動作します。
- KMS暗号化オブジェクトのサポート：AWS KMSキー (SSE-KMS) で暗号化されたS3オブジェクトであっても、CloudFront側から安全にネイティブ認証をパスして取得できます。
- 動的リクエストのサポート：読み込み（GET）処理に特化していたOAIとは異なり、PUTやDELETEといった動的リクエストの認証にも対応しています。
⚠️ 注意（Website-Endpointの制約） S3バケットを「静的ウェブサイトホスティング（website endpoint）」として構成している場合、CloudFrontからは「カスタムオリジン」として認識されるため、OAC（およびOAI）を適用することはできません。アクセス制限の安全性を優先する場合は、S3のRESTエンドポイントを使用してOACを構成することを推奨します。
OAIからOACへのゼロダウンタイム移行
稼働中のシステムでOAIからOACへ移行する際、手順の順序を誤ると一時的にアクセス拒否（HTTP 403）のエラーが発生します。本番環境でダウンタイムなく安全に切り替えるには、以下の3ステップアプローチを行います：
- バケットポリシーの更新（二重許可）：S3バケットポリシーに、既存のOAI用の許可ステートメントを残したまま、新しく作成するOAC（CloudFrontサービスプリンシパル経由）の読み込み許可ステートメントを追記します。
- CloudFrontのオリジン設定切り替え：CloudFrontディストリビューションのオリジン設定をOACへ切り替え、デプロイが完全に完了するまで待ちます。これにより、OACによるリクエスト署名が有効化されます。
- レガシーOAIポリシーの削除：ディストリビューションが完全にデプロイされ、OAC経由でのアクセスが確認できたら、S3バケットポリシーから古いOAIのステートメントを削除してクリーンアップします。
VPC内のプライベートリソースを直接保護：VPC Origins
オンプレミスの物理サーバーや特定のロードバランサーを保護する場合、カスタムヘッダーによるアクセス制御を駆使してオリジンを検証する必要がありました。しかし、VPC Originsの登場により、セキュリティ設計は大きく簡素化されました。
VPC Originsを使用すれば、インターネット上のパブリックアクセスを一切持たないVPC内のプライベートサブネットに配置したApplication Load Balancer (ALB)、Network Load Balancer (NLB)、またはEC2インスタンスを、CloudFrontのオリジンとして安全に指定できます。 ユーザーからのリクエストは、CloudFrontからプライベートかつセキュアな接続を介してVPCに直接ルーティングされるため、パブリックインターネットへの露出（アタックサーフェス）を最小限に抑えることが可能です。
さらに、AWS Resource Access Manager (RAM) を利用したクロスアカウントVPC Origins（2025年11月サポート）にも対応しており、企業の「マルチアカウント戦略」に則り、中央のネットワークアカウントでCloudFrontを一括管理しつつ、各開発チームのアカウントにあるプライベートAPI（API GatewayやALB）をグローバル配信する、といった柔軟なゼロトラストアーキテクチャが構築できます。
2. エッジ機能の最適設計：CloudFront Functions vs Lambda@Edge
コンテンツのパーソナライズやセキュリティポリシーの適用、リクエストの動的ルーティングなどをエッジで高速に処理するために、CloudFrontでは2つのサーバーレスランタイムが用意されています。開発要件や制約に応じて、どちらを採用すべきか正しく見極める必要があります。
1. CloudFront Functions
軽量かつ極めて高速なJavaScript実行環境です。ビューワーリクエストおよびビューワーレスポンスのイベントに対して動作し、世界中のすべてのCloudFrontエッジロケーションでミリ秒未満の処理時間を実現します。
- 主なユースケース：URL書き換え（URIリライト）、HTTPヘッダーの追加・削除、クエリ文字列パラメータの正規化、シンプルなリダイレクトなど。
- 主な制約：
- ファイルシステムやリクエストボディ（BODY）へのアクセスは不可。
- 外部サービスを呼び出すネットワークアクセスは不可（関数は自己完結する必要あり）。
- コードサイズやコンピューティング実行時間（CPU使用率）に非常に厳格なクォータ制限が存在。
2. Lambda@Edge
AWS Lambdaの機能をCloudFrontのエッジ（地域ミドルキャッシュ）に拡張した、フル機能の汎用サーバーレスコンピューティングです。Node.jsやPythonを利用でき、より複雑でリソース集約的なタスクに適しています。
- 主なユースケース：依存関係にあるサードパーティ製ライブラリ（JWT署名の検証用ライブラリなど）を利用した詳細な認証認可、HLS/DASHといったストリーミング配信用マニフェストファイルの動的編集、リクエストボディの解析や外部データベースへの問い合わせ。
- 主な機能・仕様：
- サードパーティライブラリおよびAWS SDKの使用が可能。
- 外部ネットワークアクセスが可能（他のAWSリソースやAPIへのHTTPコールなど）。
- ビューワー側だけでなく、オリジンリクエスト/オリジンレスポンスのイベントにもトリガーを設定可能。
- 出力可能なレスポンスサイズ上限は最大1MB（ビューワーイベントでは最大40KB）。
エッジ機能の設計パターンと2026年最新ログ機能
エッジでのロジック実装において、パフォーマンス向上とデータ管理の分離を両立するために以下の2つの強力な機能が活用されます。
動的設定変更：CloudFront KeyValueStore
以前は、国ごとのリダイレクト先マッピングなどの構成データを関数コード内にハードコードする必要があり、設定変更のたびに関数の再デプロイが発生していました。 これを解決するのがCloudFront KeyValueStoreです。CloudFront Functionsからエッジで極めて低遅延で読み込み可能な安全なキーバリューストアであり、関数コードと構成データを完全に分離できます。キーバリューストア側をAPI等で動的にアップデートするだけで、ミリ秒未満で世界中のエッジロケーションに関数の設定変更を反映させることが可能です。
可観測性の向上：cf.logCustomData() (2026年7月新機能)
これまでCloudFront Functions内のログ出力（console.log()など）は、CloudWatch Logs（us-east-1リージョン）に別々のログストリームとして送られるため、CloudFront自体のアクセスログと動作検証を紐付ける作業（相関分析）に手間がかかっていました。
2026年7月にローンチされた cf.logCustomData() メソッドにより、CloudFront Functions内からCloudFrontの標準アクセスログ（v2）およびリアルタイムログに直接カスタムデータを挿入できるようになりました。 これにより、A/Bテストのグループ割り当て結果、認証の合否、エッジでの動的ルーティング判定といったカスタムデータをCloudFrontアクセスログの1レコードに集約できます。収集したログをAmazon S3へ出力し、Amazon Athena等で1クエリで統合分析できるようになり、デバッグやビジネス分析の作業効率が大幅に向上しています。
3. Webアプリケーション開発の難所：CORSエラーの解決
Webアプリケーションの開発段階、あるいはデプロイ後に頻発するエラーの一つがCORS (Cross-Origin Resource Sharing)エラーです。異なるドメイン（オリジン）からフォントやAPI、画像アセットなどを読み込もうとする際、ブラウザのセキュリティ制限によってリクエストが拒否されます。
CloudFrontを配置したアーキテクチャでCORSエラー（No 'Access-Control-Allow-Origin' headerなど）を根本解決するためには、以下の3つのアプローチを検討します。
1. レスポンスヘッダーポリシーの適用
CloudFrontのレスポンスヘッダーポリシー（Response Headers Policy）を使用すれば、オリジンサーバーを変更することなく、CloudFrontのエッジでレスポンスに対して自動的に必要なCORSヘッダーを追加・上書きしてビューワーに返すことができます。AWSが提供する「CORS制限解除のマネージドポリシー」を適用するか、独自のカスタムポリシーを作成してキャッシュビヘイビアに紐付けるだけで、安全かつシンプルに解決できます。
2. キャッシュキーへの「Origin」ヘッダーの含め方
CORSリクエストを正しく処理するためには、オリジンサーバーが要求する Origin ヘッダーや Access-Control-Request-Method ヘッダーなどをCloudFrontがキャッシュキーに含める、またはオリジンへのリクエスト転送時に正しく転送する必要があります。 CORSリクエストを考慮せずにキャッシュキーを構成すると、特定のドメイン用に返されたCORSヘッダー付きのレスポンスがCloudFrontにキャッシュされてしまい、別のドメインからアクセスしたユーザーにそのキャッシュが配信され、結果としてCORSエラーが引き起こされるという現象が発生します。適切なキャッシュポリシーとオリジンリクエストポリシーの選択が必要です。
3. S3バケットのCORSポリシー構成（RESTオリジン直接通信の場合）
S3オリジンから直接アセットをロードする場合は、S3バケット側にも適切なCORS構成ルール（AllowedOrigins、AllowedMethods、AllowedHeadersなど）を設定し、ブラウザからのプリフライト（OPTIONS）リクエストに対してS3自体が正しく応答できるように設計する必要があります。
4. まとめ：モダンなエッジ配信設計のチェックリスト
堅牢で高速なWebアプリケーションプラットフォームをCloudFrontで設計する際には、以下のチェックリストを参考にしてください。
- 静的コンテンツ（S3）オリジンには OAIではなくOAC を構成し、バケットポリシーを特定のディストリビューションARNに厳密にバインドしているか
- 内部のWebサーバーやALBは VPC Origins を用いてプライベートサブネットに配置し、パブリック経由でのバイパス（迂回アクセス）を完全に遮断できているか
- エッジロケーションでの軽量なリクエスト・レスポンス操作には CloudFront Functions を選択し、動的パラメータ管理には KeyValueStore を組み合わせているか
- 詳細な監査や可観測性のために、CloudFrontの標準アクセスログ（S3連携）、または分析用のリアルタイムアクセスログ（Kinesisストリーム連携）が正しく構成されているか
適切なコンポーネント選択と構成管理により、グローバルな攻撃の脅威からオリジンを守りつつ、エンドユーザーに対して超低遅延のアプリケーション体験を安全に提供しましょう。