Amazon CloudFront のパブリックオリジンからプライベート VPC オリジンへの移行

はじめに

本稿は、2026 年 03 月 20 日に公開された “Migrate Amazon CloudFront public origins to private VPC origins” を翻訳したものです。

この記事では、さまざまな戦略を使用して Amazon CloudFront のパブリックオリジンを Amazon Virtual Private Cloud (Amazon VPC) オリジンに移行する方法を紹介します。また、クロスアカウントで VPC オリジンを使用することで、セキュリティを最優先としたアーキテクチャをサポートすることもできます。

CloudFront ワークロードのネットワークアーキテクチャを設計する際、集中型モデルと分散型モデルのいずれかを選択する必要があります。集中型アーキテクチャでは、専用のネットワーキングアカウントがすべての CloudFront ディストリビューションをホストし、複数のリソースアカウントにまたがるオリジンに接続します。各リソースアカウントは、Application Load Balancer (ALB)、Network Load Balancer (NLB)、Amazon Elastic Compute Cloud(Amazon EC2) インスタンスなどのオリジンインフラストラクチャをホストします。分散型アーキテクチャでは、各リソースアカウントが独自の CloudFront ディストリビューションとオリジンインフラストラクチャをそれぞれ管理するため、他のアカウントから独立したワークロード環境が構築されます。

VPC オリジンは、集中型と分散型のどちらのアーキテクチャモデルでも使用できます。アプリケーションをプライベートにしてパブリックインターネットから分離することで、セキュリティ体制が強化されます。 VPC オリジンを使用して CloudFront レイヤーでアクセス制御を管理することで、アプリケーションをパブリックインターネットから分離できます。また、オリジンインフラストラクチャに対する DDoS 攻撃のリスクも軽減されます。既存のワークロードで CloudFront VPC オリジンを有効にする方法はいくつかあります。適切な移行アプローチの選択は、現在の構成、ビジネスニーズ、運用要件によって異なります。ここからは、さまざまな移行戦略を紹介し、お客様の環境に最適な方法を選択するための主要な考慮事項とベストプラクティスについて説明します。

前提条件

CloudFront のパブリックオリジンをプライベート VPC オリジンに移行する前に、以下の準備が必要です：

AWS アカウントと権限

CloudFront および Amazon VPC リソースを管理するために必要な Amazon Web Services (AWS) Identity and Access Management (IAM) 権限
AWS Resource Access Manager (AWS RAM) (クロスアカウント共有の場合)
リソースが配置されている AWS リージョンとアベイラビリティーゾーン (AZ) で VPC オリジンがサポートされていることを確認

リソース設定

プライベートアプリケーションリソースのネットワーク要件を確立。CloudFront VPC オリジンの前提条件のドキュメントを参照してください。セキュリティグループを使用してオリジンを保護し、CloudFront からのインバウンド接続のみに制限からのインバウンド接続のみに制限
Amazon VPC のプライベートサブネット内に必要な ALB、NLB、または EC2 インスタンスを作成。これらのリソースを VPC オリジンとして設定
CloudFront とオリジン間で HTTPS 通信を行うための、有効な SSL/TLS 証明書と適切な暗号化設定の構成

Amazon VPC Block Public Access (BPA) の設定

BPA を使用している場合は、Amazon VPC 全体または特定のプライベートサブネットに対する Amazon VPC BPA 除外設定の作成。設定手順については、Amazon VPC BPA の基本のドキュメントを参照

VPC オリジンの設定

CloudFront コンソールまたは API を使用した VPC オリジンの作成。プライベートアプリケーションリソースを作成したリソースオーナーアカウントを使用
VPC オリジンのデプロイには最大 15 分かかる場合あり

テストと検証

プライベートアプリケーションリソース (ALB、NLB、または Amazon EC2 インスタンス) が本番環境へアクセス可能な状態であり、Amazon VPC 内からアクセス可能であることの確認
同じ Amazon VPC 内のテストインスタンスからプライベートオリジンへの接続をテストし、アプリケーションへのアクセスの確認
アプリケーションがパフォーマンスベンチマークを満たし、期待どおりにコンテンツを配信していることの検証

