本記事は、2025 年 6 月 11 日に Networking & Content Delivery で公開された VPC resource gateways: Implementation patterns and use cases を翻訳したものです。 Amazon Virtual Private Cloud (Amazon VPC) 間でアプリケーションを接続する際、従来の AWS PrivateLink のプロバイダー・コンシューマーモデルに適合しないサービスへの接続が必要になると、VPC ピアリングや AWS Transit Gateway だけでは簡単に解決できない複雑なネットワーク課題に直面します。これは特に、IP アドレス空間が重複している場合に顕著です。 従来の PrivateLink の Provider-Consumer Model に適合しないサービスへの接続を、VPC リソースゲートウェイを使用することで実現でき、ネットワークアーキテクチャを簡素化できます。プロバイダーがサービスの前段に Network Load Balancer を配置することを求める VPC エンドポイントサービスとは異なり、リソースゲートウェイはロードバランサーインフラストラクチャの追加オーバーヘッドなしに、より幅広いターゲットを公開できます。 これまで複雑な追加設定が必要だったシナリオでも、追加インフラストラクチャの管理オーバーヘッドなしにサービスにアクセスできるようになりました。リソースゲートウェイは、ARN、DNS、または IP ベースのサービスへの接続を可能にしながら、セキュリティの維持、複雑さの軽減、コストの最適化を実現します。 リソースゲートウェイには複数のアクセス方法があります。 リソースエンドポイント 、 Amazon VPC Lattice サービスネットワークアソシエーション、および VPC Lattice サービスネットワークに接続された サービスネットワークエンドポイント です。本記事では、リソースへのアクセスを提供するために、リソースゲートウェイとリソースエンドポイントを使用したアーキテクチャパターンに焦点を当てます。Amazon VPC Lattice のサービスネットワークエンドポイントのユースケースと使用方法の詳細については、 こちらのブログ を参照してください。 以下のユースケースとトラフィックフローパターンを通じて、リソースゲートウェイの機能を理解していきましょう。 ユースケース 1：RDS リソースへのプライベートかつセキュアなアクセス 異なるビジネスユニットやアプリケーションコンポーネント間で厳密な分離を維持するために、マルチ VPC またはマルチアカウント戦略を採用している場合、アプリケーションサーバーとデータベースが異なる VPC や AWS アカウントに配置されます。また、このアーキテクチャパターンの要件は、合併・買収（M&A）の際にも発生します。 Amazon Relational Database Service (Amazon RDS) は、管理タスクを自動化することで従来型データベースの管理を簡素化します。 Amazon Aurora は、MySQL および PostgreSQL との完全な互換性を持つグローバルスケールのリレーショナルデータベースです。 Web/アプリケーションサーバーと RDS/Aurora データベースが異なる VPC に存在する場合、VPC ピアリングによる直接的な VPC 間通信や、AWS Transit Gateway / AWS Cloud WAN を使用したネットワーク接続のセットアップにより接続を確立できます。しかし、コンシューマーの数が急速に増加すると、これらの VPC ピアリング接続や AWS Transit Gateway / AWS Cloud WAN を経由するネットワークフローの管理オーバーヘッドが増大します。 リソースゲートウェイとリソース VPC エンドポイントを使用して、アプリケーションから Amazon RDS リソースへの接続を可能にできます。図1は、このユースケースのハイレベルアーキテクチャ図を示しています： 図1：RDS リソースへのプライベートかつセキュアなアクセス RDS リソースへのプライベートかつセキュアなアクセスを実現するために、以下の手順でリソースエンドポイントとリソースゲートウェイを構成できます： RDS リソースが存在する VPC にリソースゲートウェイを作成する。 アクセスしたい各 RDS クラスターまたはインスタンスに対して「ARN」タイプの リソース設定 を作成し、リソースゲートウェイに関連付ける。   注意 ：ARN ベースのリソースは現在、パブリックでない Amazon RDS リソースでサポートされています。ARN ベースのリソース設定の 子リソース設定 は、AWS によって自動的に管理されます。 （オプション） コンシューマー VPC と RDS VPC が異なる AWS アカウントにある場合、RDS VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に 「Resource」タイプの VPC エンドポイント を作成し、ARN タイプのリソース設定に関連付ける。VPC エンドポイントの作成時に、オプションで「Private DNS」を有効化する。Private DNS を有効にすると、リソース VPC エンドポイントを通じたプライベート接続を活用しながら、AWS サービスがリソースに対してプロビジョニングした DNS 名を使用してリクエストを続けることができます。   注意 ：Private DNS を使用するには、コンシューマー VPC の DNS ホスト名および DNS 解決が「有効」 （enableDnsHostnames, enableDnsSupport）に設定されていることを確認してください。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 VPC エンドポイントの Private DNS が有効時と無効時での動作を示す：   有効（推奨） ：RDS リソースの DNS 名（ライターエンドポイント、リーダーエンドポイント、またはインスタンスエンドポイント）を使用してリソースにアクセスできます。   無効 ：リソース VPC エンドポイントの DNS 名を使用して RDS リソースにアクセスします。ただし、これはデータベース証明書のコモンネーム（CN）を検証 していない 場合にのみ機能します。これは、リソース VPC エンドポイントの DNS 名が RDS/Aurora DB インスタンスの証明書のサブジェクト代替名（SAN）に含まれていないためです。 ユースケース 2：VPC IP CIDR が重複する環境での接続 CIDR が重複する VPC にコンシューマーとリソースが 存在する場合、それら間の直接通信が困難になります。このシナリオは、合併・買収時、パートナーネットワークへの接続時、または CIDR の計画が調整されていないマルチアカウント環境で一般的に発生します。この問題に対処する従来のソリューションには、NAT（ネットワークアドレス変換）を実行するアプライアンスの設定、NAT ゲートウェイの使用、または Network Load Balancer の作成と VPC エンドポイントサービスを使用したサービスの公開が含まれます。これらの解決策は有効ですが、追加リソースの作成が必要なため、複雑さとコストが増加します。 VPC リソースエンドポイントとリソースゲートウェイは、このような状況でコンシューマーがリソースにアクセスできるようにする、よりシンプルな代替手段を提供します。図2は、このユースケースのハイレベルアーキテクチャ図を示しています。 図2：重複 CIDR ユースケースにおけるリソースエンドポイントとリソースゲートウェイの使用 このケースでコンシューマーがリソースにアクセスできるようにするには、以下を実行します。 アクセス対象のリソースが存在する VPC にリソースゲートウェイを作成する。 リソースまたはリソースグループを表すリソース設定を作成し、リソースゲートウェイに関連付ける。 （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に、各リソース設定に対応する「Resource」タイプの VPC エンドポイントを作成する。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 リソース VPC エンドポイントの DNS 名を使用して、リソース VPC 内のリソースにアクセスする。フレンドリーな名前を使用してリソースにアクセスしたい場合は、「コンシューマー VPC」に関連付けられたプライベートホストゾーンを作成し、フレンドリー DNS 名をリソース VPC エンドポイントの DNS 名にポイントする CNAME レコードを追加できます。リソース VPC エンドポイントの DNS 名は、関連するリソース VPC エンドポイントを選択した際の「Associations」の下で確認できます。 図3：リソース VPC エンドポイントの DNS 名 ユースケース 3：パブリックドメインへの接続プロキシ パブリックエンドポイント宛ての通信であっても、一元化されたVPCを経由させるか、あるいはプライベートかつ制御されたネットワーク経路を使用することを義務付けるような厳格なポリシーを採用する場合を想定します。こうしたパブリックエンドポイントは、多くの場合 AWS 外の SaaS サービスか、AWS 上にありながら PrivateLink 経由ではプライベートに公開されていないサービスです。 リソースゲートウェイを使用して、集約 VPC 経由で、または AWS VPN 、 AWS Direct Connect 、VPC ピアリングなどのプライベート接続オプションを介したインクラウド接続ユースケースとして、パブリックエンドポイント（AWS またはサードパーティ）にアクセスできます。図4は、VPC 内のクライアントが集約 VPC とリソースゲートウェイを通じてパブリックエンドポイントにアクセスするハイレベルアーキテクチャ図を示しています。 図4：集約 VPC とリソースゲートウェイによるパブリックエンドポイントへのアクセス リソースゲートウェイを使用して集約 VPC 経由でパブリックエンドポイントへの接続を確立するには、以下のアプローチに従います： パブリックサブネットとプライベートサブネットを持つ VPC（「リソース VPC」）を作成する。VPC ルーティングを設定し、プライベートサブネットからインターネットへのトラフィックがパブリックサブネット内の NAT ゲートウェイを経由してルーティングされることを確認する。 リソース VPC のプライベートサブネットにリソースゲートウェイを作成する。 コンシューマーにアクセスさせたい各ドメイン名に対して、「DNS」タイプのリソース設定を作成する。各 DNS リソース設定は、コンシューマーにアクセスさせたい単一のドメイン名にマッピングされます。複数のドメイン名にアクセスさせたい場合は、複数のリソース設定を単一の「リソースグループ」にグループ化し、単一のリソース VPC エンドポイントで複数ドメインにアクセスできるようにできます。 （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS Resource Access Manager(RAM) を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に「Resource」タイプの VPC エンドポイントを作成し、リソース設定に関連付ける。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 プライベートホストゾーン（コンシューマー VPC に関連付け）を作成し、アクセスするパブリック FQDN をリソースエンドポイントの対応する DNS 名にマッピングする CNAME タイプのレコードを追加する。リソースエンドポイントの DNS 名の確認方法については、図2を参照。 プライベートホストゾーンで作成したレコードを使用して、アプリケーションからパブリックエンドポイントにアクセスする。 同様に、オンプレミスと AWS 間の確立済みプライベート接続を通じて、パブリックエンドポイントへのトラフィックをルーティングすることもできます。これにより、アウトバウンドインターネット接続を信頼できるエンドポイントに制限し、オンプレミスのクライアントがネットワーク分離を維持しコンプライアンス要件を満たしながら、パブリック FQDN とセキュアに通信できるようになります。図5は、オンプレミスのクライアントが AWS Site-to-Site VPN / AWS Direct Connect を介してリソースゲートウェイ経由でパブリックエンドポイントにアクセスするハイレベルアーキテクチャ図を示しています。 ※訳者注：集約 VPC の IGW からのアウトバウンド通信は TGW での接続が分かりやすく一般的ですが、TGW のデータ処理料金は $0.02/GB、リソースエンドポイントのデータ処理料金は $0.01/GB であり、本方式は特にデータ量が圧倒的である場合、コスト削減に大きく寄与します。 図5：集約 VPC とリソースゲートウェイによるオンプレミスからのパブリックエンドポイントへのアクセス ユースケース 4：Transit Gateway や VPC ピアリングを経由せずに AWS サービスのインターフェースエンドポイントを集約する インターネットを経由せずに AWS サービスへのプライベート接続を実現するには、インターフェース VPC エンドポイントを使用できます。しかし、各 VPC でサービスごとに個別のインターフェース VPC エンドポイントを作成すると、大きなコストと管理の複雑さにつながる可能性があります。そのため、より効率的なアプローチは、必要な すべてのインターフェースエンドポイントをホストする集約 VPC を用意し、AWS Transit Gateway または AWS VPC ピアリング接続を使用してコンシューマー VPC とリソース VPC 間の接続を確立し、集約 VPC エンドポイントへの接続を実現することです。 リソースゲートウェイとリソースエンドポイントは、このユースケース（特に大規模ネットワーク）に対処するための、よりシンプルでコスト効率の高いオプションを提供します。Transit Gateway アタッチメントよりも低い全体コスト（時間あたりおよびデータ処理）で、単一のリソースエンドポイントを作成して複数の AWS サービスエンドポイントにアクセスできます（集約 VPC エンドポイントが主なユースケースであることを前提）。図6は、このユースケースのハイレベルアーキテクチャ図を示しています。 図6：リソースゲートウェイを使用した集約 VPC エンドポイントへのアクセス リソースゲートウェイを使用して集約 VPC エンドポイントへのプライベート接続を確立する方法は以下のとおりです。 リソース VPC に、要件に応じた AWS サービスの集約インターフェース VPC エンドポイントを作成する。 リソース VPC にリソースゲートウェイを作成する。 各 AWS サービス VPC エンドポイントに対して、「DNS」のリソース定義を持つリソース設定を作成する。ドメイン名には、インターフェース VPC エンドポイントのリージョナル DNS 名を追加する（例： vpce-xxxx.ec2.<region>.vpce.amazonaws.com ）。   注意 ：リソースゲートウェイでは、リソース設定の DNS 名がパブリックに解決可能である必要があるため、インターフェース VPC エンドポイントのプライベート DNS 名は機能しません。 子 DNS リソース設定を持つリソースグループを作成し、リソースグループをリソースゲートウェイに関連付ける。 （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に「Resource」タイプの VPC エンドポイントを作成し、リソース設定に関連付ける。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 （オプション）異なるドメイン名を使用してサービスエンドポイントにアクセスしたい場合は、ドメイン名 <region>.amazonaws.com のプライベートホストゾーンを作成し、コンシューマー VPC に関連付ける。アクセスする各サービスに対してプレフィックス付きの CNAME タイプのレコードを追加し（例： <prefix>.ec2.<region>.vpce.amazonaws.com ）、リソースエンドポイントの対応する DNS 名にポイントする。TLS 検証が正常に行われるようにするため、プライベートホストゾーンとレコードは上記の形式である必要がある。 プライベートホストゾーンで作成したレコード（例： <prefix>.<region>.vpce.amazonaws.com ）、またはリソースエンドポイントの DNS 名を使用して、アプリケーションからインターフェースエンドポイントにアクセスする。 まとめ 本記事では、VPC リソースゲートウェイを使用して AWS 環境における複雑なネットワーク課題を簡素化する方法を説明しました。プライベートなデータベース接続の確立、IP アドレスが競合するネットワーク間の通信の実現、セキュアなインターネットアクセスの作成、AWS サービスアクセスの合理化について解説しました。これらのソリューションは、VPC リソースゲートウェイが強固なセキュリティを維持しながら一般的なネットワーク課題に対処する方法を示しており、成長に合わせたクラウドアーキテクチャの構築に有用なツールとなります。 AWS ネットワーク構成を簡素化する準備はできましたか？ VPC リソースゲートウェイ のドキュメントを参照して、今すぐリソースゲートウェイの実装を開始し、ご自身の AWS 環境でこれらのパターンを試してみてください。 翻訳はソリューションアーキテクトの長屋が担当しました。

