はじめに AI エージェントをオープンソースのフレームワークで作ろうとすると、実装はもちろんですが「コンテナ化」「Webサーバー構築」「認証・セキュリティ統合」「スケーリング」「監視」「ロールバック」といった運用まわりの課題に直面することが多いのではないでしょうか。 Microsoft Foundry の Hosted Agents は、こうした "エージェントを動かし続けるための面倒ごと" をプラットフォーム側に任せ、開発者が エージェントの振る舞いそのものに集中できる ようにするためのフルマネージドな AI エージェント実行基盤です。 Microsoft Foundry 上で実行

LifeKeeperの『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策 こんにちは、SCSKの前田です。 いつも TechHarmony をご覧いただきありがとうございます。 システム基盤の主戦場がオンプレミスからパブリッククラウドへと移り変わり、AWSやAzure上でHAクラスタを構築する機会がぐっと増えました。クラウドでのインフラ設計において、「いかにクラウドリソースを最適化し、コストや構築の手間を抑えるか」は常に重要なテーマです。 そのため、サーバーのNICを最小限に抑えたり、オンプレミスと同じ感覚で同一サブネット内にネットワークをまとめようとしたり、監視用のサーバー（Witness）の台数を節約しようと考えるケースがよく見られます。 しかし、HAクラスターソフトウェアであるLifeKeeperをクラウド（特にAzure環境）で構築する場合、この「オンプレミス感覚のネットワーク設計」や「コストを意識した構成」が、思わぬ構築の壁となって立ちはだかることがあります。仮想IP（VIP）が正常に機能しなかったり、スプリットブレイン対策の構成要件を満たせず、設計の手戻りが発生してしまうのです。 本連載企画「LifeKeeper の『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策」では、サポートセンターに蓄積された「生のトラブル事例」を元に、安定運用のための実践的な知恵を共有していきます。 1. はじめに 前回の「カテゴリ3 第1弾」では、AWS環境における自動復旧機能との競合や回避策について解説しました。 第2弾となる今回は、 Microsoft Azure（以下、Azure）環境 にフォーカスします。 Azure環境での構築・運用において、サポート窓口には「オンプレミスの感覚でIPアドレスやサブネットを設定したら通信ができない！」といったネットワーク周りのご相談や、「スプリットブレイン対策（Quorum）の最適な構成・ディスクの選び方が分からない」というお問い合わせを数多くいただきます。 今回は、Azure環境においてハマりやすい「ネットワーク設計（IP割り当て・内部ロードバランサー連携）」 の罠と、スプリットブレインを防ぎつつリソースを最適化するための 「Quorum/Witness設計」の正解について、実際のサポート事例を交えて紐解いていきましょう！ 💡 前回の記事（カテゴリ3 第1弾）はこちら！ ▶ 【クラウド環境特有の落とし穴 #1】良かれと思った自動復旧が仇に！？AWS環境（EC2/Route53/S3）でハマる構成と回避策 – TechHarmony 2. 今回の「困った！」事例①：IP・ネットワーク設計の落とし穴 ❓ 事象の概要（困った！） 「Azure上のWindowsサーバー2台でLifeKeeperを構築予定です。コストや構築の手間を省くため、仮想IPリソースとDataKeeperのミラーリングで利用するNICを『同一サブネット』に配置したいと考えています。ただ、仮想IP自体は別セグメントにする予定ですが、動作やサポート要件に影響はありますか？」 🔍 原因究明のプロセスと判明した根本原因 オンプレミスであれば、柔軟にルーティングやVLANを設定して対応できるケースもありますが、Azure環境ではネットワークの仕組みが異なります。サポートで仕様と要件を確認したところ、Azure環境特有の厳しいルールが判明しました。 Azure上で仮想IP（VIP）を機能させるためには、ロードバランサー（ILB：内部ロードバランサー等）を用いたネットワーク切り替えが前提となります。この仕組みを正常に動作させるため、LifeKeeperの要件として「保護するNICごとに異なるサブネットを割り当てること」が必須（同一サブネットでの構成は未サポート）となっているのです。 💡 具体的な解決策（できた！） Azure環境でネットワークを構成する際は、以下の対応を行うことで正常に構築・運用が可能です。 異なるサブネットの割り当て  仮想IPリソースで使用するNICと、DataKeeperのミラーリング等で使用するNICには、必ず 別々のサブネット を用意して割り当てます。 サブネットマスクは「/32」に設定  IPリソースを作成する際、クラウド特有のルーティング競合を避けるため、サブネットマスクは必ず  255.255.255.255 (/32)  に設定します（これはクラウド環境共通の必須設定です）。 ロードバランサーの活用  VIPを機能させるためのILBを適切に構成し、LifeKeeperの可用性をさらに高めるために「LB Health Check リソース」の導入も検討しましょう。 ▼【図解】Azure環境におけるネットワーク構成のNG/OK例 3. 今回の「困った！」事例②：スプリットブレイン対策とQuorumの迷い ❓ 事象の概要（困った！） 「Azure環境でスプリットブレイン対策を行いたいのですが、StorageモードやMajorityモードなど選択肢が多く、どれを選べばいいか迷っています。Azureの共有ディスクは使えるのでしょうか？ また、複数クラスタがある場合、Witnessサーバーはクラスタごとに必要ですか？」 🔍 原因究明のプロセスと判明した根本原因 スプリットブレイン（ネットワーク分断により両ノードがアクティブになってしまう現象）の対策はクラスター運用の要ですが、クラウドでは共有ストレージの扱いやネットワーク構成がオンプレミスと異なるため、構成の選択に迷うお客様が多数いらっしゃいます。 サポートからの回答により、Azure環境における最適なアプローチが整理されました。 💡 具体的な解決策（できた！） お客様の要件や環境に合わせて、以下のいずれかの手法を選択するのがベストプラクティスです。 パターンA：共有ディスクを利用する場合  v9.6.2以降（Linux版の場合）、Azure共有ディスクを用いた「SCSI-3 Persistent Reservations」によるI/Oフェンシングがサポートされています。共有ストレージを利用できる構成であれば、これが推奨の対策の1つとなります。 パターンB：サーバー構成（Majorityモード）を採用する場合 クラスターノードとは別のサーバーを「Witness（監視）サーバー」として立てて多数決をとる手法です。Witnessサーバーは、クラスターノードと異なる可用性ゾーン（AZ）に配置することが推奨されます。 ★嬉しいポイント：複数のLifeKeeperクラスターが存在する場合、 1台のWitnessサーバーを複数クラスタで「共用（相乗り）」することが可能 です。これにより、構築コストと運用負荷を大幅に削減できます！ ▼【図解】複数クラスタでのWitnessサーバー共用（相乗り）イメージ クラスタごとに Witness サーバーを立てる必要なく、 1 台のWitnessサーバーで複数のシステムを監視してコストが削減出来るわね！ 4. 補足事例：DataKeeperのパフォーマンス設計（同期 vs 非同期）と潜むリスク Azureのようなクラウド環境（あるいは遠隔地へのDR構成）でDataKeeperを利用する際、避けて通れないのが「同期モード」と「非同期モード」の選択です。 ここでは、設計時に必ず議論になる「リージョン間の距離（ネットワーク遅延）」 と、 「障害発生時のリスク」の2つの観点から解説します。 1. 物理的な距離（レイテンシ）が性能に与える影響 DataKeeperの同期モードは、稼働系で書き込みが発生するたびに、ターゲット側へデータを送り、その「書き込み完了通知（ACK）」が戻ってくるまでアプリケーションの処理を一時待機させます。 同一リージョン内（可用性ゾーン：AZ間など）：  遅延が極めて小さいため、同期モードでも実用的なパフォーマンスが得られることが多いです。 リージョン間（東日本－西日本間など）：  ネットワークの「物理的な距離」に応じて通信遅延（レイテンシ）が大きくなります。同期モードを選択した場合、この遅延がそのまま「アプリの書き込みレスポンス低下」として現れます。 設計のポイント： 東日本と西日本を跨ぐようなDR（災害対策）構成で同期モードを採用する場合は、「性能低下を許容してでもデータ保全を優先する」 という明確な合意が必要です。パフォーマンスを最優先とするなら、距離の影響を受けにくい 「非同期モード」が第一の選択肢となります。 2. 障害発生時のデータロスと自動フェイルオーバー 非同期モードを選択する際、もう一つ理解しておくべきなのが「障害時の挙動」と「計画的な切り替え時の挙動」の違いです。 同期モード：  常に両ノードのデータが一致しているため、障害時もデータロスが発生せず、 最高レベルのデータ品質 を保てます。 非同期モード：  稼働系の書き込みを優先し、同期はバックグラウンドで行います。 ⚠️  【重要】非同期モードの落とし穴：  稼働系が突然ダウンした場合、待機系への 自動フェイルオーバー自体は正常に実行 されますが、まだ転送されていなかった「未同期のデータ（キュー）」は、フェイルオーバー時に すべて破棄（データロス）されます。これにより、復旧後にデータ不整合が生じるリスクがある点に注意が必要です。 💡 【補足】計画的な切り替えは安全： メンテナンス等で「手動でのスイッチオーバー」を行う場合は、LifeKeeperが未同期のデータをすべて送り終えてから切り替える 動作をします。そのため、非同期モードであっても手動切り替えであればデータロスや不整合は発生しません。 【結論：どう選ぶべきか？】 Azure環境における判断基準は以下のようになります。 項目 同期モード（推奨：同一リージョン/AZ間） 非同期モード（推奨：リージョン間/DR構成） 重視する点 データ品質・完全一致（ロスなし） アプリケーションの処理速度（レスポンス） 距離の影響 距離（東日本-西日本など）があると遅延する 距離に関わらず書き込み速度に影響しない 障害時の自動切り換え (フェイルオーバー) ロスなし・不整合なし 直前のデータ破棄・不整合のリスクあり 計画時の手動切り替え (スイッチオーバー) ロスなし・不整合なし ロスなし・不整合なし（同期完了を待つため） 💡 さらに深掘り！：非同期モードで「データ不整合」はどこまで起きる？ 「非同期モードでデータが破棄されると、ファイルが壊れてOSやDB（Oracle等）が起動しなくなるのでは？」と不安に思う方もいるかもしれません。しかし、DataKeeperにはそのリスクを最小限に抑える**「書き込み順序の整合性（Write Order Fidelity）」**という重要な仕組みがあります。 書き込み順序の保証：  DataKeeperはブロック単位で同期を行いますが、ソース側で書き込まれた順序を厳密に守ってターゲット側へ転送します。そのため、「新しいブロックだけが先に届き、古いブロックが欠落する」といった不自然な状態は発生しません。 「停電直後」と同じ状態（クラッシュ一貫性）：  障害発生時のターゲット側のディスクは、理論上**「ソース側のサーバーがある一瞬の時点で突然停電した際のディスク状態」**と等価です。 復旧のメカニズム：  最新の数ブロックが失われたとしても、ディスク全体としては「過去のある時点」の整合性が保たれています。そのため、フェイルオーバー後のOS（NTFS/ReFS等）やデータベース（Oracle等）は、自身の標準的なリカバリ機能（ログのロールバック等）を使って、不整合を解消し正常に起動することが可能な設計となっています。 【結論】 非同期モードは「直前のデータ（数秒分など）」を失う可能性はありますが、 「システムが二度と立ち上がらなくなるようなファイル破損」を防ぐための高度な転送制御 が行われています。パフォーマンスを優先しつつ、実用的な可用性を確保できるのが、DataKeeperが選ばれる理由の一つです。 5. 「再発させない！」ためのチェックリスト＆ベストプラクティス これまでの事例を踏まえ、Azure環境での構築前・設定時に確認していただきたいチェックリストを作成しました。ぜひ日々の運用や新規構築時にお役立てください！ ✅ 再発防止策（Azure構築前・設定時のチェックリスト） 【ネットワーク・IP設計】  仮想IPリソースに割り当てるサブネットマスクは  255.255.255.255 (/32)  に設定しているか？  各サーバーのNIC（IPリソース用とミラーリング用など）には、それぞれ 異なるサブネット を割り当てているか？（※同一サブネットは未サポート）  仮想IPを機能させるためのロードバランサー（ILB等）は適切に設計されているか？  LB Health Checkリソースの導入を検討し、フェイルオーバーの確実性を高めているか？ 【Quorum・データ保護設計】  スプリットブレイン対策として、自社環境に合ったフェンシング手法（SCSI-3 PR、Majorityモード等）を正しく選定できているか？  Majorityモードの場合、Witnessサーバーはクラスタノードと異なる可用性ゾーン（AZ）に配置するよう設計しているか？  DataKeeperの同期モードは要件に合っているか？（LAN環境/データ品質重視＝「同期」、WAN環境/レスポンス重視＝「非同期」） 💡 ベストプラクティス Azure特有の設定マニュアルを必ず参照する  Azure環境はオンプレミスや他のクラウドと動作原理が異なる部分があります。構築時は公式マニュアルの「Azure 特有の設定について」を必ずご一読いただき、OS（Windows/Linux）ごとの差異も確認してください。 Witnessサーバーの効率的な活用  複数クラスタを運用する場合、MajorityモードのWitnessサーバーは1台で共用可能です。無駄なリソースを省き、コストの最適化を図りましょう。 ログの監視ポイントを把握する  フェイルオーバーの成否やスプリットブレイン対策の挙動は、Linuxであれば  /var/log/lifekeeper.log  に記録されます。運用監視ツール等と連携し、このログを適切に監視する仕組みを整えることが安定稼働への近道です。 6. まとめ いかがでしたでしょうか。Azure環境でLifeKeeperを安定稼働させるためには、クラウド特有のネットワーク仕様（ILB連携やサブネット要件）と、ストレージ仕様（スプリットブレイン対策）を正しく理解することが成功の鍵となります。 「オンプレと同じで大丈夫だろう」と思い込まず、事前に公式ドキュメントや本記事のチェックリストを活用して、落とし穴を回避してくださいね！日々の運用でここを意識すれば、不要なトラブルは確実に防げます。 7. 次回予告 次回の連載テーマは「カテゴリ4：DataKeeperの落とし穴：データ保護とパフォーマンスのバランス」です。 DataKeeperのミラー同期トラブルや、性能ボトルネックと障害時動作の確認ポイントについて、実際のサポート事例からディープに解説します。お楽しみに！ 📚 本連載のバックナンバー 過去のトラブル事例と解決策もぜひあわせてご覧ください！ カテゴリ1：リソース起動・フェイルオーバー失敗の深層 ▶ 【リソース起動・フェイルオーバー失敗の深層 #1】EC2リソースが起動しない！クラウド連携の盲点とデバッグ術 – TechHarmony ▶ 【リソース起動・フェイルオーバー失敗の深層 #2】ファイルシステムの思わぬ落とし穴：エラーコードから原因を読み解く – TechHarmony ▶ 【リソース起動・フェイルオーバー失敗の深層 #3】設定ミス・通信障害・バージョン違いの深層と再発防止策 – TechHarmony カテゴリ2：OS・LKバージョンアップで泣かないために ▶ 【OS・LKバージョンアップで泣かないために #1】OSバージョンは変えていないのに！？カーネル更新の「落とし穴」と互換性の真実 – TechHarmony ▶ 【OS・LKバージョンアップで泣かないために #2】「設定が消えた！？」「亡霊IPが警告！？」を防ぐロードマップ：単純な上書き更新に潜む落とし穴と回避策 – TechHarmony カテゴリ3：クラウド環境特有の落とし穴 ▶ 【クラウド環境特有の落とし穴 #1】良かれと思った自動復旧が仇に！？AWS環境（EC2/Route53/S3）でハマる構成と回避策 – TechHarmony ▶ 【クラウド環境特有の落とし穴 #2】オンプレ感覚の「同一サブネット」はNG!?Azure環境のネットワーク要件とQuorum設計の最適解 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

はじめに 本稿は、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  にお問い合わせください。 著者 Kartik Bheemisetty Kartik Bheemisetty は US-ISV のお客様を担当するシニアテクニカルアカウントマネージャーであり、お客様が AWS クラウドサービスを活用してビジネス目標を達成できるよう支援しています。AWS のネットワークおよびコンテンツ配信サービスに関する専門知識を持っています。ベストプラクティスに関する専門的なガイダンスの提供、分野別専門家へのアクセスの促進、AWS の支出、ワークロード、イベントの最適化に関する実用的なインサイトの提供を行っています。 LinkedIn で彼とつながることができます。 Ravi Avula Ravi はエンタープライズアーキテクチャに注力する AWS のシニアソリューションアーキテクトです。ソフトウェアエンジニアリングにおいて 20 年の経験を持ち、決済業界でソフトウェアエンジニアリングおよびソフトウェアアーキテクチャの複数のリーダーシップ職を歴任してきました。 翻訳は Solutions Architect の長谷川 純也が担当しました。