モニタリングメトリクス

Amazon CloudWatch メトリクス：4xxErrorRate、5xxErrorRate、OriginLatency を追跡し、オリジン接続の問題やパフォーマンス低下の特定
CloudFront ログ：アクセスログを確認し、オリジン接続の失敗、タイムアウトエラー、VPC オリジンからの予期しないレスポンスコードの確認
Amazon VPC フローログ：CloudFront から VPC オリジンへのトラフィックフローの確認。セキュリティグループルールで必要な接続が許可されていることの確認
アプリケーションログ：オリジンアプリケーションログを監視し、CloudFront との統合に問題があることを示すエラーやパフォーマンスの問題の確認

移行戦略

このセクションでは、CloudFront でパブリックオリジンからプライベート VPC オリジンへ移行するための戦略について説明します。これらの戦略を実施する前に、前提条件を完了しておく必要があります。

戦略 1：CloudFront 継続的デプロイの使用 (推奨)

CloudFront 継続的デプロイを使用すると、設定の変更を安全にテスト・検証でき、ステージング環境を本番環境に昇格させる前に変更内容をテストできます。このブルー/グリーンデプロイメントアプローチが推奨される移行戦略である理由は、ダウンタイムゼロの移行とロールバック機能が組み込まれているためです。また、本番トラフィックに影響を与える前に、VPC オリジンの接続性、パフォーマンス、機能を安全にテスト・検証できます。この戦略を図 1 に示します。
継続的デプロイメントでは、本番 (プライマリ) ディストリビューションをミラーリングするステージングディストリビューションが作成されます。ステージングディストリビューションに新しい VPC オリジンを設定できます。プライマリディストリビューションはパブリックオリジンからのトラフィック配信を継続します。ヘッダーベースまたは重みベースの方式で継続的デプロイメントポリシーを作成し、ステージングディストリビューションにトラフィックを振り分けることができます。

まず、特定のヘッダーでトラフィックをタグ付けしてテストを行うには、ヘッダーベースタイプでポリシーを有効にします。これにより、テストフェーズ中に発生する可能性のある問題を迅速に解決できます。Amazon VPC、ネットワーク、アプリケーションのパフォーマンスが検証され、問題が解決したら、ポリシーを重みベースタイプに更新します。

重みベースポリシーでは、本番トラフィックの特定の割合 (0%〜15%) をステージングディストリビューションにルーティングできます。最初は小さい割合から始め、徐々に増やしていくことができます。重みベースポリシータイプを使用する場合、セッションの維持を有効にできます。これにより、特定のユーザーセッションは、ビューワーセッションが閉じられるまで特定のディストリビューションに維持されます。検証が完了したら、1 回の操作でステージング設定を本番環境に昇格させます。詳細な手順については、「 Use CloudFront continuous deployment to safely validate CDN changes 」を参照してください。

図 1：CloudFront 継続的デプロイメント機能を使用したプライベート VPC オリジンへの移行

戦略 1 の考慮事項

キャッシュ：プライマリディストリビューションとステージングディストリビューションはキャッシュは別管理。CloudFront がステージングディストリビューションに最初のリクエストを送信した時点ではキャッシュは空であり、ビヘイビア設定に基づいてキャッシュを開始
トラブルシューティング：移行中に問題が発生した場合は、継続的デプロイメントポリシーでトラフィックの重みを 0% に削減。問題を調査・解決してから、トラフィックの割合を徐々に増加
セッション状態：継続的デプロイメントポリシーを無効または有効にすると、CloudFront はすべてのセッション (アクティブなセッションを含む) をリセットし、すべてのリクエストを新規として処理。セッションスティッキネスの無効化・有効化時にも同様
プロトコルサポート：現在、HTTP3 は継続的デプロイメントポリシーでは未サポート
ポリシー：重みベースポリシーを使用する場合、重みは 0〜15 の数値で指定

戦略 2：CloudFront エッジ関数の使用