こんにちは。アマゾン ウェブ サービス ジャパン合同会社 パートナーソリューションアーキテクトの深井 宣之です。 2026 年 6 月 5 日に AWS 公共パートナーネットワーク（PSN）セミナーとして「IT 基盤の環境変化に対応する AWS マイグレーション」と題した Webinar を開催しました。本ブログでは開催内容について Blog にまとめたものになります。投影資料もダウンロードすることが可能です。 本セミナーでは、アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター統括本部 パートナーアカウントマネージャーの坂口 雄一郎と、同 パブリックセクター技術統括本部 パートナーソリューションアーキテクトの深井 宣之が登壇し、ハードウェアの価格高騰や納期遅延、仮想化ソフトウェアのライセンス体系変更といった IT 基盤を取り巻く環境変化を踏まえ、AWS マイグレーションの全体像をご紹介しました。初級レベルの内容として、AWS やクラウドの知識がない方にもご参加いただける構成としています。 資料（PDF）の ダウンロードはこちら から可能です。 IT 基盤を取り巻く環境変化 近年、エンタープライズサーバーやメモリ、SSD ストレージなどハードウェアの価格高騰が続いており、リードタイムも延長しています。多くの現場では納期が読めず、入札や調達計画に影響が出ているのが実態です。 加えて、仮想化ソフトウェアのライセンス体系変更により、既存の IT 基盤を従来と同じコストで維持することが困難になるケースが増えています。 セキュリティ面では、AI を悪用したサイバー攻撃が高度化しており、Claude Mythos に象徴されるような AI 時代のセキュリティ脅威が現実のものとなっています。一方で、日本政府は行政機関での AI 徹底利活用を基本方針として決定しており、守りと攻めの両面での対応が求められています。 AWS が選ばれる理由 こうした環境変化を踏まえ、マイグレーション先の IT 基盤として AWS が選ばれる 7 つの理由を紹介しました。 IT リソース調達時間の短縮 — オンデマンドで即座にリソースを確保でき、数か月の調達リードタイムから解放 コスト最適化 — 従量課金モデルにより、使った分だけの支払いが可能 継続的な値下げ — AWS はこれまで 161 回 (2026年 5月時点) の値下げを実施 耐障害性と高可用性 — グローバルインフラストラクチャにより、マルチ AZ 構成での高可用性を実現 AI 時代に対応するセキュリティ — AWS は主要なコンプライアンスに準拠しておりその中で ISMAP 認定も取得。AWS では従前より AI を活用したセキュリティの高度化に取り組む 最新 AI サービスへのアクセス — Amazon Bedrock をはじめとする AI サービスや、Anthropic 社との戦略的提携による最新モデルへのアクセスが可能 移行を成功に導くためのソリューション — 移行ツールやプログラムが充実 AWS マイグレーションの進め方 移行パス AWS では移行戦略として 7 つのパス（7R）を定義しています。多くのケースではリホスト（Lift-and-shift）で移行し、まず AWS に移行することでハードウェア保守から解放され、空いた工数でモダナイゼーションに注力する段階的アプローチが一般的です。 リロケート: Amazon Elastic VMware Service (Amazon EVS) VMware 環境をそのまま AWS に移行する場合は、Amazon Elastic VMware Service（Amazon EVS）が活用できます。東京リージョンで既に利用可能です。 リホスト: AWS Application Migration Service（AWS MGN） OS やアプリケーションをそのまま移行するリホストには AWS MGN が利用できます。継続的にデータをレプリケーションし、ダウンタイムを最小化します。エージェント型とエージェントレス型の 2 つの方式があります。 データベース移行: AWS Database Migration Service (AWS DMS) と AWS Schema Conversion Tool (AWS SCT) データベースの移行には AWS DMS が利用できます。異なるエンジン間の移行では AWS SCT を併用します。 モダナイゼーション: AWS Transform AWS Transform は大規模な移行とモダナイゼーションのための初のエージェント型 AI サービスです。 コスト把握: Migration Evaluator 移行後コストを事前に把握する無料サービスです。約 1 週間のデータ収集後に評価レポートを提示します。 MAP（Migration Acceleration Program） MAP は移行時の二重投資負荷を軽減するため、クレジットや現金還元を提供するプログラムです。MAP の詳細は AWS Partner Central をご参照ください。 お客様事例 東京都中央区 — Amazon WorkSpaces による VDI 刷新 オンプレミス VDI のレスポンス低下を Amazon WorkSpaces で解消。基幹系・内部事務系の両セグメントで利用しています。 岩手県教育委員会 — 共同利用型校務支援システム 全 33 市町村が共同利用する校務支援システムの基盤として AWS を採用。校務支援システムを含む学校関連のIT基盤では、長崎県、新座市、名古屋市、福岡市でも実績があります。 同志社大学 — 情報インフラの全体最適化 4 系統の情報インフラを AWS に移行。AWS MGN を活用し、ダウンタイム削減とコスト最適化を実現しました。 おわりに IT 基盤を取り巻く環境は大きく変化しています。AWS はこうした環境変化への対応を支援します。ご興味をお持ちの方は御社担当の Partner Account Manager にお気軽にご連絡ください。 このブログは、アマゾン ウェブ サービス ジャパン合同会社 パートナーソリューションアーキテクト 深井 宣之が執筆しました。

