AWS Cloud WAN Routing Policy：実運用におけるグローバルネットワークのシナリオ集 (Part 2)

本文は 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 の田村大地が担当しました。原文はこちらです。

Amazon Web Services ブログ