既存の CloudFront ディストリビューションに、作成したプライベート VPC オリジンをオリジンとして追加します。次に、viewer-request トリガーを使用した CloudFront Function (サンプルコードは以下) を作成し、カスタムヘッダーまたはパブリックオリジンとプライベート VPC オリジン間の重み付けトラフィック分割に基づいて、トラフィックを VPC オリジンに振り分けます。その他の例については、GitHub の amazon-cloudfront-functions サンプルを参照してください。

import cf from 'cloudfront';

const kvsHandle = cf.kvs();

// Configuration: Update these values to match your CloudFront distribution origins
const PUBLIC_ORIGIN_DOMAIN = 'your-public-origin.example.com';  // Replace with your public origin domain
const PRIVATE_ORIGIN_ID = 'your-private-origin-id';              // Replace with your private VPC origin ID

async function handler(event) {
    const request = event.request;
    
    try {
        const config = await kvsHandle.get('routing_mode', { format: 'json' });
        
        if (config.mode === 'header') {
            const routeHeader = request.headers['x-route-origin'];
            if (routeHeader && routeHeader.value === 'public') {
                cf.updateRequestOrigin({
                    domainName: PUBLIC_ORIGIN_DOMAIN
                });
            } else if (routeHeader && routeHeader.value === 'private') {
                cf.selectRequestOriginById(PRIVATE_ORIGIN_ID);
            }
        } else if (config.mode === 'weighted') {
            const hash = simpleHash(event.viewer.ip);
            if (hash % 100 < config.weight_percentage) {
                cf.selectRequestOriginById(PRIVATE_ORIGIN_ID);
            } else {
                cf.updateRequestOrigin({
                    domainName: PUBLIC_ORIGIN_DOMAIN
                });
            }
        }
    } catch (error) {
        console.log('Routing error: ' + error);
    }
    
    return request;
}

function simpleHash(str) {
    let hash = 0;
    for (let i = 0; i < str.length; i++) {
        hash = ((hash << 5) - hash) + str.charCodeAt(i);
        hash = hash & hash;
    }
    return Math.abs(hash);
}

リクエストのルーティングモードは KVS で定義し、キーを「routing mode」、値を {"mode": "weighted", "weight_percentage": 70} または {"mode": "header"} に設定します。テストを開始するには、パブリックオリジンにトラフィックを転送する対象のビヘイビアに CloudFront Function を関連付けます。

まず、KVS の値を {"mode": "header"} に設定します。カスタムヘッダー x-route-origin の値を public または private に指定したリクエストを CloudFront に送信してテストを開始します。テストフェーズ中に発生する可能性のある問題を迅速に解決できます。

設定、ネットワーク、アプリケーションのパフォーマンスメトリクスを検証します。明らかな問題を解決した後、KVS を更新して重み付けでトラフィックをルーティング {"mode": "weighted", "weight_percentage": 5} します。まずトラフィックの 5% をプライベートオリジンに送信し、weight_percentage を徐々に 100% まで増加させます。プライベートオリジンがトラフィックを受信し、期待どおりに動作していることを確認したら、キャッシュビヘイビアを更新して、現在のパブリックオリジンの代わりにプライベートオリジンを使用するように変更します。その後、トラフィックがプライベート VPC オリジンにルーティングされていることを検証します。エラーがないことを確認したら、キャッシュビヘイビアから CloudFront Function を削除します。他のキャッシュビヘイビアについても同じプロセスを繰り返します。

図 2：CloudFront エッジ関数を使用したプライベート VPC オリジンへの移行

戦略 2 の考慮事項

キャッシュ：ディストリビューションは、設定されたキャッシュビヘイビアに基づいてリクエストをキャッシュ
トラブルシューティング：移行中に問題が発生した場合は、トラフィックの重みを 0% に削減。問題を調査・解決してから、トラフィックの割合を徐々に増加
オリジン設定：CloudFront Function でオリジン固有の設定を追加する場合は、オリジン変更のヘルパーメソッドを参照。特に指定がない限り、すべての設定はオリジン設定または関連するキャッシュビヘイビア設定から継承
CloudFront Function：ビヘイビアに既存の CloudFront Function が関連付けられている場合は、オリジン選択ロジックをサブ関数として実装し、メイン関数から呼び出す形で統合
KVS：関数コードの複雑さを軽減し、コード変更のデプロイなしでデータを更新可能。詳細な手順については、「CloudFront Functions 用の低レイテンシーデータストア、Amazon CloudFront KeyValueStore の紹介」を参照