本文は 2026年6月26日 に公開された AWS Cloud WAN Routing Policy: Real-World Global Network Scenarios (Part 2) を翻訳したものです。 Part 1 では、 AWS Cloud WAN のルーティングポリシーを紹介し、グローバルネットワーク全体でルート伝播とパス選択に影響を与えるためのきめ細かな制御をどのように使用できるかを示しました。各ルーティングポリシーは、3つの主要コンポーネントで構成されます。1) マッチ条件：ルートプレフィックスまたは BGP 属性を評価します。2) アクション：マッチしたルートの処理方法を決定します。3) 方向性：ポリシーをインバウンドとアウトバウンドのどちらのルート伝播に適用するかを指定します。これらの構成要素は、アタッチメント、セグメント、またはリージョンのレベルで適用できます。 本記事では、これらの概念を踏まえ、ハイブリッド環境やマルチサイト環境で一般的に見られる3つの実運用シナリオを取り上げます。AWS Cloud WAN のルーティングポリシーを使用して、 AWS Transit Gateway 環境からの移行中にルーティングを制御する方法、ローカルプリファレンスを使用して複数の AWS Direct Connect ロケーション間のパス選択を改善する方法、そして同一の BGP 自律システム番号（ASN）を持つネットワーク間の接続を許可する方法を学びます。 これらのパターンは、AWS Cloud WAN を集中型のポリシー適用ポイントとして使用し、グローバルネットワーク全体のルーティング制御を簡素化する方法を示しています。 本記事で説明するシナリオは、網羅的なリストではありません。AWS Cloud WAN のルーティングポリシーは、ここで扱う以外にも追加のマッチ条件とアクションをサポートしているため、お客様の環境固有のルーティング課題に対応できます。利用可能なマッチ条件とアクションの完全なリストについては、 AWS Cloud WAN ルーティングポリシーのドキュメント を参照してください。 前提条件 本記事は、2部構成のシリーズの第2回です。マッチ条件、アクション、方向性、基本的な設定ワークフローなど、ルーティングポリシーの基礎を扱った Part 1: AWS Cloud WAN Routing Policy — Fine-grained controls for your global network を既に読まれていることを前提とします。また、 Amazon Virtual Private Cloud（Amazon VPC） 、AWS Cloud WAN、AWS Direct Connect、 AWS Site-to-Site VPN などの主要な AWS ネットワークサービス、および AS-path、ローカルプリファレンス、コミュニティ属性といった概念を含む Border Gateway Protocol（BGP） の基礎を理解していることを前提とします。AWS Cloud WAN のハイブリッド接続パターンに関する補足的な背景情報については、 Simplify global hybrid connectivity with AWS Cloud WAN and AWS Direct Connect integration を参照することを推奨します。 補足：AWS Cloud WAN のルーティングポリシーには、コアネットワークポリシーバージョン 2025.11 以降が必要です。本記事で説明する設定を実装する前に、コアネットワークがこのバージョンで動作していることを確認してください。 シナリオ1：既存の Transit Gateway 環境からのルート伝播の制御 AWS Cloud WAN を採用する場合、既に AWS Transit Gateway 上に構築された既存環境を運用しているかもしれません。移行中は、これらの環境を AWS Cloud WAN に接続することで、一度きりのカットオーバーではなく、段階的な移行が可能になります。 こうしたアーキテクチャでよくある要件は、AWS Cloud WAN が Transit Gateway から学習したルートを、ネットワークの他の部分、特に AWS Direct Connect や AWS Site-to-Site VPN を通じて接続されたオンプレミス環境にどのように伝播するかを制御することです。 次の図（図1）は、ルーティングポリシーが適用されていない場合に、AWS Cloud WAN 内でルートがどのように学習され、伝播されるかを示しています。この例では、ap-southeast-2 リージョンの Transit Gateway が、AWS Direct Connect を通じてオンプレミスのデータセンター（DC1）に接続されています。この Transit Gateway が AWS Cloud WAN にアタッチされると、DC1 は重複したルートを受信し始めます。1つ目のルートセットは、Transit Gateway から直接伝播されます。2つ目のセットは AWS Cloud WAN 自体から来るもので、AWS Cloud WAN は Transit Gateway ルートテーブルのアタッチメントから同じルートを学習し、それらを Direct Connect 経由で DC1 に再配布します。ルーティングポリシーがない場合、このルートの重複は、非効率的または予測不可能なルーティング動作につながる可能性があります。 図1：ルーティングポリシーがない場合のルート伝播動作 AWS Cloud WAN のルーティングポリシーは、BGP コミュニティのタグ付けとフィルタリングによってこの問題を解決し、どのルートをオンプレミス環境にアドバタイズするかを正確に制御できるようにします。 図2：ルーティングポリシー適用後のルート伝播動作 図2に示すように、Transit Gateway は自身の production ルートテーブルを AWS Cloud WAN の production セグメントに接続します。ルーティングポリシーは2つのステップで動作します。第1に、Transit Gateway ルートテーブルのアタッチメントから学習したルートに、BGP コミュニティ値（65000:1 など）をタグ付けします。第2に、このコミュニティタグを、production セグメントから hybrid セグメントへルートを共有する際のフィルタとして使用します。タグ付けされたルートは、hybrid セグメントの Direct Connect ゲートウェイ（DXGW）へはそれ以上アドバタイズ（伝播）されません。 その結果、オンプレミスのデータセンターは Transit Gateway から直接ルートのみを受信することになり、重複したアドバタイズが排除され、Transit Gateway が同じデータセンターに接続されたままのアーキテクチャにおけるルーティングの競合を回避できます。 補足：AWS Cloud WAN に直接アタッチされた新しい VPC は、Transit Gateway の背後にある既存の VPC が AWS Cloud WAN 上の VPC と通信できるように、自身の Classless Inter-Domain Routing（CIDR）ブロックを Transit Gateway にアドバタイズします。ただし、これらの CIDR ブロックは、その関連付けの 許可プレフィックスリスト に含まれていない限り、Transit Gateway の Direct Connect ゲートウェイの関連付けを通じてオンプレミスにはアドバタイズされません。これにより、Cloud WAN の VPC ルートが Transit Gateway パス経由で DC1 にアドバタイズされるのを防ぎ、AWS Cloud WAN の Direct Connect ゲートウェイをオンプレミスへの唯一のパスとして残します。 仕組み 既存の Transit Gateway から学習したルートは production セグメントに入り、アタッチメントのインバウンドポリシーによってコミュニティ 65000:1 でタグ付けされます。production の VPC と AWS Cloud WAN のリソースは、Transit Gateway のワークロードに通常どおり到達できます。一方、production のルートが hybrid セグメントと共有される際、アウトバウンドのセグメントフィルタリングポリシーがコミュニティタグ 65000:1 にマッチし、それらのルートをドロップします。その他すべての production ルート（VPC からのルート）は hybrid セグメントに通過し、Direct Connect 経由でオンプレミスにアドバタイズされます。これにより、同じ Transit Gateway に依然として直接接続されているデータセンターへの重複したルートアドバタイズを防ぎます。 ステップ1：Transit Gateway のルートにコミュニティをタグ付けする（Transit Gateway ルートテーブルアタッチメントでインバウンド） このインバウンドポリシーを、AWS Cloud WAN の Transit Gateway ルートテーブルアタッチメントに適用します。このポリシーは、Transit Gateway から学習したすべてのルートにマッチし、コミュニティ 65000:1 でタグ付けします。 { "routing-policies": [ { "routing-policy-number": 100, "routing-policy-name": "tagTgwRoutes", "routing-policy-description": "Tag routes learned from existing TGW with community 65000:1", "routing-policy-direction": "inbound", "routing-policy-rules": [ { "rule-number": 10, "rule-definition": { "match-conditions": [ { "type": "prefix-in-cidr", "value": "0.0.0.0/0" } ], "condition-logic": "and", "action": { "type": "add-community", "value": "65000:1" } } } ] } ] } ステップ2：セグメント共有時にタグ付けされたルートをフィルタリングする（prod → hybrid） このアウトバウンドポリシーを、production セグメントから hybrid セグメントへルートを共有する際に適用します。このポリシーは、コミュニティ 65000:1 を持つルートにマッチしてドロップし、Transit Gateway 由来のルートが hybrid セグメントおよび Direct Connect 経由でオンプレミスの DC に伝播されるのを防ぎます。コミュニティ値 65000:1 にマッチしないルートは暗黙的に許可され、通常どおり伝播を続けます。AWS Cloud WAN のルーティングポリシールールはデフォルト許可（default-allow）を基本として動作し、ドロップルールによって明示的にマッチしたルートのみがフィルタリングされます。 { "routing-policies": [ { "routing-policy-number": 200, "routing-policy-name": "filterRoutesToHybrid", "routing-policy-description": "Drop TGW-originated routes (community 65000:1) when sharing prod to hybrid", "routing-policy-direction": "outbound", "routing-policy-rules": [ { "rule-number": 10, "rule-definition": { "match-conditions": [ { "type": "community-in-list", "value": "65000:1" } ], "condition-logic": "and", "action": { "type": "drop" } } } ] } ] } ステップ3：ポリシーを配布ポイントに関連付ける 3.1 ルーティングポリシーラベルを使用して、タグ付けポリシーを Transit Gateway ルートテーブルアタッチメントに適用します。 { "attachment-routing-policy-rules": [ { "rule-number": 100, "conditions": [ { "type": "routing-policy-label", "value": "TgwInbound" } ], "action": { "associate-routing-policies": [ "tagTgwRoutes" ] } } ] } 関連付けを完了するには、routing-policy-label を Transit Gateway ルートテーブルアタッチメントに割り当てます。これは、アタッチメントの作成時に routing-policy-label パラメータを使用するか、AWS Cloud WAN コンソールで既存のアタッチメントを編集することで実行できます。このシナリオでは、ラベル TgwInbound を Transit Gateway ルートテーブルアタッチメントに割り当てます。 3.2 セグメント共有のレベルでフィルタリングポリシーを適用します。 { "segment-actions": [ { "action": "share", "mode": "attachment-route", "segment": "production", "share-with": [ "hybrid" ], "routing-policy-names": [ "filterRoutesToHybrid" ] } ] } シナリオ2：複数の Direct Connect ロケーション間でのパス選択の改善 複数のオンプレミスロケーションがある場合、耐障害性のために複数のサイトから同じプレフィックスをアドバタイズしていることが多いでしょう。これは可用性を向上させますが、AWS Cloud WAN が複数のロケーションから固有の優先度なしに同一のルートを受信するというルーティングの曖昧さを生み出します。追加の制御がなければ、トラフィックが適切に誘導されない場合に非効率的なルーティング決定につながる可能性があります。 ルーティングポリシーが適用されていない場合、AWS Cloud WAN はデフォルトのルーティング動作（ロンゲストプレフィックスマッチ）に依存し、ローカルプリファレンスやパスステアリングは行われません。図3に示すように、AWS Cloud WAN が同じプレフィックス（例えば DC2 から発信される 10.2.0.0/16）を3つの DXGW とサイトすべてから同時に学習する場合、DC2 を通る直接パスを優先するメカニズムがありません。その結果、DC2 宛てのトラフィックが代わりに DC1 や DC3 を経由して出ていくことがあり、不要なバックボーンの通過、レイテンシーの増加、コストの増加を招きます。 補足：このシナリオでは、オンプレミスのデータセンターが MPLS や AWS Direct Connect SiteLink などのバックボーンネットワークを通じて相互接続されており、フェイルオーバー時にサイト間でトラフィックを通過させられることを前提としています。 図3：ルーティングポリシーがない場合のルートパス選択 AWS Cloud WAN のルーティングポリシーは、ローカルプリファレンスなどの BGP 属性を使用して、パス選択を集中的に制御します。図4に示すように、各 DXGW アタッチメントに適用されたインバウンドルーティングポリシーがローカルプリファレンス値を割り当て、トラフィックを発信元のデータセンターへ誘導することで、最も直接的なパスが優先されるようにします。 図4：ルーティングポリシー適用後のルートパス選択 このシナリオでは、各データセンターが特定のプレフィックスのセットを保有しています。DC1 は 10.1.0.0/16 を、DC2 は 10.2.0.0/16 を、DC3 は 10.3.0.0/16 を発信します。耐障害性のため、3つの DC はいずれも、自身の Direct Connect ロケーションから3つすべてのプレフィックスをアドバタイズします。各 DC は専用の DXGW を通じて接続されており、DC1 は ASN 65010、DC2 は 65011、DC3 は 65012 を使用します。AWS Cloud WAN は3つの DXGW すべてから同じルートを学習し、ローカルプリファレンスを使用して各プレフィックスのトラフィックをその保有元 DC へ誘導します。他の DC は、セカンダリおよび第3（ターシャリ）のフェイルオーバーパスとして機能します。 AWS Cloud WAN の観点から見ると、このシナリオのパス優先度マトリックスは次のとおりです。 プレフィックス 1番目（ローカルプリファレンス 300） 2番目（LP 200） 3番目（LP 100） DC1: 10.1.0.0/16 DXGW 65010 DXGW 65011 DXGW 65012 DC2: 10.2.0.0/16 DXGW 65011 DXGW 65012 DXGW 65010 DC3: 10.3.0.0/16 DXGW 65012 DXGW 65011 DXGW 65010 仕組み 3つの DC はいずれも耐障害性のために3つすべてのプレフィックスをアドバタイズしますが、各プレフィックスは特定の DC に属します。AWS Cloud WAN が 10.1.0.0/16 を3つの DXGW すべてから学習すると、ルーティングポリシーは、DXGW 65010（保有元である DC1）から 300、DXGW 65011（DC2）から 200、DXGW 65012（DC3）から 100 のローカルプリファレンスを割り当てます。AWS Cloud WAN は最も高いローカルプリファレンスを持つパスを選択し、10.1.0.0/16 のトラフィックを DC1 経由で誘導します。DC1 の Direct Connect パスに障害が発生した場合、トラフィックは自動的に DC2（ローカルプリファレンス 200）、次いで DC3（ローカルプリファレンス 100）へフォールバックします。同じロジックが、DC2 保有のプレフィックス（プライマリは DXGW 65011、セカンダリは 65012、第3経路は 65010 経由）および DC3 保有のプレフィックス（プライマリは DXGW 65012、セカンダリは 65011、第3経路は 65010 経由）にも適用されます。 DXGW のレベルでは、VIF 上の BGP コミュニティ を通じて、追加のパス制御レイヤーが利用できます。各 DXGW にはプライマリとセカンダリの2つの VIF があり、コミュニティタグによってアウトバウンドトラフィックにどちらの VIF が優先されるかが決まります。高優先度には 7224:7300、低優先度には 7224:7100 を使用します。あるいは、アクティブ・アクティブの ECMP ロードバランシングのために、両方の VIF に 7224:7200 を適用することもできます。 この設定により、AWS Cloud WAN と DXGW は、インバウンドのルート優先設定を使用してアウトバウンドトラフィックをオンプレミスへ誘導します。対称ルーティングを実現するには、オンプレミスから AWS へ流れるトラフィックについても、オンプレミスのデバイスが同じパスを優先するように設定する必要があります。 補足：定義された3つのプレフィックスリストのいずれにもマッチしないプレフィックスは、明示的なローカルプリファレンスが設定されないまま通過し、3つの DXGW すべてにわたって非決定的なパス選択となります。オンプレミスから新しいプレフィックスがアドバタイズされるのに合わせて、プレフィックスリストを最新の状態に保つようにしてください。 ステップ1：各データセンター用のプレフィックスリストを定義する データセンターごとに個別のプレフィックスリストを作成し、そのサイトから発信される CIDR をグループ化します。プレフィックスリストは Amazon VPC マネージドプレフィックスリスト（カスタマーマネージドプレフィックスリスト）として作成され、その後プレフィックスリストエイリアスを使用してコアネットワークに関連付けられます。ルーティングポリシーがプレフィックスをマッチする際に参照するのは、このエイリアスです。例えば、10.1.0.0/16、10.2.0.0/16、10.3.0.0/16 をそれぞれ含む3つの マネージドプレフィックスリスト を作成し、エイリアス dc1Prefixes、dc2Prefixes、dc3Prefixes を使用してコアネットワークに関連付けます。 補足：–max-entries パラメータは必須で、プレフィックスリストが保持できるエントリの最大数を定義します。ここで使用している値 5 は任意のものであり、含める予定のプレフィックス数に応じて調整できます。 aws ec2 create-managed-prefix-list --prefix-list-name dc1Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.1.0.0/16 aws ec2 create-managed-prefix-list --prefix-list-name dc2Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.2.0.0/16 aws ec2 create-managed-prefix-list --prefix-list-name dc3Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.3.0.0/16 aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc1-prefix-list-arn> --prefix-list-alias dc1Prefixes aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc2-prefix-list-arn> --prefix-list-alias dc2Prefixes aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc3-prefix-list-arn> --prefix-list-alias dc3Prefixes ステップ2：DXGW アタッチメントごとにルーティングポリシーを定義する 各 DXGW は、それぞれ独自のインバウンドルーティングポリシーを持ちます。このポリシーは、パス優先度マトリックスに基づいて各プレフィックスにローカルプリファレンス値を割り当て、各プレフィックスを発信元 DC へ、決定的なフェイルオーバー順序で誘導します。 DXGW 65010（DC1）のポリシー。DC1 のプライマリ、DC2 と DC3 の第3経路： { "routing-policies": [ { "routing-policy-number": 100, "routing-policy-name": "pathPreferenceDxgw65010", "routing-policy-description": "DXGW 65010 (DC1): primary for DC1, tertiary for DC2, tertiary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}} ] } ] } DXGW 65011（DC2）のポリシー。DC2 のプライマリ、DC1 と DC3 のセカンダリ： { "routing-policies": [ { "routing-policy-number": 200, "routing-policy-name": "pathPreferenceDxgw65011", "routing-policy-description": "DXGW 65011 (DC2): secondary for DC1, primary for DC2, secondary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}} ] } ] } DXGW 65012（DC3）のポリシー。DC3 のプライマリ、DC2 のセカンダリ、DC1 の第3経路： { "routing-policies": [ { "routing-policy-number": 300, "routing-policy-name": "pathPreferenceDxgw65012", "routing-policy-description": "DXGW 65012 (DC3): tertiary for DC1, secondary for DC2, primary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}} ] } ] } ステップ3：ポリシーを DXGW アタッチメントに関連付ける 各ルーティングポリシーを routing-policy-label にマッピングし、次にラベルによってアタッチメントをマッチし、対応するルーティングポリシーを関連付ける attachment-routing-policy-rules を定義します。routing-policy-label を各アタッチメントに割り当てます。 { "attachment-routing-policy-rules": [ {"rule-number": 100, "conditions": [{"type": "routing-policy-label", "value": "dxgw65010inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65010"]}}, {"rule-number": 200, "conditions": [{"type": "routing-policy-label", "value": "dxgw65011inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65011"]}}, {"rule-number": 300, "conditions": [{"type": "routing-policy-label", "value": "dxgw65012inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65012"]}} ] } 次に、routing-policy-label パラメータまたはコンソールを使用して、対応する routing-policy-label を各 DXGW アタッチメントに適用します。このシナリオでは、ラベル dxgw65010inbound を DXGW 65010 アタッチメントに、dxgw65011inbound を DXGW 65011 アタッチメントに、dxgw65012inbound を DXGW 65012 アタッチメントに割り当てます。 シナリオ3：同一 ASN を持つネットワーク間の通信の許可 Wide Area Network（WAN）を構築する企業は、グローバル接続のために AWS のバックボーンインフラストラクチャをますます活用していますが、買収、有機的な成長、または一般的なデフォルト ASN 値を使用したマルチサイト展開などにより、プライベート ASN の重複に直面することがよくあります。複数のサイトが同一の ASN を使用している場合、BGP のループ防止機能が、AS-path にそのサイト自身の ASN を含むルートを拒否し、WAN 全体のエンドツーエンドの通信を妨げます。 このシナリオでは、2つの ASN の競合がエンドツーエンドの通信を妨げています。図5に示すように、DC1 と DC2（A）はどちらも ASN 65000 を使用しています。AWS Cloud WAN がそれらの間でルートを伝播すると、各サイトは AS-path に自身の ASN を検出するため、相手のルートを拒否します。これが BGP のループ防止機能を引き起こします。 図5：DC1 と DC2 間で BGP ループ防止機能を引き起こす ASN の競合 2つ目の競合（B）は、図6に示すように、ASN 64512 を使用する DC3 が、ap-southeast-2 の AWS Cloud WAN コアネットワークエッジ（CNE）の ASN と競合するというものです。これにより、DC3 のルートは ap-southeast-2 の CNE によってドロップされ、DC3 もその CNE からのルートをドロップします。 図6：DC3 と AWS Cloud WAN CNE 間の ASN の競合によるルート伝播のブロック これら2つの競合が組み合わさることで、3つのデータセンターすべてにわたって到達性が完全に失われる結果となります。 AWS Cloud WAN のルーティングポリシーは、replace-asn-list アクションによってこの問題に対処します。このアクションは、AS-path 全体を指定した ASN のセットで置き換え、ループ防止機能を引き起こす競合を取り除き、オンプレミスの BGP の番号を振り直すことなく接続を復元します。 図7に示すように、3つのデータセンターは AWS Cloud WAN を中央のグローバルバックボーンとして使用します。DC1 は ap-southeast-2 リージョンの Direct Connect を通じて接続し、DC2 は us-west-2 リージョンの Site-to-Site VPN を通じて接続し、DC3 はメトロファイバー経由で DC2 を通じて AWS Cloud WAN に到達します。インバウンドルーティングポリシーは、2つのアタッチメントポイントに適用されます。(1) DC1 用の Direct Connect ゲートウェイアタッチメント、および (2) DC2 用の VPN アタッチメントです。DC3 のルートは DC2 の VPN アタッチメントを経由して通過するため、そのアタッチメントのインバウンドポリシーが DC2 と DC3 の両方の ASN 置換を処理します。 図7：3つのデータセンターすべての接続を復元する ASN 置換ルーティングポリシー 次の表は、ASN の置換をまとめたものです。 ソース 元の ASN 置換後の ASN 理由 DC1（Direct Connect） 65000 65550 DC2 でのループ検出を回避 DC2（Site-to-Site VPN） 65000 65551 DC1 でのループ検出を回避 DC3（DC2 のメトロファイバー経由） 64512 65552 ap-southeast-2 の CNE ASN との競合を回避 重要：AWS Cloud WAN のコアネットワークエッジ（CNE）は、インバウンドルーティングポリシーが評価される前に、BGP AS-path のループ検出を実行します。CNE が自身の ASN と一致する ASN を持つルートを受信した場合、replace-asn-list アクションが実行される前にそのルートをドロップします。トポロジーを計画する際は、オンプレミスのルートが、受信側の CNE の ASN と一致する ASN を持たないようにしてください。 仕組み このアプローチは、各サイトに固有で競合しない置換 ASN を割り当てることで、どのサイトも伝播されたルートの中に自身の ASN を見ることがなく、また、どのルートもトポロジー内の CNE と競合する ASN を持たないようにするものです。DC1 が AWS Cloud WAN にルートをアドバタイズすると、Direct Connect ゲートウェイアタッチメントのインバウンドポリシーが、AS-path 全体を ASN 65550 で置き換えます。これらのルートは AWS Cloud WAN を通じて伝播し、AS-path に 65000 ではなく 65550 を含んだ状態で DC2 に到達するため、DC2 のルーターはループ検出を引き起こすことなくそれらを受け入れます。 DC2 がルートをアドバタイズすると、VPN アタッチメントのインバウンドポリシーが AS-path 全体を ASN 65551 で置き換えます。これにより DC1 は、AS-path に 65000 ではなく 65551 を含んだ状態でこれらのルートを受信するため、BGP のループ検出を防ぎ、DC1 と DC2 間の双方向通信を復元します。 DC3 については、ルートは ASN 64512（DC3）と ASN 65000（DC2）の両方を持った状態で、DC2 の VPN アタッチメントを通じて AWS Cloud WAN に入ります。インバウンドポリシーは AS-path 全体を単一の専用 ASN（65552）で置き換え、競合する2つの値を1回の操作で取り除きます。これにより、DC3 のプレフィックスが AWS Cloud WAN のルートテーブルに受け入れられ、DC1 およびクラウドリソースにアドバタイズされるようになります。 すべての置換 ASN（65550、65551、65552）は、コアネットワークエッジ用に設定された ASN 範囲の外から選択されています。ルーティングポリシーの置換値は、AWS Cloud WAN の CNE の ASN 範囲と重複できないためです。 ステップ1：DC1 の Direct Connect ゲートウェイアタッチメントにインバウンドポリシーを定義する このポリシーは、DC1 から到着する AS-path に ASN 65000 を含むルートにマッチし、それを 65550 に置き換えます。これらのルートが DC2 に伝播されるとき、AS-path には 65000 が含まれなくなるため、DC2 のルーターはそれらを受け入れます。 { "routing-policies": [ { "routing-policy-name": "replaceasndc1", "routing-policy-description": "Replace ASN 65000 from DC1 with 65550 to avoid loop detection at DC2", "routing-policy-direction": "inbound", "routing-policy-number": 100, "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 65000}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65550]}}} ] } ] } ステップ2：DC2 の VPN アタッチメントにインバウンドポリシーを定義する このポリシーは、2つのルーティングルールを使用して ASN の競合を解決します。 ルール10 ：DC3 の ASN（64512）を 65552 に置き換えます。 ルール20 ：DC2 の ASN（65000）を 65551 に置き換えます。 DC3 からのルートは DC2 を経由して通過するため、AS-path に両方の ASN を含みます。そのため、順序が重要です。replace-asn-list は AS-path 全体を上書きするため、DC3 のルートが専用の置換 ASN（65552）を受け取れるように、ルール10 を先に実行する必要があります。 もしルール20 が先に実行されると、DC2 の ASN にマッチして AS-path 全体を 65551 で置き換えてしまいます。DC3 のルートは依然として受け入れられ、接続は機能しますが、DC2 のルートと区別がつかなくなり、ルートの追跡やトラブルシューティングが難しくなります。 { "routing-policies": [ { "routing-policy-name": "replaceasndc2", "routing-policy-description": "Replace ASN 65000 from DC2 with 65551 and ASN 64512 from DC3 with 65552", "routing-policy-direction": "inbound", "routing-policy-number": 200, "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 64512}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65552]}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 65000}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65551]}}} ] } ] } ステップ3：ポリシーをアタッチメントに関連付ける routing-policy-label にマッチする attachment-routing-policy-rules を定義することで、各ルーティングポリシーをアタッチメントに関連付けます。routing-policy-label パラメータまたはコンソールを使用して、各アタッチメントに指定の routing-policy-label をタグ付けします。 { "attachment-routing-policy-rules": [ {"rule-number": 100, "conditions": [{"type": "routing-policy-label", "value": "dc1inbound"}], "action": {"associate-routing-policies": ["replaceasndc1"]}}, {"rule-number": 200, "conditions": [{"type": "routing-policy-label", "value": "dc2inbound"}], "action": {"associate-routing-policies": ["replaceasndc2"]}} ] } 最後に、routing-policy-label パラメータまたはコンソールを使用して、各アタッチメントに指定の routing-policy-label をタグ付けします。このシナリオでは、ラベル dc1inbound を DC1 の Direct Connect ゲートウェイアタッチメントに、dc2inbound を DC2 の VPN アタッチメントに割り当てます。 知っておくべきこと AWS Cloud WAN への Direct Connect ゲートウェイアタッチメントを作成する際、DXGW が接続する CNE を選択できます。各 CNE は自身のローカルリージョンの VPC ルートのみを DXGW にアドバタイズするため、関連付けを制限する特別な理由がない限り、シナリオ2に示すようにすべての CNE を選択することを推奨します。 IPv6 がサポートされています。同じマッチ条件、アクション、ポリシー構造が IPv6 プレフィックスにも適用されます（ワイルドカードマッチとして ::/0 を使用）。本記事で説明したすべてのシナリオにおいて、IPv6 のルート伝播に同一のルーティングポリシーパターンを適用できます。 シナリオ2に示すように複数の Direct Connect ゲートウェイをデプロイすると、単一の Direct Connect ゲートウェイ（DXGW）を使用する場合よりも、きめ細かなルーティング制御が可能になります。AWS Cloud WAN のルーティングポリシーは、VIF や DXGW のレベルで利用できるものよりも幅広い BGP 属性の制御を提供します。オンプレミス接続を複数の DXGW に分散させることで、ルーティングの決定を AWS Cloud WAN に移し、トラフィックエンジニアリングのためのより豊富なポリシー制御を利用できるようになります。 ルーティングポリシー内のルールは、rule-number の順に評価されます。評価を停止する終端アクションは drop と allow のみです。replace-asn-list、set-local-preference、add-community などのその他のアクションは非終端であり、評価は残りのルールへと続き、各変更が引き継がれていきます。replace-asn-list アクションは、個々の ASN を置換するのではなく、AS-path 全体を上書きします。その結果、先のルールによって変更されたルートは、後のルールがマッチするための元の ASN をもはや持ちません。シナリオ3の DC2 を経由する DC3 のルートのように、ルートが複数の ASN を持ちうる場合は、最も具体的なマッチが最初に適用されるようにルールを順序付けてください。 AWS Cloud WAN は、CNE ごとに BGP AS-path のループ検出を実行し、このチェックはインバウンドルーティングポリシーが適用される前に実行されます。受信ルートの AS-path に、そのアタッチメントが接続する CNE の ASN が含まれている場合、replace-asn-list ポリシーが変更を加える前にそのルートは拒否されます（詳細な例についてはシナリオ3を参照してください）。 クリーンアップ 本記事で説明したルーティングポリシーは、AWS Cloud WAN のコアネットワークポリシードキュメント内で定義されるものであり、単独で課金対象となるリソースを作成することはありません。これらの設定を削除するには、次の手順を実行します。 AWS Cloud WAN コンソールでアタッチメントを編集するか、AWS CLI を使用して、各アタッチメントから routing-policy-label を削除します。 ポリシーを参照している attachment-routing-policy-rules と、すべての segment-actions を削除します。 コアネットワークポリシーの routing-policies セクションから、ルーティングポリシーの定義（tagTgwRoutes、filterRoutesToHybrid、pathPreferenceDxgw*、replaceasn*）を削除します。 変更を適用するために、コアネットワークポリシーのバージョン更新を送信します。 シナリオ2でマネージドプレフィックスリストを作成し、それらが不要になった場合は、AWS CLI または AWS マネジメントコンソールを使用して削除します。 まとめ 本記事では、AWS Cloud WAN のルーティングポリシーが、ハイブリッド環境やマルチサイト環境における一般的なルーティングの課題をどのように解決できるかを示す、3つの実運用シナリオを取り上げました。コミュニティのタグ付けとフィルタリングを使用して Transit Gateway 環境からのルート伝播を制御する方法、ローカルプリファレンスを使用して複数の DXGW と Direct Connect ロケーション間のパス選択を改善する方法、そして AS-path の置換を使用して BGP の ASN の競合を解決する方法を紹介しました。ルーティングポリシー設定の基礎を扱った Part 1 と合わせて、これらのシナリオは、AWS Cloud WAN をグローバルネットワークの統合的なルーティング制御レイヤーとしてどのように使用できるかを示しています。始めるには、 AWS Cloud WAN のドキュメント を参照してください。 著者について Jordan Rojas Garcia Jordan は、AWS の Worldwide Specialist Organization に所属するシニアネットワークスペシャリストソリューションアーキテクトです。従来型のデータセンターネットワークの分野でキャリアをスタートし、2018年に AWS に入社しました。AWS では、クラウドネットワーキングソリューションの設計に注力し、AWS クラウドでネットワークを構築するためのガイダンスとベストプラクティスを提供しています。仕事以外では、旅行、新しい料理の開拓、ハイキングを楽しみ、二輪車と四輪車の運転への情熱を燃やしています。 Akeef Khan Akeef Khan は、オーストラリアのシドニーを拠点とする Amazon Web Services のソリューションアーキテクトです。Cross-Industries セグメントのお客様を担当し、小売業や QSR（クイックサービスレストラン）の組織が AWS を採用、運用、スケールできるよう支援しています。彼の専門分野はネットワーキングであり、AWS のサービスを使ってお客様のグローバルなネットワーク接続をシンプルにすることに情熱を注いでいます。仕事以外では、新しいテクノロジーの探求と継続的な学習を楽しんでいます。 翻訳は Solutions Architect の田村 大地が担当しました。原文は こちら です。