はじめに — なぜ今、VPCオリジンへの移行が注目されているのか
Amazon CloudFrontは、世界中に分散したエッジロケーションを活用してコンテンツを高速配信するCDNサービスです。多くのシステムでは、CloudFrontのオリジンとしてALB（Application Load Balancer）やNLB（Network Load Balancer）、EC2インスタンスを利用しています。しかし従来のアーキテクチャでは、これらのオリジンをパブリックサブネットに配置し、インターネットからアクセス可能な状態にしておく必要がありました。
2024年11月20日、AWSはこの課題を根本から解決する新機能「CloudFront VPC Origins」を発表しました。この機能により、CloudFrontはVPCのプライベートサブネット内に置かれたALB・NLB・EC2インスタンスを直接オリジンとして利用できるようになりました。本記事では、従来構成の課題を整理したうえで、VPCオリジンへの移行方法と得られるメリットについて詳しく解説します。
従来のパブリックオリジン構成が抱えていた課題
CloudFrontのオリジンとしてALBを利用する場合、これまでは以下のような運用上の負担が生じていました。
課題 | 詳細 |
|---|---|
パブリックIPの必要性 | ALB・NLBをパブリックサブネットに配置し、パブリックIPを割り当てる必要があった。AZ×2で月約$7.20のコストが発生 |
アクセス制御の複雑さ | CloudFrontからのトラフィックのみ許可するため、マネージドプレフィックスリストの管理やカスタムヘッダーの設定・検証が必要だった |
攻撃面の拡大 | オリジンがインターネットに露出しているため、CloudFrontをバイパスした直接攻撃のリスクが存在した |
継続的な維持管理コスト | セキュリティグループやACLの定期的な見直しが必要で、運用オーバーヘッドが大きかった |
これらの課題は、セキュリティ要件が厳しいエンタープライズ環境や金融・医療系サービスにとって特に深刻でした。CloudFront VPC Originsは、こうした問題をアーキテクチャレベルで解消する機能です。
CloudFront VPC Originsとは何か
CloudFront VPC Originsは、CloudFrontがVPC内に「サービス管理ENI（Elastic Network Interface）」を自動生成し、プライベートサブネット内のリソースへ直接アクセスできる仕組みです。ALBやNLBに外部からのアクセスを一切許可しなくても、CloudFrontからのリクエストがプライベートネットワーク経由で届くようになります。
CloudFrontはVPC Origin作成時に CloudFront-VPCOrigins-Service-SG という名前のセキュリティグループを自動生成します。このセキュリティグループを活用することで、CloudFrontからのトラフィックのみをオリジンに許可するというシンプルかつ確実なセキュリティ境界を実現できます。
項目 | 内容 |
|---|---|
対応リソース | ALB、NLB（一部制限あり）、EC2インスタンス |
非対応リソース | Gateway Load Balancer、デュアルスタックNLB、TLSリスナー付きNLB |
非対応機能 | WebSockets、gRPC、Lambda@Edgeのオリジンリクエスト/レスポンストリガー |
追加費用 | なし（CloudFront通常料金のみ） |
対応リージョン | 商用リージョン（ap-northeast-1含む） |
なお、NLBをVPC Originとして利用する場合はセキュリティグループの設定が必須です。また、VPC Originを利用するサブネットはプライベートサブネットである必要がありますが、VPCにはインターネットゲートウェイのアタッチが引き続き必要です。
パブリックオリジンからVPCオリジンへの移行手順
既存のパブリックオリジン構成をVPCオリジンへ安全に移行するには、CloudFrontの「継続的デプロイメント（Continuous Deployment）」機能を活用したブルーグリーン方式が推奨されています。ダウンタイムなしで段階的に移行できるため、本番環境での運用リスクを最小化できます。
移行の大まかな流れは以下の通りです。
ステップ | 作業内容 |
|---|---|
1. VPC Originの作成 | CloudFrontコンソールの「VPC origins」からALB/NLB/EC2のARNを指定して作成。ステータスが「Deployed」になるまで最大15分待機 |
2. Staging Distributionの作成 | 既存のDistributionに対してStaging Distributionを作成し、オリジンをVPC Originに変更 |
3. ヘッダーベーステスト | 特定のリクエストヘッダーを持つトラフィックのみStaging Distributionへ誘導し、VPC Origin経由の動作を検証 |
4. ウェイトベース切り替え | 動作確認後、本番トラフィックの一部をStaging Distributionへ流し始め、段階的に割合を増やす |
5. 本番へのプロモート | 問題がなければStaging DistributionのコンフィグをPrimary Distributionへプロモート |
6. パブリック設定の削除 | オリジンのサブネットをプライベート化し、不要になったパブリックIP・セキュリティグループ設定を削除 |
ヘッダーベースのトラフィック分割では、テスト用クライアントにのみ特定ヘッダーを付与してリクエストを送ることで、本番への影響なく検証できます。ウェイトベースに切り替えた後は、5%・10%・50%と段階的に割合を引き上げながら監視を続けることが推奨されます。何か問題が発生した場合は、Staging DistributionをPrimary Distributionへのプロモートを中止してロールバックできます。
移行によって得られる具体的なメリット
VPCオリジンへの移行を完了したシステムでは、セキュリティ・コスト・運用の3つの観点で具体的な改善が期待できます。
観点 | 改善内容 |
|---|---|
セキュリティ | ALB・NLBがプライベートサブネットに移動し、インターネットからの直接アクセスが物理的に不可能になる。CloudFrontが唯一のエントリーポイントとなり、WAFやShieldの保護を確実に経由させられる |
コスト削減 | ALBのパブリックIPが不要になることで、AZ×2構成で月約$7.20のIPアドレス費用を削減。規模が大きいほど削減効果が大きい |
運用簡素化 | マネージドプレフィックスリストの更新管理やカスタムヘッダー検証ロジックが不要になる。セキュリティグループのルールが大幅にシンプルになる |
パフォーマンス | CloudFrontからオリジンまでのトラフィックがAWSの内部バックボーンネットワーク上を通るため、低遅延かつ安定した通信が保証される |
特にセキュリティの観点では、従来の「CloudFrontからのIPのみ許可」という設定はAWSがプレフィックスリストを更新するたびに追随する必要がありましたが、VPCオリジンでは自動生成されるサービス管理セキュリティグループがその役割を担うため、人的ミスや設定漏れのリスクが排除されます。
まとめ — CloudFront VPC Originsは移行を検討すべき機能
CloudFront VPC Originsは、追加費用なしでセキュリティ・コスト・運用効率を同時に改善できる強力な機能です。特に、既存のパブリックオリジン構成で「セキュリティグループの管理が煩雑」「ALBを外部から見えないようにしたい」「コンプライアンス要件を満たすためにオリジンのパブリック露出を排除したい」という課題を感じているチームには積極的に移行を検討する価値があります。
継続的デプロイメントを活用したブルーグリーン移行手順が整備されているため、本番環境でも安全に切り替えを進めることができます。WebSocketsやgRPCなどの非対応機能の有無を事前に確認したうえで、まずはStaging Distributionを使ったテストから始めてみることをお勧めします。AWSのマネージドサービスの進化を活用して、よりシンプルで堅牢なアーキテクチャへの一歩を踏み出してみてください。