戦略 3：既存ディストリビューションの更新 (インプレース移行)

このインプレースアップグレード戦略は、既存の CloudFront ディストリビューションを直接変更して、パブリックオリジンを VPC オリジンに置き換える方法です。このアプローチは最も迅速な移行方法ですが、サービスの中断を最小限に抑えるために、慎重な計画とメンテナンスウィンドウが必要です。この戦略を図 3 に示します。

まず、既存の CloudFront ディストリビューションに新しい VPC オリジンを作成し、キャッシュビヘイビアを更新してパブリックオリジンの代わりに新しいプライベートオリジンにトラフィックをルーティングします。すべてのビヘイビアの更新と検証が完了したら、古いパブリックオリジンの設定を削除できます。このアプローチは、プリプロダクション環境やテスト環境で VPC オリジンをテストする場合に最適です。本番環境では、戦略 1 に従うことを推奨します。本番ディストリビューションにインプレースで変更を行う場合は、アプリケーションに十分なメンテナンスウィンドウを確保してください。また、切り替え中にワークロードが中断に許容できることを確認してください。

図 3：キャッシュビヘイビアの更新によるプライベート VPC オリジンへの移行 (インプレース移行)

戦略 3 の考慮事項

CloudFront ディストリビューションの更新：新しい設定が更新されると、CloudFront はすべてのエッジロケーションへの変更の伝播を開始。エッジロケーションで設定が更新された後、CloudFront はそのロケーションから新しい設定に基づいてコンテンツの配信を即座に開始。それまでは、CloudFront は古い設定でコンテンツを配信
サービスの中断：ビヘイビアの更新プロセス中に、新しく作成したリソースでネットワークやアプリケーションに関連する問題が発生する可能性があるため、トラブルシューティング用に十分なメンテナンスウィンドウを確保
ロールバックの複雑さ：ロールバックにはビヘイビアの変更を元に戻す必要があり、パブリックオリジンの再作成が必要になる場合あり。変更を行う前に元の設定を記録しておくこと。
テスト要件：本番環境でインプレースアップグレードを実施する前に、非本番環境で VPC オリジンの接続性を十分にテスト
ビヘイビアの依存関係：複雑な設定を持つ複数のビヘイビアがある場合は、体系的に更新し、各変更を個別に検証

戦略 4：マルチテナントディストリビューションのプライベート VPC オリジンへの移行

マルチテナント CloudFront ディストリビューションは、パスベースまたはホストベースのルーティングを使用して、単一のディストリビューションで複数のアプリケーション、顧客、またはビジネスユニットにコンテンツを配信します。これらのディストリビューションを VPC オリジンに移行するには、分離とセキュリティ境界を維持しながら、どのテナントにも影響を与えないよう慎重な計画が必要です。この戦略を図 4 に示します。

マルチテナントディストリビューションでは、各テナントは親ディストリビューションから設定を継承し、独自のドメインを持ちます。オリジンはメインディストリビューション上で作成・設定され、テナントへのトラフィックルーティングのテンプレートとして使用されます。そのため、インプレース移行を行うと、オリジンがテナント間で共有されているため、すべてのテナントに影響を与える可能性があります。

推奨されるアプローチは、VPC オリジンを使用した新しいマルチテナントディストリビューションを作成し、各テナントを新しいディストリビューションに関連付けることです。これにより、各テナントを個別にテストし、テナントを 1 つずつ VPC オリジンを使用した新しいディストリビューションに移行できます。

図 3：キャッシュビヘイビアの更新によるプライベート VPC オリジンへの移行 (インプレース移行)

戦略 4 の考慮事項

ビヘイビアの整理：移行中の混乱を避けるため、テナントごとにビヘイビアがパスパターンまたはホストヘッダーで明確に整理されていることを確認
クロスアカウントの複雑さ：異なるテナントのオリジンが異なる AWS アカウントに存在する場合は、AWS RAM を使用して各アカウント間で VPC オリジン共有を適切に設定
テナントごとのテスト：次のテナントに進む前に、各テナントの移行を個別に検証
ロールバック計画：他のテナントに影響を与えずに個別のテナントをロールバックする必要がある場合に備え、テナントごとにロールバック手順を個別に文書化
コミュニケーション：各テナントまたはアプリケーションオーナーと調整し、希望するメンテナンスウィンドウ中に移行をスケジュール

その他の考慮事項

Origin Shield：パブリックオリジンで Origin Shield を使用していた場合、プライベート VPC オリジンでも引き続き使用可能。
オリジングループ：現在の CloudFront ディストリビューションでオリジングループを使用している場合は、新しいオリジングループを作成し、ビヘイビアをオリジングループにマッピングするよう設定が必要
レイヤー 7 の保護：AWS Shield Standard は、幅広い DDoS 攻撃から CloudFront ディストリビューションを保護。AWS では、プライベート VPC オリジンをレイヤー 7 の標的型攻撃から保護するために、AWS Shield Advanced および AWS WAF のインテリジェントな脅威緩和メカニズム (レイヤー 7 DDoS 緩和ルール、Bot Control など) によるディストリビューションの保護を推奨
クォータ：CloudFront のクォータを確認し、必要に応じて移行前に VPC オリジンに関連するクォータを引き上げ

クリーンアップ

継続的な課金を避けるため、トラフィックルーティングとテスト用に作成した未使用のリソースを削除してください。CloudFront ディストリビューションを削除する前に、すべてのトラフィックが移行済みで、DNS レコードが更新されていることを確認してください。移行テスト用にテスト ALB、NLB、または EC2 インスタンスを作成した場合は、不要であれば削除してください。

継続的デプロイ (戦略 1) を使用した場合は、ステージング設定をプライマリディストリビューションに昇格させます。エッジ関数 (戦略 2) を使用した場合は、CloudFront Function とその KVS の関連付けを解除して削除します。インプレース移行 (戦略 3) を使用した場合は、古いパブリックオリジンの設定を削除します。マルチテナントアーキテクチャ (戦略 4) を移行した場合は、すべてのテナントの移行完了後に古いマルチテナントディストリビューションを無効化して削除します。

クリーンアップが完了したことを確認するには、CloudFront コンソールでテスト関数と未使用のディストリビューションが削除されていることを確認します。さらに、AWS Cost Explorer を 24〜48 時間モニタリングし、一時リソースへの課金が停止していることを確認します。

まとめ

VPC オリジンへの移行は、パブリックエンドポイントを排除することでセキュリティ体制を強化します。アクセス制御は CloudFront レイヤーで管理できます。CloudFront のパブリックオリジンからプライベート VPC オリジンへ移行するための 4 つの移行戦略は、それぞれ移行速度、リスク軽減、運用の複雑さの間で異なるトレードオフを持っています。最適な移行アプローチは、既存の構成、ビジネスニーズ、および運用要件によって異なります。

移行を始める準備はできましたか？最初のステップは、現在のディストリビューション構成を十分に理解することです。それにより、ご自身の環境に最適な戦略を選択するために必要な知識が得られます。詳細な設定ガイダンスとベストプラクティスについては、CloudFront VPC オリジンのドキュメントをご覧ください。

CloudFront の機能やベストプラクティスに関する最新情報については、AWS Networking and Content Delivery Blog をフォローしてください。フィードバックがある場合は、コメントセクションにコメントを送信してください。質問がある場合は、Amazon CloudFront re:Post で新しいスレッドを開始するか、AWS Support にお問い合わせください。

著者

翻訳は Solutions Architect の長谷川純也が担当しました。

Amazon Web Services ブログ