MS Word テンプレート _102504
偏向のない言語
この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
フィードバック
このドキュメントでは、AWS および Microsoft Azure を使用した Cisco Multi-Cloud Networking の設計オプションおよび展開に関する考慮事項について説明します。次のユースケースを取り上げます。
· クラウド ネイティブ ルーティング機能を使用したクラウドからインターネットへの接続
· オンプレミスの L3 外部（L3Outs）を介したクラウドから外部ネットワークへの接続
· クラウド ネイティブ ルーティング サービスを使用した外部サイトへの接続
· Microsoft Azure でのクラウド ネイティブ サービスの統合
· Microsoft Azure および AWS でのブラウンフィールド インポート
· AWS GWLB（ゲートウェイ ロード バランサー）によるファイアウォールの冗長性
このドキュメントは、読者が Cisco ACI および Multi-Cloud Networking テクノロジーの基本的な知識を持っていることを前提としています。
Cisco Cloud ACI および Multi-Cloud Networking は、複数のオンプレミス Cisco ACI データセンターおよびパブリッククラウドプラットフォーム全体でポリシーとネットワーク接続を管理する機能を提供します。詳細については、『Cisco Cloud ACI on AWS ホワイトペーパー 』および『Cisco Cloud ACI on Microsoft Azure ホワイトペーパー』を参照してください。
Cisco ACI サービスグラフは、ファイアウォール、ロードバランサ、侵入防御システム（IPS）などのレイヤ 4 からレイヤ 7 のサービスを挿入する機能を提供します。詳細については、『Cisco ACI サービスグラフの設計ホワイトペーパー』を参照してください。
このドキュメントで使用されている以下の用語を理解しておいてください。
· Cisco ACI および Multi-Cloud Networking の用語:
o Cisco Cloud Network Controller（以前の Cisco Cloud Application Policy Infrastructure Controller：Cisco Cloud APIC）*
o Nexus Dashboard Orchestrator（NDO）
o Virtual Routing and Forwarding（VRF）
o ブリッジドメイン（BD）
o エンドポイント グループ（EPG）
o レイヤ 3 外部（L3Out）または外部ルーティングネットワーク（L3Out）
o レイヤ 3 外部のサブネットベースの EPG（L3Out 外部 EPG）
o サービス グラフ
· AWS の用語：
o 仮想プライベート クラウド（VPC）
o Security Group（SG）
o Application Load Balancer（ALB）
o Network Load Balancer（NLB）
· Azure の用語：
o 仮想ネットワーク（VNet）
o ネットワーク セキュリティ グループ（NSG）
o アプリケーション セキュリティ グループ（ASG）
o Azure Application Gateway
o Basic Load Balancer
o Standard Load Balancer
o Microsoft Enterprise エッジルータ（MSEE）
*Cisco Cloud Network Controller リリース 25.0(5) より前は、Cisco Cloud Application Policy Infrastructure Controller（Cloud APIC）と呼ばれていました。このドキュメントでは、リリース 25.0(5) より前に記述されたセクションまたは 25.0(5) より前のリリースを示す文で、引き続き「Cloud APIC」および Cloud APIC アイコンを使用しています。
このドキュメントの主な目的は、Cisco Multi-Cloud Networking のユース ケースに関する設計ガイドラインを提供することです。ACI マルチクラウドは、オンプレミスの Cisco ACI、サイト、Amazon パブリッククラウド（AWS）、Microsoft Azure（Azure）などの複数のクラウド環境を相互接続するために使用するソリューションです。
次の図は、オンプレミスの ACI ファブリック、AWS 環境、および Microsoft Azure 環境を接続する Cisco Multi-Cloud Networking の簡単なトポロジの例を示しています。
図 1 に示すように、Cisco Multi-Cloud Networking は次のコンポーネントで構成されています。
· Cisco Nexus Dashboard Orchestrator（NDO）：NDO は中央ポリシーコントローラとして機能し、各クラウドサイトを独自の Cisco Cloud Network Controller によって抽象化して、複数のオンプレミスの Cisco ACI データセンターおよびパブリッククラウドプラットフォームに全体でポリシーを管理します。NDO は Nexus ダッシュボード上のサービスとして実行されます。Nexus ダッシュボードは、VMware ESXi、Linux KVM、Amazon Web Services、または Microsoft Azure で実行される物理アプライアンスまたは仮想マシンのクラスタとして展開できます。以前にバージョン間サポートが導入されているため、NDO は、異なるソフトウェアバージョンを実行しているオンプレミス APIC と Cisco Cloud Network Controller を管理できます。
· Cisco Cloud Network Controller（以前の Cisco Cloud APIC）：Cisco Cloud Network Controller は、サポートされているパブリッククラウド上で仮想インスタンスとして実行され、パブリッククラウド内の自動接続、ポリシー変換、およびワークロードのさらなる可視性を提供します。Cisco Cloud Network Controller は、NDO から受け取ったすべてのポリシーを変換し、それらをクラウドネイティブの構造（AWS の VPC やセキュリティグループ、Microsoft Azure の VNet、アプリケーション セキュリティ グループ、ネットワーク セキュリティ グループなど）にプログラムします。Cisco Cloud Network Controller は、AWS Marketplace や Azure Marketplace などのパブリッククラウド マーケットプレイスを通じて展開されます。
· Cisco Cloud ルータ(CCR)：Cisco Cloud ルータは、パブリッククラウドプラットフォームの重要なコンポーネントです。CCR は、オンプレミスサイトおよびパブリッククラウドプラットフォームへのサイト間通信に使用されます。さらに、CCR は Microsoft Azure 内の VNet 間通信にも使用されます。このドキュメントでは CCR という用語を使用していますが、Cisco Cloud APIC のリリース 25.0(3) より前は、Cisco Services Router 1000V（CSR1000V または CSR）が CCR として使用され、Cisco Cloud APIC のリリース 25.0(3) からは、Cisco Catalyst 8000V（C8000V）が、新しい展開でデフォルトの CCR として使用されていることに注意してください。C8000V は、より優れたパフォーマンスを提供する新しいクラウド仮想ルータプラットフォームです。CSR を使用するリリース 25.0(3) より前の既存の展開の場合、Cloud APIC がリリース 25.0(3) 以降にアップグレードされた場合は、古い CSR1000V から新しい C8000V に移行する必要があります。移行中、CSR は一度に 1 つずつ停止するため、キャパシティは減少しますが、トラフィックの中断は最小限に抑えられます。リリース 25.0(3) 以降、Cloud APIC ユーザーインターフェイスでは、C8000V を CCR（Cisco Cloudルータ）呼んでいます。
· オンプレミス ACI ファブリック（オプション）：オンプレミス ACI ファブリックは Cisco APIC によって管理されます。Cisco Cloud Network Controller では、オンプレミス ACI ファブリックの存在は必須ではありませんが、オンプレミスのデータセンターとパブリッククラウドプラットフォームの両方があるのが一般的です。
このセクションでは、Cisco ACI、AWS、および Microsoft Azure のネットワークとセキュリティモデルについて簡単に説明します。これは、クラウドプロバイダーごとに構造と用語がわずかに異なるためです。たとえば、オンプレミスの ACI ファブリックの VRF は、AWS の VPC および Microsoft Azure の VNet として解釈できますが、同一ではありません（VPC や VNet は複数のルーティングテーブルを持つことができますが、VRF で持つことができるルーティングテーブルは 1 つです）。さらに、オンプレミスの ACI ファブリックの VRF は、AWS の複数の VPC（リージョン 1 の VPC1 およびリージョン 2 の VPC2）、および Microsoft Azure の複数の VNet（リージョン 1 の VNet1 およびリージョン 2 の VNet2）として解釈できます。
その他の例を次に示します。
· Cisco ACI ネットワークポリシーモデルは、テナント、ブリッジドメイン（BD）、ブリッジドメインサブネット、エンドポイントグループ（EPG）、およびコントラクトを使用します。
· AWS は、ユーザーアカウント、Virtual Private Cloud（VPC）、セキュリティグループ、セキュリティ グループ ルール、およびネットワーク アクセス リストを使用します。
· Microsoft Azure は、リソースグループ、仮想ネットワーク（VNet）、アプリケーション セキュリティ グループ（ASG）、ネットワーク セキュリティ グループ（NSG）、アウトバウンドルール、およびインバウンドルールを使用します。
次の図は、Cisco ACI、AWS、および Microsoft Azure のネットワークおよびセキュリティモデルを示しています。
運用とセキュリティを容易にする一貫したポリシーモデルを実現するには、オンプレミスの ACI サイトとパブリッククラウドプラットフォームの異なるオブジェクト間で、同じパースペクティブを維持するためのマッピングモデルが必要です。たとえば、管理者はポリシー規則を定義して、Web サーバーが特定のポートでデータベースサーバーと通信するようにできます。ポリシー規則は、場所に関係なくすべてのエンドポイントに適用されます。
Nexus Dashboard Orchestrator がモデルを作成し、オブジェクトとポリシーが、オンプレミスの ACI サイトの APIC コントローラと AWS または Azure の Cisco Cloud Network Controller によって、物理ファブリックとクラウド インフラストラクチャ上の具体的なオブジェクトにレンダリングされます。
図 6 と 7 は、Cisco ACI ポリシーモデルのオブジェクトと、AWS や Microsoft Azure で利用可能なクラウド ネイティブ コンストラクト間のマッピングを示しています。次に例を示します。
· ACI のコントラクトは、AWS のセキュリティグループ（SG）ルールや Microsoft Azure のネットワーク セキュリティ グループ（NSG）ルールにマップされます。
· コントラクトルールは、AWS の SG ルールや Microsoft Azure の NSG ルールにマッピングされます。
セキュリティルールが適用される場所は、クラウド環境によって異なります。AWS の場合、SG ルールは AWS インスタンス（クラウドエンドポイント）のネットワークインターフェイスに直接適用されます。Microsoft Azure の場合、リリース 5.1(2) から、NSG ルールは、仮想マシンが存在する Azure 上のサブネットに適用されます。仮想マシンは、NSG の送信元または接続先を参照するアプリケーション セキュリティ グループ（ASG）にグループ化されます。これらのマッピングはすべて、Cloud Network Controller ソリューションの重要なコンポーネントの 1 つである Multi-Cloud Networking によって、動的にレンダリングされます。
詳細については、次のホワイトペーパーを参照してください。
マルチリージョン ハイブリッド クラウドプラットフォームの設計
このセクションでは、マルチリージョン ハイブリッド クラウドプラットフォーム トポロジのトラフィックフローについて説明します。
次の図は、このセクションで使用するトポロジの例を示したものです。次のネットワークで構成されています。
· オンプレミスの Cisco ACI ファブリック：
o ブリッジドメインサブネット（172.16.2.0/24 はブリッジドメインサブネットです）
o 外部ネットワーク（172.16.0.0/24 は、オンプレミスの L3Out 経由で到達可能な外部の接続先です）
· クラウド サイト：
o Microsoft Azure：リージョン 1 および 2（10.111.0.0/16、10.112.0.0/16、10.113.0.0/16 および 10.114.0.0/16 は VNet CIDR です）
o AWS: リージョン 1 およびリージョン 2（10.121.0.0/16、10.122.0.0/16、10.123.0.0/16 および 10.124.0.0/16 は VPC CIDR です）
· ブランチネットワーク：
o branch-1（192.168.81.0/24 は第 1 ブランチネットワークです）
o branch-2（192.168.82.0/24 は第 2 ブランチネットワークです）
NDO と Cisco Cloud Network Controller は、異なるリージョンにあるクラウドプラットフォーム間でさまざまなネットワーク関連構成を調整して、マルチリージョンのハイブリッドクラウド環境でのトラフィックフローを実現します。ネットワーク関連の構成には次のようなものがあります。
· AWS：VPC、CIDR、サブネット、ルートテーブル、TGW、TGW ピアリング、セキュリティグループ、セキュリティグループルール、Application Load Balancer。
· Microsoft Azure：VNet、CIDR、サブネット、ルートテーブル、VNet ピアリング、ネットワーク セキュリティ グループ、アプリケーション セキュリティ グループ、Azure アプリケーション ゲートウェイ、ネットワークロードバランサ。
· Cisco Cloud ルータのライフサイクル管理と構成。
次の図は、NDO および Cisco Cloud Network Controller によって自動化される内容を示しています。
Cisco Multi-Cloud Networking solution を導入する主な利点の 1 つは、ネットワーク接続のオーケストレーションと、複数のクラウド環境での運用の簡素化です。
次の表は、このセクションで説明するトラフィックフローをまとめたものです。次のサブセクションで、各シナリオについて詳しく説明します。
表 1 トラフィックフローパターン
| トラフィックパターン |
Traffic flow |
| （プライベートサブネットからプライベートサブネットへ） |
トラフィックは、AWS TGW や Microsoft Azure VNet ピアリングなどクラウドネイティブのルーティング機能を介して転送されます。 |
| （プライベートサブネットからプライベートサブネットへ） |
トラフィックは、クラウドプラットフォーム内の Cisco Cloud ルータ間の VXLAN トンネルを介して転送されます。 |
| オンプレミスの ACI ファブリックとパブリッククラウドプラットフォーム間のトラフィックフロー （プライベートサブネットからプライベートサブネットへ） |
トラフィックは、クラウドプラットフォーム内の Cisco Cloud ルータと Cisco ACI スパインスイッチ間の VXLAN トンネルを介して転送されます。 |
| インターネットとクラウドプラットフォーム間のトラフィックフロー （パブリックサブネットからプライベートサブネットへ） |
トラフィックは、AWS IGW（インターネットゲートウェイ）や Microsoft Azure のデフォルトシステムルートなどのクラウド ネイティブ ルーティング機能を介して転送されます。 |
| 外部ネットワークとクラウドプラットフォーム間のトラフィックフロー （プライベートサブネットからプライベートサブネットへ） |
トラフィックは、クラウドプラットフォームの Cisco Cloud ルータとブランチルータの間の IPsec トンネルを介して転送されます。 |
パブリッククラウドプラットフォーム内のリージョン内およびリージョン間トラフィックフロー
次の図は、同じパブリッククラウド プロバイダーの 2 つのリージョン間で確立されたトラフィックフローを示しています。
AWS を使用した Cisco Multi-Cloud Networking の場合、同じリージョン内の VPC 間トラフィックは、ローカルのトランジットゲートウェイ（TGW）を介して転送されます。リージョン間トラフィックは、複数のリージョンの TGW 間ピアリングを利用し、クラウドプロバイダーのプライベートバックボーンを介して転送されます。
Cisco Cloud Network Controller は、TGW の作成、各 VPC の TGW アタッチメント構成、TGW のリージョン間ピアリング、VPC ルートテーブルの作成、各 VPC の VPC ルートテーブル構成を処理します。
Microsoft Azure を使用した Cisco Multi-Cloud Networking の場合、VNet 間トラフィックは VNet ピアリングを介してインフラ VNet 内の Azure Load Balancer に転送され、トラフィックはインフラ VNet 内の Cisco Cloud ルータの 1 つに負荷分散されます。次に、Cisco Cloud ルータは VNet ピアリングを介してトラフィックを接続先 VNet に転送します。リターントラフィックは、ロードバランシングに基づいて別の Cisco Cloud ルータに送信される可能性があります。
Cisco Cloud Network Controller は、VNet ピアリング、Azure Load Balancer、Cisco Cloud Router、および各 VNet のルート テーブルの構成を処理します。
ローカル VNet 外部のプライベートサブネット宛てのトラフィックは、同じリージョン内のローカル Azure Load Balancer に転送されるため、リージョン間トラフィックは、着信トラフィックとリターントラフィックで異なる Azure Load Balancer に転送されます。トラフィックは、Cisco Cloud ルータに負荷分散された後、グローバル VNet ピアリングを介して接続先 VNet に転送されます。
同じリージョンにローカルの Azure Load Balancer がない場合、トラフィックはグローバル VNet ピアリングを介して接続先リージョンの Azure Load Balancer に転送されます。
さまざまなリージョンで複数の Azure Load Balancer を使用できる場合、Cisco Cloud Network Controller は、VNet のルートテーブルを更新することで、ネクストホップとして使用する Azure Load Balancer を決定します。この判断は、Cisco Cloud ルータの構成や可用性など、複数の要因に基づいています。次の図の例では、双方向に同じ Azure Load Balancer を使用していますが、トラフィックは、着信トラフィックとリターントラフィックで異なる Azure Load Balancer に転送される可能性があります。
テナントの設計とガイドラインについては、次のセクションを参照してください。
· ユースケース #1：複数のサイトにまたがるアプリケーション（テナント内）
· ユースケース #2：複数のサイトにまたがるアプリケーション（テナント間共有サービス）
次の図は、異なるパブリッククラウドプラットフォームのプライベートサブネット間のトラフィックフローを示しています。
パブリッククラウド外部のプライベートサブネット宛てのトラフィックは、ローカルの TGW またはローカルの Azure Load Balancer に転送されます。その後、トラフィックは同じクラウド内の Cisco Cloud ルータに転送され、Cisco Cloud ルータのルーティングテーブルに基づいて、VXLAN トンネルの反対側の Cisco Cloud ルータに送信されます。
· 接続先 IP サブネットがオンプレミスの ACI ファブリックにある場合、Cisco Cloud ルータはオンプレミスの ACI のルータにトラフィックを送信します。「オンプレミスの ACI ファブリックとパブリッククラウドプラットフォーム間のトラフィックフロー」を参照してください。
· 接続先 IP サブネットがブランチネットワークなど別の外部ネットワークにある場合、Cisco Cloud ルータはトラフィックを接続先ロケーションのルータに送信します。「外部ネットワークとクラウドプラットフォーム間のトラフィックフロー」を参照してください。
次の図の例では、双方向に同じ Cisco Cloud ルータを使用していますが、トラフィックは、着信トラフィックとリターントラフィックで異なる Cisco Cloud ルータを通過する可能性があります。次の図に示すように、別のクラウドから Microsoft Azure へのトラフィックは、Azure Load Balancer を通過しません。
Cisco Cloud Network Controller は、ルートテーブル、TGW、VNet ピアリング、Azure Load Balancer などのパブリッククラウド ネットワーク構成に加えて、VXLAN トンネルを含む Cisco Cloud ルータの構成も処理します。
同じリージョンに Cisco Cloud ルータがない場合、トラフィックは Cisco Cloud ルータが存在するリージョンに転送され、Cisco Cloud ルータ間の VXLAN を介して接続先パブリッククラウドに転送されます。
テナントの設計とガイドラインについては、次のセクションを参照してください。
· ユースケース #1：複数のサイトにまたがるアプリケーション（テナント内）
· ユースケース #2：複数のサイトにまたがるアプリケーション（テナント間共有サービス）
オンプレミスの ACI ファブリックとパブリッククラウドプラットフォーム間のトラフィックフロー
次の図は、オンプレミスの ACI ファブリックとパブリッククラウドプラットフォーム間のトラフィックフローを示しています。
送信元 VPC または VNet 外部のプライベートサブネット宛てのトラフィックは、ローカルの TGW またはローカルの Azure Load Balancer に転送されます。その後、トラフィックは同じクラウド内の Cisco Cloud ルータに転送され、Cisco Cloud ルータのルーティングテーブルに基づいて、VXLAN トンネルの向こうのオンプレミスの ACI ファブリックのルータに送信されます。
· 接続先 IP サブネットが別のパブリッククラウドにある場合、Cisco Cloud ルータはトラフィックを接続先パブリッククラウドの Cisco Cloud ルータに送信します。「パブリッククラウドプラットフォーム間のトラフィックフロー」を参照してください。
· 接続先 IP サブネットがブランチネットワークなど別の外部ネットワークにある場合、Cisco Cloud ルータはトラフィックを接続先ロケーションのルータに送信します。「外部ネットワークとクラウドプラットフォーム間のトラフィックフロー」を参照してください。
トラフィックがオンプレミスの ACI ファブリックに着信すると、接続先 IP サブネットに応じて、オンプレミスの ACI ファブリックまたは外部ネットワークの接続先エンドポイントに L3Out 経由で転送されます。NDO とオンプレミス APIC は、オンプレミス ACI ファブリックでのネットワーク展開を処理します。
次の図の例では、双方向に同じ Cisco Cloud ルータを使用していますが、トラフィックは、着信トラフィックとリターントラフィックで異なる Cisco Cloud ルータを通過する可能性があります。次の図に示すように、オンプレミスの ACI ファブリックから Microsoft Azure へのトラフィックは、Azure Load Balancer を経由しません。
Cisco Cloud Network Controller は、ルートテーブル、TGW、VNet ピアリング、Azure Load Balancer などのパブリッククラウド ネットワーク構成に加えて、VXLAN トンネルを含む Cisco Cloud ルータの構成も処理します。NDO は、オンプレミスの ACI ファブリックのルータの構成テンプレートを生成します。構成テンプレートは Cisco IOS-XE CLI シンタックスに基づいているため、クラウド管理者がルータに合わせて編集する必要がある場合があります。
同じリージョンに Cisco Cloud ルータがない場合、トラフィックは Cisco Cloud ルータが存在するリージョンに転送され、オンプレミスの ACI ファブリックの Cisco Cloud ルータとスパインスイッチ間の VXLAN を介して接続先に転送されます。次の図では、リージョン 3 のエンドポイントとオンプレミスの ACI ファブリック間のトラフィックは、両方向にリージョン 2 の Cisco Cloud ルータを使用していますが、トラフィックは着信トラフィックとリターントラフィックで異なるリージョンの異なる Cisco Cloud ルータを通過する可能性があります。
テナントの設計とガイドラインについては、次のセクションを参照してください。
· ユースケース #1：複数のサイトにまたがるアプリケーション（テナント内）
· ユースケース #2：ハイブリッドマルチクラウド環境での共有サービス
· ユースケース #3：オンプレミスの L3 外部（L3Outs）を介したクラウドから外部ネットワークへの接続
インターネットとクラウドプラットフォーム間のトラフィックフロー
次の図は、インターネットとクラウドプラットフォーム間のトラフィックフローを示しています。
緑の矢印で示されているように、インターネット宛のトラフィックは、AWS Internet Gateway（IGW）や Microsoft Azure のデフォルトシステムルートなどのクラウド ネイティブ ルーティング機能を介して転送されますが、TGW、VNet ピアリング、Cisco Cloud ルータは経由しません。 Cisco Network Controller は、次のホップとしてインターネットゲートウェイを指定するデフォルトルートを、AWS ルートテーブルに追加します。
もう 1 つの例は、オンプレミスの ACI ファブリックでの L3Out の使用です。この場合、オンプレミスの ACI ファブリックとパブリッククラウドプラットフォーム間のトラフィックフローのシナリオと同様に、インターネット宛のトラフィックはオンプレミスの ACI ファブリックに転送され、L3Out を介して外部ネットワークに転送されます。 NDO、Cisco Cloud Network Controller、およびオンプレミス APIC は、オンプレミスの ACI ファブリックおよびパブリッククラウドプラットフォーム全体のネットワーク展開を処理します。
次の図の例では、双方向に同じ Cisco Cloud ルータを使用していますが、トラフィックは着信トラフィックとリターントラフィックで異なる Cisco Cloud ルータを通過する可能性があります。オンプレミスの ACI ファブリックから Microsoft Azure へのトラフィックは、Azure Load Balancer を経由しません。
テナントの設計とガイドラインについては、次のセクションを参照してください。
· ユースケース #3-1：クラウド ネイティブ ルーティング機能を使用したクラウドからインターネットへの接続
· ユースケース #3-2：オンプレミスの L3 外部（L3Outs）を介したクラウドから外部ネットワークへの接続
外部ネットワークとクラウドプラットフォーム間のトラフィックフロー
次の図は、外部ネットワークとクラウドプラットフォーム間のトラフィックフローを示しています。この例では、ブランチネットワークが外部ネットワークの代表として使用されています。
この場合、オンプレミスの ACI ファブリックとパブリッククラウドプラットフォーム間のトラフィックフローのシナリオと同様に、送信元 VPC/VNet の外部にあるプライベートサブネット宛のトラフィックは、ローカルの TGW またはローカルの Azure Load Balancer に転送されます。その後、トラフィックは同じクラウド内の Cisco Cloud ルータに転送され、Cisco Cloud ルータのルーティングテーブルに基づいて、IPsec トンネルの向こうの接続先ロケーション（この例ではブランチネットワーク）のルータに送信されます。
· 接続先 IP サブネットが別のパブリッククラウドにある場合、Cisco Cloud ルータはトラフィックを他のパブリッククラウドの Cisco Cloud ルータに送信します。「パブリッククラウドプラットフォーム間のトラフィックフロー」を参照してください。
· 接続先 IP サブネットがオンプレミスの ACI ファブリックにある場合、Cisco Cloud ルータはオンプレミスの ACI のルータにトラフィックを送信します。「オンプレミスの ACI ファブリックとパブリッククラウドプラットフォーム間のトラフィックフロー」を参照してください。
次の図の例では、双方向に同じ Cisco Cloud ルータを使用していますが、トラフィックは、着信トラフィックとリターントラフィックで異なる Cisco Cloud ルータを通過する可能性があります。Microsoft Azure の場合、次の図に示すように、外部ネットワークから Microsoft Azure へのトラフィックは Azure Load Balancer を通過しません。
テナントの設計とガイドラインについては、次のセクションを参照してください。
· ユースケース #4：クラウド ネイティブ ルーティング サービスを使用した外部サイトへの接続
· ユースケース #5：WAN、ブランチ、または非 ACI サイトへの外部接続
· ユースケース #6：SD-WAN ソリューションとの相互運用
このサブセクションでは、オンプレミス ACI サイトとクラウドサイト間のサイト間接続について説明します。
オンプレミスの ACI サイトとクラウドサイトは、Cisco Cloud ルータとオンプレミスルータ間のアンダーレイネットワークの到達可能性のためのダイナミック ルーティング プロトコルとして OSPF を使用し、IPsec トンネルを介して接続されます。IPsec トンネルと OSPF はオプションです。
· NDO でのサイト接続の一部として IPsec が有効になっていない場合、NDO は OSPF を構成する代わりに、Cisco Cloud ルータで静的ルートを構成します。
· IPsec が有効になっている場合、NDO はインフラ VPC/VNet の Cisco Cloud ルータで IPsec と OSPF を構成します。
NDO は、オンプレミスルータの構成テンプレートも生成します。構成テンプレートは Cisco IOS-XE CLI シンタックスに基づいているため、クラウド管理者がルータに合わせて編集する必要がある場合があります。
アンダーレイ IP ネットワークは、インターネットを介して、AWS の場合は AWS Direct Connect で構成されるプライベートパスを介して、Microsoft Azure の場合は Azure ExpressRoute（ER）を介して通過できます。このアンダーレイネットワークは、2 つのサイト間のオーバーレイ コントロールプレーンとデータプレーンの IP 到達可能性を提供します。AWS Direct Connect または Azure ExpressRoute の場合、プライベート接続であるため、IPsec は必要ない場合があります。
次の図は、AWS Direct Connect および Azure ExpressRoute を使用した例を示しています。オンプレミスの Cisco ACI スパインスイッチは、サイト間ネットワークに接続します。オンプレミスルータは、AWS Direct Connect Gateway（DX GW）および Microsoft Enterprise Edge（MSEE）ルータとの eBGP ピアリングを確立します。オンプレミスルータとクラウドプラットフォームの Cisco Cloud ルータの間に、IPsec トンネルと OSPF ネイバーシップが確立されます。MP-BGP EVPN セッションが、オンプレミスの ACI ファブリック内の ACI スパインスイッチと、Cisco Cloud ルータの間で、IPsec トンネルを介して確立されます。
オンプレミスの ACI サイトとクラウドサイト間のオーバーレイネットワークは、コントロールプレーンとして BGP EVPN を実行し、データプレーンとして VXLAN カプセル化とトンネリングを使用します。VXLAN は、オンプレミスの Cisco ACI ファブリックとクラウドプラットフォーム全体に VRF をストレッチするときに、適切なルーティングドメインを識別するために使用されます。テナントホストルートとプレフィックスルートは、2 つのサイト間で BGP EVPN ルートタイプ 2（ホスト）およびタイプ 5（プレフィックス）として交換されます。このオーバーレイネットワーク接続のプロビジョニングは、NDO によって自動化されます。
IPsec トンネルと VXLAN カプセル化のオーバーヘッドによるフラグメンテーションを回避するために、BGP EVPN コントロールプレーンの ACI コントロールプレーン MTU ポリシーとデータプレーンのエンドポイントで、最大伝送ユニット（MTU）サイズを調整する必要がある場合があります。調整を行わないと、ネットワーク内のデバイスによるフラグメンテーションが全体のパフォーマンスを低下させる可能性があります。たとえば、関連するエンドポイントの MTU が 1,300 バイトに調整されている場合、これは、MTU の一般的な値が 1,500 バイトであるインターネットを通過するために、VXLAN からの追加の 50 バイトと、 IPsec オーバーヘッドの約 100 バイトを考慮しています。エンドポイントの MTU サイズの調整が許可されていないか、望ましくない場合は、Cisco Cloud Network Controller から、Cisco Cloud ルータの TCP 最大セグメントサイズ（MSS）を調整します。
Cisco Cloud Network Controller から Cisco Cloud ルータの TCP MSS 値を変更する構成手順については、https://www.cisco.com/c/en/us/td/docs/dcn/aci/cloud-apic/25x/installation/azure/cisco-cloud-apic-for-azure-installation-guide-250x/configuring-using-setup-wizard-250x.html を参照してください。
Cisco Multi-Cloud Networking Design オプション
このセクションでは、一般的な Cisco Multi-Cloud Networking 設計のユースケースと設計上の考慮事項について説明します。
表 2 は、このセクションで説明する設計オプションの比較をまとめたものです。次のサブセクションでは、各設計オプションとその考慮事項について説明します。
表 2 一般的な設計オプション
| 使用例 |
検討 |
|
|
アプリケーションは、エンドポイントのグループとして導入できます。サブネットは、クラウドサイトとオンプレミスサイトで異なる必要があります。 |
| テナントはサイト（オンプレミスとクラウド）にまたがる必要があります。 VRF 間でサブネットをオーバーラップさせないでください。 |
|
| オンプレミスの L3 外部（L3Outs）を介したクラウドから外部ネットワークへの接続 （共有オンプレミス L3 外部（L3Outs）） |
L3Out は、オンプレミス ACI の専用テンプレートで定義する必要があります。オンプレミスの L3Out は、共通のテナントに配置することはできません。 |
| Azure は Azure VPN ゲートウェイまたは Express Route ゲートウェイを使用します。 AWS は Transit Gateway を使用します。 外部サイトでブランチデバイスを手動で構成するのは、エンドユーザーの責任です。 |
|
| 外部デバイスで BGP と IPsec を有効にする必要があります。外部デバイスの BGP ASN は、クラウドプラットフォームの Cisco Cloud ルータの BGP ASN とは異なる必要があります。 |
|
| SD-WAN 側での自動化構成はありません。SD-WAN 管理者は、 Cisco Multi-Cloud Networking ソリューションに合わせてルーティングとポリシーを適宜手動で構成する必要があります。 |
|
| Cisco Cloud Network Controller リリース 25.1(1) の時点で、サードパーティのロードバランサ統合は Azure でのみ使用できます。 |
|
| Cisco Cloud Network Controller リリース 25.1(1) の時点で、サードパーティのファイアウォール挿入は Azure でのみ使用できます。 |
|
| Cisco Cloud Network Controller リリース 25.1(1) の時点で、マルチノードサービスの挿入は Azure でのみ使用できます。 |
|
| Cisco Cloud Network Controller リリース 25.1(1) の時点で、クラウドネイティブサービスの統合は Azure でのみ使用できます。 |
|
| Cisco Cloud Network Controller は、VPC/VNet などのネットワーク オブジェクトのみをインポートします。クラウド管理者は、SG/NSG やルートテーブルの作成や更新など、特定の手動構成手順を実行する必要があります。 |
|
| スイッチオーバー時のルーティングとセキュリティ構成を自動化するには、「ルーティングとセキュリティ」を備えたブラウンフィールド インポート機能が必要です。 |
|
| 「ルーティングのみ」のブラウンフィールド インポート機能が必要です。 |
重要な注意事項：NDO によって駆動されるサイト間通信の場合、NDO リリース 4.0(3) 以降、オンプレミスの ACI サイトが通信の一部である場合は、各サイトで「コントラクト ベースのルーティング」オプションを有効にする必要があります。これは、ルーティングとセキュリティ ポリシーを分離するための「コントラクト ベースのルーティング」の無効化は、クラウド サイト間、またはクラウド サイトと Cisco Nexus Dashboard ファブリック コントローラー (NDFC)によって管理されるオンプレミスのスタンドアロン NX-OS ベースのファブリックとの間のサイト間通信に対してのみサポートされるためです。NDO または Cisco Cloud Network Controller では、デフォルトでは「コントラクト ベースのルーティング」が有効になっていないことに注意してください。各サイトの構成ノブは、NDO の [サイト接続] の下の [サイト間接続] にあります。
このドキュメントは、AWS と Microsoft Azure の両方の Cisco Cloud APIC で「コントラクト ベースのルーティング」が有効になっているという前提に基づいて作成されています。「コントラクトベースのルーティング」オプションは、次の手順で見つけることができます。
1. [インテント（Intent）] ボタンをクリックします。
2. 「Cloud Network Controller の設定」をクリック
3. 「詳細設定」で「構成の編集」をクリックし、コントラクト ベースのルーティングをオンにします。
ユースケース #1：複数のサイトにまたがるアプリケーション（テナント内）
このユースケースは、アプリケーションがオンプレミスのファブリックとパブリッククラウドプラットフォームにまたがる、最も一般的なユースケースの 1 つです。このユースケースの主な利点は、ワークロードの柔軟性と一元化されたポリシー制御です。Web 層などのアプリケーション層を、オンプレミスのファブリックとパブリッククラウドプラットフォーム全体に展開して、より優れたレジリエンスを提供できます。一方、Web 層とデータベース層など他の層との間のセキュリティポリシーは、ワークロードの場所に関係なく一貫して維持されます。
次の図は、このユースケースの例を示しています。この例では、サンプルアプリケーション「Ecom」はデータベース層と Web 層で構成されています。
· データベース層は、オンプレミスの ACI ファブリックでプロビジョニングされた EPG 「データベース」によって表されています。
· Web 層は、AWS と Microsoft Azure の両方に存在する EPG 「Web」によって表されています。
このユースケースでは、VRF が 3 つの環境（オンプレミスの ACI、AWS、および Microsoft Azure）にまたがって、それらの間のレイヤー 3 接続を有効にしています。次の例では、VRF は AWS の VPC と Microsoft Azure の VNet にマッピングされていますが、技術的には ACI の 1 つの VRF を複数の VPC/VNet にマッピングできます。たとえば、次の図に示すように、VPC が異なるリージョンにある場合、ACI で 1 つの VRF を作成し、その VRF を AWS の 2 つの VPC にマッピングできます。
エンドポイントが異なる環境にある場合でも、EPG 内の通信にはコントラクトは必要ありません。たとえば、EPG「Web」の AWS インスタンスは、コントラクトなしで EPG「Web」の Azure VM と通信できます。EPG がストレッチされている場合、通信に必要なルーティングとセキュリティポリシーの構成は、NDO を介して各環境に自動的に展開されます。
AWS と Microsoft Azure では、内部ルーティングと外部ルーティングの導入方法が異なりますが、Cisco Multi-Cloud Networking ソリューションは、さまざまな環境に一貫したネットワークとセキュリティ ポリシー モデルを提供し、ハイブリッド マルチクラウド環境での運用を簡素化することで、この複雑さを標準化します。管理者は VRF、EPG、および NDO 上の EPG 間のコントラクトを作成します。これらは、Cisco APIC および Cloud Network Controller との対話を通じて、これらの環境全体で展開を処理します。
考慮事項：このユースケースでは、アプリケーション層（Web EPG など）がパブリッククラウドプラットフォーム全体に広がっています。これを実現するには、AWS と Azure 両方のクラウドサイトに関連付けられているテンプレート（たとえば、「ストレッチテンプレート」）で、Web EPG 構成をプロビジョニングする必要があります。NDO では、テンプレートは構成プロビジョニングの最小単位を表します（構成の変更は一度に 1 つのテンプレートを展開できます）。したがって、ストレッチテンプレートを変更すると、ストレッチテンプレートが適用されるすべてのサイトに同時に変更がプッシュされます。結果として、このタイプのストレッチテンプレートでは、両方のパブリッククラウドサイトでサポートされている機能のみを使用できます。たとえば、クラウド サービス EPG は、現時点では Microsoft Azure を使用するクラウド サイトでのみサポートされている機能であるため、ストレッチテンプレートでは構成できません。
ユースケース #2：ハイブリッドマルチクラウド環境での共有サービス
このセクションでは、共有サービスと呼ばれる、共通のプロバイダーリソースが異なるコンシューマーで共有されるユースケースについて説明します。共有サービスの例には、ユーザーとアプリケーションで共有される共通データベース、DNS、AD サービスなどがあります。
ネットワーク設計の観点から言えば、共有サービスは、以下の特定の条件下では VRF 間接続を介して導入できます。
· VRF 間でリークできるのは、重複しない IP アドレスだけです。
· 複数のコンシューマ VRF からプロバイダー VRF にリークされるサブネットは一意にする必要があり、重複できません。
コントラクト設計の観点から言えば、VRF 間およびテナント間コントラクトには、次のガイドラインがあります。
· VRF 間テナント内コントラクトの場合、コントラクト範囲を「テナント」に設定する必要があります。
· テナント間コントラクトの場合、コントラクト範囲を「グローバル」に設定する必要があります。
· コンシューマーとプロバイダーの VRF は、サイト全体にストレッチする必要はありません（サイトローカルにできます）。
· サイト間のテナント間コントラクトの場合、NDO がクラウド環境を管理するための適切な資格情報を持つように、両方のサイトを NDO 「テナント」構成の両方のテナントに関連付ける必要がありますが、テナントを 「スキーマ」構成を介して両方のサイトに展開する必要はありません。次に例を示します。
o オンプレミス ACI サイトの VRF1 の EPG1 の tenant1。
o クラウドサイトの VRF2 の EPG2 の tenant2。
o オンプレミスの ACI サイトとクラウドサイトの両方が、NDO「テナント」構成の tenant1 と tenant2 に関連付けられています。
o tenant1 のスキーマ template1 はオンプレミスの ACI サイトにのみ展開され、tenant2 の template2 はクラウドサイトにのみ展開されます。
上記の考慮事項があるため、Cisco Multi-Cloud Networking ソリューションのサイト間でサブネットリークとルート伝達がどのように機能するか、およびサポートされているコントラクト構成を理解することが重要です。次のサブセクションでは、VRF 内ルート伝達、VRF 間ルートリーク、および VRF 間コントラクトとテナント間コントラクトの構成例について説明します。
このサブセクションでは、サイト間の VRF 内ルート伝達について説明します。
次の図は、VRF が AWS、Microsoft Azure、オンプレミスの ACI サイトを含む複数のサイトにまたがっている場合の VRF 内ルート伝達の例を示しています。この例では、vrf1 もオンプレミスの ACI サイトに展開されていますが、オンプレミスの ACI サイトにはまだブリッジドメインが展開されていません。その結果、AWS と Microsoft Azure の両方の Cisco Cloud ルータには、vrf1 ルーティングテーブルに 2 つのルートがあります（この例では、10.111.0.0/16 と 10.121.0.0/16）。
次に、BD サブネットが 172.16.2.1/24 であるブリッジドメイン（bd1）があり、そのブリッジドメインがオンプレミスの ACI サイトに展開されているとします。bd1 の EPG がオンプレミスの ACI サイトとクラウドサイトにまたがっている場合、または bd1 の EPG がクラウドサイトの別の EPG とコントラクトしている場合、172.16.2.0/24 サブネットは Cisco Cloud ルータにアドバタイズされます。
次の図は、ストレッチ EPG の存在により、オンプレミスの ACI サイトからクラウドサイトへのルートが伝達される第 1 の例です。
次の図は、ストレッチされていないオンプレミス EPG（EPG「Database」）と別のストレッチされていないクラウド EPG（EPG 「Web」）間のコントラクトを使用する第 2 の例です。
このサブセクションでは、VRF 間ルートリークの動作、および VRF 間コントラクトとテナント間コントラクトの構成例について説明します。
次の図は、VRF がサイト全体にストレッチされるシナリオ 2a を示しています。テナント間コントラクトの場合、両方のテナントがサイト全体にストレッチされます（両方のテナントがすべてのサイトに展開されます）。この例では、EPG「Web」および「Web2」はクラウドサイトのみに展開され、EPG「Database」および「Database2」はオンプレミスの ACI サイトのみに展開されます。このシナリオでは、これらの間のコントラクトにより、次の通信が許可されます。
· EPG Web のエンドポイントと EPG Database のエンドポイント
· EPG Web2 のエンドポイントと EPG Database2 のエンドポイント
· EPG Web のエンドポイントと EPG Web2 のエンドポイント
他の EPG 間通信は、ルートが存在する場合でも許可されません。たとえば、EPG Web のエンドポイントと EPG Database2 のエンドポイントは相互に通信できません。
Cisco Multi-Cloud Networking ソリューションでの VRF 間ルートリークの動作は、特定のサブネットを他の VRF にのみリークするオンプレミス ACI ファブリック内の VRF 間ルート リークとは少し異なることに注意してください。Cisco Multi-Cloud Networking ソリューションの場合、VRF 間コントラクトがある場合、すべての CIDR とルートが他の VRF にリークされます。たとえば、vrf1 と vrf2 の間の VRF 間コントラクトが EPG Web と Web2 の間だけである場合でも、vrf1 と vrf2 には、他の VRF からリークされた次のルートがあります。
· vrf1：10.122.0.0/16（AWS での vrf2 CIDR）、10.112.0.0/16（Azure での vrf2 CIDR）、および 172.16.22.0/24（bd2）
· vrf2：10.121.0.0/16（AWS での vrf1 CIDR）、10.111.0.0/16（Azure での vrf2 CIDR）、および 172.16.2.0/24（bd1）
次の図は、シナリオ 2a と比較してコントラクト数が多いシナリオ 2b を示しています。この場合、サイト間のすべての EPG 間通信が許可されます（たとえば、EPG Web のエンドポイントと EPG Database2 のエンドポイントは相互に通信できます）。
次の図は、コンシューマーまたはプロバイダーの VRF がオンプレミスの ACI サイトとクラウドサイトにストレッチされていないシナリオ 2c を示しています。コンシューマー VRF 「vrf1」は AWS と Microsoft Azure にのみ展開され、プロバイダー VRF 「vrf2」はオンプレミスの ACI サイトにのみ展開されます。テナント間コントラクトの場合、テナントをすべてのサイトに展開する必要はありませんが、オンプレミスの ACI サイトとクラウドサイトの両方を NDO「Tenants」構成の両方のテナントに関連付ける必要があります。 
次の図は、3 つの VRF がサイトローカルであるシナリオ 2d を示しています。シナリオ 2c の考慮事項と同様に、テナント間コントラクトの場合、テナントをすべてのサイトに展開する必要はありませんが、すべてのサイトを NDO「Tenants」構成のすべてのテナントに関連付ける必要があります。
次の図は、シナリオ 2e を示しています。このシナリオは、オンプレミスの ACI ファブリックで外部 EPG として表される外部ネットワークに共有サービスが存在する一般的な共有サービスのユースケースの 1 つです。レイヤ 3 アウト（L3Out）は、VRF の 1 つ（図 37 の vrf1）または別の VRF（図 38 の vrf3）で構成する必要があります。vrf1 と vrf2 の両方で定義することはできません。
vrf1 と vrf2 の両方に存在できない理由は、ルートが重複する可能性があるためです。シナリオ 2a で説明されているとおり、Cisco Multi-Cloud Networking ソリューションの場合、VRF 間コントラクトがある場合、すべての CIDR とルートが他の VRF にリークされます。以下の図にサポートされない例を示します。vrf1 と vrf2 の間の VRF 間コントラクトが EPG Web と Web2 の間だけである場合でも、vrf1 と vrf2 には、他の VRF からリークされた次のルートがあります。
· vrf1：10.122.0.0/16（AWS での vrf2 CIDR）、10.112.0.0/16（Azure での vrf2 CIDR）、172.16.22.0/24（bd2）、および 192.168.30.0/24
· vrf2：10.121.0.0/16（AWS での vrf1 CIDR）、10.111.0.0/16（Azure での vrf2 CIDR）、172.16.2.0/24（bd1）、および 192.168.30.0/24
問題は、両方の VRF で、192.168.30.0/24 ルートが VRF 内でリークされ、また他の VRF からもリークされるため、サブネットが重複することです。
上級者向けの注意事項：このタイプの重複ルートがある場合、オンプレミスの ACI でトラフィックがドロップされる可能性があります。たとえば、vrf1 のクラウドエンドポイントから外部ネットワーク（192.168.30.0/24）へのトラフィックは、Cisco Cloud ルータの 1 つに転送され、vrf1 ではなく vrf2 経由のルートを使用してオンプレミスの ACI ファブリックにトラフィックを送信する可能性があります。つまり、トラフィックが vrf2 VNID を使用してオンプレミスの ACI ファブリックに到着します。その結果、ACI リーフスイッチは、vrf1 の EPG の許可ルールを持たない vrf2 のゾーン分割ルールを参照します。
外部 EPG とクラウド EPG の構成に関する考慮事項については、ユースケース #3-2 で説明します。
ユースケース #3：クラウドからインターネット/外部ネットワークへの接続
ユースケース #3-1：クラウド ネイティブ ルーティング機能を使用したクラウドからインターネットへの接続
これは、クラウドワークロードがクラウド ネイティブ ルーティング機能（AWS のインターネットゲートウェイや Microsoft Azure のデフォルト システム ルートなど）を使用してインターネットに直接アクセスする一般的なユースケースです。このユースケースの主な利点は、簡素化と拡張性です。構成が簡単であり、パブリッククラウドプラットフォームによって、その VPC（AWS 上）および VNet（Microsoft Azure 上）から直接、大規模なインターネットアクセスが提供されます。
次の図は、EPG「Web」と外部 EPG「Internet-EPG」（0.0.0.0/0 IP セレクタを使用）が、アプリケーションプロファイル「Ecom」のテナントで定義されている例を示しています。クラウドワークロードから開始されるインターネットアクセスを許可するには、コンシューマーとしての EPG「Web」とプロバイダーとしての「Internet EPG」の間にコントラクトを適用する必要があります。
この場合、クラウド サイトのコントラクトがコンシューマーからプロバイダーへのトラフィックのみの許可ルールを作成するため、インターネット上のエンドポイントによって発信され、EPG Web（コンシューマー）のクラウドエンドポイントに向かうトラフィックは許可されません。プロバイダーからコンシューマーへのリターントラフィックは、（明示的な許可ルールがない場合でも）自動的に許可されます。これは、コンシューマーからプロバイダーへのトラフィックが以前に監視されているためです。したがって、インターネット上のエンドポイントが EPG Web 内のクラウドエンドポイントとの通信を開始する可能性がある場合、インターネット-EPG はコントラクトのコンシューマー、EPG Web はコントラクトのプロバイダーである必要があります。
ユースケース #3-2：オンプレミスの L3 外部（L3Outs）を介したクラウドから外部ネットワークへの接続
このユースケースは、オンプレミスの ACI ファブリックを介して外部ネットワークとパブリッククラウド リソース間の接続を提供する必要がある場合に使用されます。外部ネットワークには、WAN、単純なブランチ、またはインターネット接続を使用できます。
このユースケースの利点は、一貫したセキュリティポリシーモデルと安全な接続です。通常のエンドポイントとして接続されているかのようにオンプレミスの ACI サイトへの接続をルーティングしたポリシーを、外部ネットワークに適用できます。オンプレミスのファイアウォールを使用して、クラウドサイトに出入りするトラフィックに特定のセキュリティポリシーを適用できます。
次の図は、アプリケーションプロファイル「Ecom」のテナントに、レイヤ 3 外部「L3Out」と外部 EPG 「Ext-EPG」が定義されている例を示しています。このユースケースの目的は、クラウドサイトでプロビジョニングされた EPG 「Web」と、オンプレミスの L3Out を介してアクセス可能な外部ネットワークリソースとの間の接続を提供することです。したがって、EPG「Ext-EPG」（オンプレミスの L3Out に関連付けられている）とクラウド内の EPG「Web」 の間にコントラクトを適用する必要があります。EPG「Database」と外部 EPG「Ext-EPG」間のコントラクトは任意です。
。 
このユースケースには、次のガイドラインがあります。
· オンプレミスの ACI サイトにマッピングされた専用テンプレートで、関連付けられた外部 EPG とともに L3Out を構成する必要があります。
· オンプレミスの L3Out からクラウド EPG サブネット（この特定の例では Web EPG が存在するサブネット）をアドバタイズするには、Ext-EPG の下でクラウド CIDR プレフィックスを構成し、[ルート制御をエクスポート（Export Route Control）] をオンに設定する必要があります。（図 42）
· オンプレミスの L3Out 接続を介して学習した外部プレフィックスをクラウドサイトにアドバタイズするには、外部 EPG で [共有ルート制御（Shared Route Control）] と [外部 EPG の外部サブネット（External Subnets for External EPG）] を設定する必要があります（図 43）。
ユースケース #4：クラウド ネイティブ ルーティング サービスを使用した外部サイトへの接続
このユースケースの目的は、Azure VPN や ExpressRoute Gateway、AWS Transit Gateway などのクラウド ネイティブ ルーティング サービスを使用して、外部サイトに接続することです。
· Azure の場合、クラウド管理者が Microsoft Azure ポータルから直接 Azure VPN/ExpressRoute Gateway を作成する必要があります。
· AWS の場合、Cisco Cloud Network Controller は、Cisco Cloud Network Controller の初回設定プロセスの一部として Transit Gateway を自動的に作成します。
BGP は、ブランチの外部デバイスからクラウド ネイティブ ルーティング サービスへの動的プロトコルとして使用され、IPsec はアンダーレイトンネルとして使用されます。セキュリティルールは、AWS の SG ルールと Microsoft Azure の NSG ルールを使用して、各クラウドサイトで適用されます。
以下の表は、Cisco Cloud Network Controller の権限下でのクラウドプラットフォームから外部サイトへの外部接続の提供に関する Microsoft Azure と AWS の違いをまとめたものです。
表 3 外部接続に関する Microsoft Azure VPN/ExpressRoute Gateway と AWS Transit Gateway の比較
|
|
Microsoft Azure VPN/ExpressRoute Gateway |
AWS Transit Gateway |
|
|
|
クラウド管理者は、Microsoft Azure ポータルから VPN/ExpressRoute Gateway を手動で作成します。 |
Transit Gateway プロビジョニングは Cisco Cloud Network Controller の初回設定プロセスの一部として Cisco Cloud Network Controller により自動化されます。 |
|
| 設定の自動化 |
Microsoft Azure は、ゲートウェイ構成を自動化し、外部デバイスの構成テンプレート（デバイス構成スクリプトとも呼ばれます）をエクスポートします。クラウド管理者は、Cisco ISR、ASA などのさまざまな製品の構成テンプレートを選択できます。クラウド管理者は、外部デバイスに合わせて構成テンプレートを編集する必要がある場合があります。
|
Cisco Cloud Network Controller は、Transit Gateway の設定を自動化し、外部デバイスの構成テンプレートをエクスポートします。構成テンプレートは Cisco IOS-XE CLI シンタックスに基づいているため、クラウド管理者が外部デバイスに合わせて編集する必要がある場合があります。 |
|
| クラウドネイティブサービスと外部デバイス間のルーティングプロトコルとセキュリティ |
IPsec 上の外部 BGP。
|
IPsec 上の外部 BGP。 |
|
| スループットはサイズ変更可能か |
はい、クラウド管理者はゲートウェイ SKU を指定したり、スループット要件に応じて別の SKU に変更したりできます。
|
いいえ、Transit Gateway は固定サービスであるためです。 |
ユースケース #4-1：Microsoft Azure VPN Gateway と ExpressRoute Gateway を使用した外部サイトへの接続
このユースケースは、外部サイト（ブランチネットワークなど）を Microsoft Azure に直接接続するオプションの 1 つです。Microsoft Azure がゲートウェイの展開に必要とするゲートウェイサブネットは、初回設定時に Cisco Cloud Network Controller によって自動的に展開されます。Azure ExpressRoute Gateway と Azure VPN Gateway はどちらも、ブランチネットワークから Microsoft Azure への接続に使用できます。
· Azure ExpressRoute Gateway は、Microsoft のグローバルネットワークを介して Microsoft Azure への直接接続を提供します。転送されるデータはすべて暗号化されず、インターネットを経由しません。
· Azure VPN Gateway は、インターネットを介した Microsoft Azure への安全な接続を提供します。転送されるすべてのデータはプライベートトンネルで暗号化され、インターネットを経由します。
このユースケースでは、クラウド管理者が Microsoft Azure ポータルから直接 Microsoft Azure VPN Gateway（または ExpressRoute Gateway）を作成します。クラウド管理者は、ローカル ネットワーク ゲートウェイ（外部デバイスを表す Microsoft Azure の用語）も作成します。VPN Gateway の BGP ASN、外部デバイス、IPsec オプションなどの必須情報を入力すると、Microsoft Azure は外部デバイスタイプに基づいて構成テンプレートをエクスポートします（Microsoft Azure は、Cisco ASA、 ISR などさまざまなデバイスタイプをサポートします）。構成テンプレートには、IPsec トンネルや BGP の構成など、必要な情報が含まれています。構成テンプレートに基づいて外部デバイスを構成し、外部デバイスと Azure VPN Gateway の間に IPsec および BGP セッションを確立するのは、ネットワーク管理者の責任です。
外部デバイスの背後にあるブランチサブネットルートは、外部サイトからクラウドサイトへ、BGP を介して Azure VPN Gateway にアドバタイズされます。次に、Azure VPN Gateway は、ゲートウェイトランジットを使用した VNet ピアリング（トランジットピアリングとも呼ばれます）を使用して、ブランチサブネットルートをユーザー VNet（スポーク VNet とも呼ばれます）に伝達します。ゲートウェイトランジットを使用した VNet ピアリングは、Cisco Cloud Network Controller によって自動的に有効になります。
クラウドサイトから外部サイトへの逆方向では、ユーザーの VNet CIDR が Azure VPN Gateway に伝達され、Azure VPN Gateway が BGP を介して外部デバイスにアドバタイズします。
このユースケースの主な利点は、導入の柔軟性です。一部の設計シナリオでは、ブランチサイトが異なる物理リージョンに分散しており、すべてのブランチサイトがオンプレミスの ACI ファブリックを介してクラウドプラットフォームに接続するのは効率的ではありません。そのようなシナリオでは、このユースケースで、Azure ExpressRoute Gateway または VPN Gateway を終端ポイントとして利用し、ブランチサイトに展開された外部デバイスからクラウドプラットフォームに直接接続できます。Cisco Multi-Cloud Networking solution は一貫したポリシーモデルを引き続き提供します。
次の図はこのシナリオの例を示しています。この例では、外部 EPG 論理オブジェクト（Ext-EPG）を使用して、Microsoft Azure 外部のサブネットに属しており、クラウドでプロビジョニングされた EPG Web と通信する必要がある、すべてのエンドポイント（たとえば、外部サイト）を分類します。Ext-EPG と EPG Web の間で使用されるコントラクトの範囲は、[グローバル（global）] に設定する必要があります。これは、外部 EPG がインフラテナントに展開され、EPG「Web」がユーザーテナントに展開されるためです。
ブランチデバイスは IPsec と BGP を有効にする必要があることに注意してください。Microsoft Azure ExpressRoute Gateway と VPN Gateway がサポートするルートの数は限られているため、Microsoft Azure のドキュメントで最新のスケール数を確認してください。
ユースケース #4-2：AWS Transit Gateway を使用した外部サイトへの接続
このユースケースは、AWS のネイティブ ネットワーキング サービスである Transit Gateway を介して、ブランチネットワークなどの外部サイトを AWS に直接接続するオプションの 1 つです。Transit Gateway は、初回設定プロセス中に Cisco Cloud Network Controller によってインフラ VPC に自動的に展開されます。Cloud APIC 25.0(2) リリース以降、Cisco Cloud Network Controller は AWS Transit Gateway から外部サイトへの IPsec トンネルと BGP セッションを開始できます。Cisco Cloud Network Controller 管理者は、外部サイトのブランチデバイスのパブリック IP アドレスと BGP ASN、および AWS Transit Gateway とブランチデバイスの IKE や事前共有キーなどの一般的な IPsec パラメータを含む、適切な構成で外部接続を作成するだけです。構成ファイルをダウンロードし、Cisco Cloud Network Controller を介した接続を有効にして、外部デバイスを手動で構成するのはネットワーク管理者の責任です。
このユースケースの主な利点は、ネットワークの自動展開における柔軟性です。このユース ケースでは、Cisco Cloud Network Controller が TGW トンネルの構成と TGW ルートテーブルの作成を自動化します。さらに、Cisco Cloud APIC は、外部ネットワーク TGW ルートテーブルとユーザー VPC ルートテーブル間のルート伝達を自動化します。すべてのリージョンに Cisco Cloud ルータを導入する必要はありません。代わりに、AWS Transit Gateway VPN アタッチメントを活用することで、物理的な場所にあるブランチから異なる AWS リージョンにあるクラウドワークロードに接続できます。外部サイトの外部ネットワークはサブネットベースのセレクタを使用して外部 EPG として扱われ、外部 EPG とクラウド EPG の間でコントラクトを適用できるため、一貫したポリシーモデルも維持されます。
次の図で、構成例について説明します。この例では、外部 EPG は AWS 外部のサブネット用です。コントラクトの範囲は、[グローバル（global）] に設定する必要があります。これは、外部 EPG がインフラテナントに展開され、EPG「Web」がユーザーテナントに展開されるためです。 
ユースケース #5：WAN、ブランチ、または非 ACI サイトへの外部接続
このユースケースは、AWS と Microsoft Azure の両方で、Cloud APIC リリース 25.0(1) からサポートされている Cisco Cloud ルータの外部接続機能に基づいています。このユースケースは、オンプレミスの ACI ファブリックを経由せずに、外部 IP ネットワークをクラウドプラットフォーム（AWS および Microsoft Azure）に直接接続する必要がある場合に使用されます。
このユースケースとユースケース #4 の違いは、Cisco Cloud ルータまたはクラウド ネイティブ ルーティング サービスのどちらを終端地点として使用するかです。このユースケースの利点の 1 つは、ルーティングの規模です。Cisco Cloud ルータは、クラウドネイティブサービスと比較して、より多くのルートをサポートするためです。外部ネットワークのルーティングデバイスは、BGP と IPsec を使用して、インフラテナントの Cisco Cloud ルータへの IP 接続を確立する必要があります。集中型オーケストレーターとして、NDO は Cloud Network Controller と通信して Cisco Cloud ルータを構成し、外部デバイスの構成テンプレートを生成します。Cisco Cloud ルータは、外部デバイスが BGP と IPsec をサポートしている場合、クラウドプラットフォームの外部にある任意のネットワークに接続できます。
次の図で、構成例について説明します。この例では、外部ネットワークは Microsoft Azure 外部のサブネットとして分類されています。コントラクトの範囲は、[グローバル（Global）] に設定する必要があります。これは、外部 EPG がインフラテナントに展開され、EPG「Web」がユーザーテナントに展開されるためです。
このユースケースには、次のガイドラインがあります。
· 1 つのクラウドプラットフォームの Cisco Multi-Cloud Networking ソリューションによって管理される Cisco Cloud ルータは、他のクラウドプラットフォームの Cisco Cloud ルータに接続するブランチのトランジットにはなりません。たとえば、ブランチのエンドポイントからのトラフィックは、Microsoft Azure サイトの Cisco Cloud ルータを介して AWS サイトのエンドポイントに到達できません。
· Cisco Cloud ルータはブランチのトランジットにはできません。つまり、ブランチ 1 からのトラフィックは Cisco Cloud ルータを介してブランチ 2 に到達できません。
· Cisco Cloud ルータはブランチおよびオンプレミスの ACI サイトのトランジットにはできません。つまり、1つのブランチからのトラフィックは Cisco Cloud ルータを介してオンプレミスの ACI サイトに到達できません。
次の図は、サポートされているトラフィックフローとサポートされていないトラフィックフローを示しています。
ユースケース #6：SD-WAN ソリューションとの相互運用
Cloud APIC リリース 25.0(1) でサポートされている Cisco Cloud ルータの外部接続機能を活用することで、ユースケース #4 で説明されているように、Cisco SD-WAN または任意の SD-WAN ソリューションが Cisco Multi-Cloud Networking と相互作用して、ブランチ ネットワークからクラウド ワークロードへの接続とセグメンテーションを提供できます。
次の図はこのシナリオの例を示しています。Cloud ACI から見ると、SD-WAN ブランチ ネットワークは外部 EPG です。SD-WAN エッジデバイスは、パブリッククラウドプラットフォームなど、どこにでも導入できます。SD-WAN エッジデバイスから Cisco Cloud ルータへの通信チャネルには、インターネット、Microsoft Azure Express Route、AWS Direct Connect などがあります。
外部 EPG 分類を微調整して、SD-WAN ブランチネットワークからクラウドワークロードまでのエンドツーエンドのセグメンテーションを行うことができます。このシナリオ例では、branch-01 ネットワークサブネットは外部 EPG1 として分類され、branch-02 ネットワークサブネットは外部 EPG2 として分類されます。個別の外部 EPG を使用することで、ブランチ ネットワーク サブネットに基づいて異なるセキュリティポリシーを適用できます。たとえば、外部 EPG1 とクラウドの EPG1 の間にコントラクトを適用し、外部 EPG2 とクラウドの EPG2 の間に別のコントラクトを適用できます。この構成では、branch-01 はクラウドの EPG1 のワークロードと通信できますが、クラウドの EPG2 とは通信できません。一方、branch-02 はクラウドの EPG2 のワークロードとは通信できますが、クラウドの EPG1 とは通信できません。コントラクトが適用されている場合、セキュリティポリシーは Cloud Network Controller によって、AWS では SG ルール、Microsoft Azure では NSG ルールとして、それぞれプログラムされます。
このユースケースには、次のガイドラインがあります。
· 現時点では、Cisco SD-WAN コントローラと NDO は独立して動作します。NDO は、Cisco Cloud ルータの構成を自動化し、BGP および IPsec パラメータを含む外部デバイスの構成テンプレートを生成します。Cisco SD-WAN 管理者は、構成テンプレートに基づいて、cEdge デバイスを設定し、Cisco Cloud ルータへの IPsec および BGP セッションを確立できます。
· SD-WAN エッジデバイスと Cisco Cloud ルータの BGP ASN は異なっている必要があります。
このユースケースでは、ロードバランサが、サービスグラフに伴うコントラクトを使用して EPG 間に挿入されます。Cisco Multi-Cloud Networking ソリューションは、AWS および Microsoft Azure が提供するクラウド ネイティブ ロードバランサと、F5 BIG-IP Virtual Edition、Citrix ADC VPX などのサードパーティのロードバランサをサポートします。
次の表は、クラウド ネイティブ ロードバランサとサードパーティ ロードバランサで Cisco Multi-Cloud Networking ソリューションがサポートするものの違いをまとめたものです。
表 4 クラウド ネイティブ ロードバランサとサードパーティのロードバランサの比較
|
|
クラウド ネイティブ ロードバランサ |
サードパーティのロードバランサ |
|
|
|
Cisco Cloud Network Controller は、サービスグラフ展開の一部として、ロード バランサを作成および構成します。 |
サードパーティのロード バランサの作成と構成は、Cisco Cloud Network Controller の外部で行います。 |
|
| VIP のターゲットとしてプロバイダーエンドポイントを動的に追加/削除します |
はい
|
いいえ |
|
| サポートされているロードバランサ |
Cisco Multi-Cloud Networking ソリューションでは、クラウド ネイティブ ロード バランサは ALB または NLB と呼ばれます。 · ALB（Application Load Balancer） o AWS Application Load Balancer o Azure Application Gateway（Standard および Standard_v2 SKUs） · NLB（Network Load Balancer） o Azure Load Balancer（Standard SKU） |
ロードバランサの種類に制限はありません。 以下は、ロードバランサインスタンスの例です。 · F5 BIG-IP Virtual Edition · Citrix ADC VPX · Radware Alteon VA- ADC · A10 vThunder |
|
| 考慮事項 |
Cisco Cloud Network Controller リリース 25.1(1) の時点で、VM スケール セットは、Azure を使用する Cisco マルチクラウド ネットワーキング ソリューションでのみサポートされています。
|
サードパーティのロードバランサの挿入は、この記事の執筆時点で、Microsoft Azure を使用した Cisco Multi-Cloud Networking ソリューションでのみサポートされています。 |
|
2 つの主な違いは、Cisco Cloud Network Controller はクラウド ネットワーキングのルーティングとセキュリティ ポリシーに加えて、クラウド ネイティブ ロード バランサの作成と構成も管理しますが、Cisco Cloud Network Controller はサードパーティのロード バランサは管理しないことです。Cisco Cloud Network Controller はサードパーティのロードバランサを構成しないため、ロードバランサの VIP のターゲットとしてプロバイダーエンドポイントを動的に追加または削除する機能は、クラウド ネイティブ ロードバランサでのみ使用できます。
このドキュメントでは、以下で説明するロードバランサ挿入のユースケースについて説明し、各オプションのトラフィックフローと関連する展開の考慮事項について説明します。
· パブリック（外部）ロードバランサ：インターネットなどの外部ネットワークと、同じ VRF の一部であるプロバイダーエンドポイントとの間の垂直方向トラフィックフロー。パブリックロードバランサは、外部向けのパブリック IP アドレスを所有し、クラウドプラットフォームのプロバイダーエンドポイントへのトラフィックを負荷分散します。
· プライベート（内部）ロードバランサ：同じ VRF にあるコンシューマーエンドポイントとプロバイダーエンドポイントの間の水平方向トラフィックフロー。プライベートロードバランサはプライベート IP アドレスを所有し、クラウドプラットフォームのプロバイダーエンドポイントへのトラフィックを負荷分散するために使用されます。ハイブリッドシナリオでは、オンプレミスネットワークからロードバランサのフロントエンドにアクセスできます。
次の図は、パブリックおよびプライベート（内部）ロード バランサを使用した設計の例を示しています。
· パブリックロードバランサは、同じテナント内の外部 EPG「internet」と EPG「web」間のコントラクト「external-to-web」に挿入されます。
· プライベートロードバランサは、同じテナント内の EPG「web」と EPG「app」間のコントラクト「web-to-app」に挿入されます。
この図では、プライベートロードバランサに 1 つの VRF（VPC または VNet）を使用していますが、Azure では VNet 間設計もサポートされています。オンプレミスの ACI ファブリックとは異なり、クラウド サイトはロードバランサの設計にトラフィックリダイレクトを使用しないため、前提として、リターントラフィックが接続を開始したクライアントに到達する前にロードバランサに誘導されるように、SNAT を常に有効にする必要があります。
クラウド ネイティブ ロードバランサのユースケースには、次のガイドラインがあります。
· SNAT は ALB では有効化されていますが、NLB では有効化されていません。
· Cisco Cloud Network Controller は、Azure Load Balancer（NLB）および Application Gateway（ALB）のバックエンドターゲットとして VM インスタンスと VM スケールセットをサポートしています。VM スケール セットをバックエンド ターゲットとして使用するには、リリース 25.0(2) 以降が必要です。
· Cisco Network Controller は、AWS Application Load Balancer（ALB）のバックエンドターゲットとして Amazon EC2 インスタンスをサポートしています。現時点では、Auto Scaling グループはサポートされていません。
· AWS ALB：コンシューマーとプロバイダーの EPG は、同じ VPC にある必要があります。ALB は、ターゲット EC2 インスタンスが存在する同じ VPC の 2 つのアベイラビリティゾーンに関連付けられています。アベイラビリティゾーンごとに、ALB のアベイラビリティゾーンで 1 つのサブネットを選択する必要があり、そのサブネットは、TGW VPC のアタッチメントに使用されるサブネットであってはなりません。（Transit Gateway の設計プラクティスの推奨事項に基づいて、 Cisco Multi-Cloud Networking ソリューションでは、VPC を Transit Gateway にアタッチするために、アベイラビリティゾーンごとに 1 つの専用ゲートウェイサブネットが必要です。）下の図 46 は、シナリオの例を示しています。
· Azure NLB：NLB とそのターゲット（プロバイダー EPG）は、同じ VNet 内にある必要があります。NLB は専用サブネットにある必要があります。
· Azure ALB：ALB は、コンシューマーとプロバイダーから到達可能なハブ VNet またはプロバイダー VNet のいずれかにある必要があります。ALB は専用サブネットにある必要があります。
· 動的 IP または静的 IP の割り当て
o パブリックおよびプライベート/内部 AWS ロードバランサ（Azure ALB）：
§ 動的 IP が使用されます。
o パブリック Azure Application Gateway（Azure ALB）：
§ Standard V1 の場合、動的パブリック IP が使用されます。
§ Standard V2 の場合、静的パブリック IP が使用されます。
o プライベート/内部 Azure Application Gateway（Azure ALB）：
§ Standard V1 の場合、Azure が静的および動的プライベート IP の両方をサポートしているため、両方がサポートされます。
§ Standard V2 の場合、Azure が Standard V2 の動的プライベート IP をサポートしていないため、静的プライベート IP のみがサポートされます。
· 現時点では、サイト間トラフィックはサポートされていません。次に例を示します。
o コンシューマーが AWS サイトにあり、プロバイダーが Microsoft Azure サイトにある場合。
o コンシューマーが ACI オンプレミスサイトにあり、プロバイダーが Microsoft Azure サイトにある場合。
サードパーティのロードバランサのユースケースには、次のガイドラインがあります。
· 現時点では、 Cisco Multi-Cloud Networking ソリューションは Microsoft Azure でのサードパーティのロードバランサの挿入のみをサポートしています。
· サードパーティのロードバランサは、コンシューマーとプロバイダーから到達可能なハブ VNet またはプロバイダー VNet にある必要があります。
· サードパーティのロードバランサで SNAT を有効にする必要があります（現時点では、リターントラフィックのトラフィックリダイレクトはサポートされていません）。
· サードパーティのロードバランサは、次の設計オプションをサポートしていません。
o ワンアーム モード
o リダイレクション
o DSR（Direct Server return）
o ロードバランサ インターフェイス サブネットの外部にあるエイリアン VIP 範囲。
o アクティブ-スタンバイ HA
· 現時点では、サイト間トラフィックはサポートされていません。次に例を示します。
o コンシューマーが AWS サイトにあり、プロバイダーが Microsoft Azure サイトにある場合。
o コンシューマーが ACI オンプレミスサイトにあり、プロバイダーが Microsoft Azure サイトにある場合。
特に明記されていない限り、次のサブセクションでは、SNAT を備えた Azure Application Gateway を使用した Azure での Cisco Cisco Multi-Cloud Networking ソリューションを例として使用します。
次の図は、パブリックロードバランサを使用した設計の例を示しています。この設計の一般的なユースケースは、インターネットなどの外部ネットワークに公開されるパブリックサービスです。この例では、外部 EPG がコンシューマーであり、クラウド EPG 「Web」がコントラクトのプロバイダーです。ロードバランサのインターフェイスは 1 つです。コンシューマーから VIP へのトラフィックは、ロードバランサに着信します。ロードバランサが送信元と接続先の IP アドレスを変更した後、トラフィックはクラウド EPG 「Web」のエンドポイントの 1 つに転送されます。リターントラフィックは、NAT された IP アドレスを所有するロードバランサに戻ります。ロードバランサが送信元と接続先の IP アドレスを変更すると、トラフィックは外部エンドポイントに転送されます。
前のサブセクションのロードバランサの挿入に関する考慮事項で提供されたガイドラインに加えて、このユースケースには次のガイドラインがあります。
· この例ではインフラ VNet でロードバランサを使用していますが、Azure を使用した Cisco Multi-Cloud Networking ソリューションでは、次のような他の組み合わせもサポートされています。
o インフラ VNet 内のコンシューマー外部 EPG、ロードバランサ、プロバイダークラウド EPG。
o インフラ VNet 内のコンシューマー外部 EPG とロードバランサ、ユーザー VNet 内のプロバイダークラウド EPG。
o インフラ VNet 内のコンシューマー外部 EPG、ユーザー VNet 内のロードバランサおよびプロバイダークラウド EPG。
· ALB を使用した AWS での Cisco Multi-Cloud Networking ソリューションは、VPC 内設計のみをサポートします。つまり、コンシューマー、ロードバランサ（ALB）、プロバイダーは同じ VPC に存在する必要があります。
次の図は、プライベート ロード バランサを使用した設計の例を示しています。この設計の一般的なユースケースは、他のプライベートネットワークに公開されるサービスです。この例では、クラウド EPG 「Web」がコンシューマーであり、クラウド EPG 「App」がコントラクトのプロバイダーです。ロードバランサのインターフェイスは 1 つです。コンシューマーから VIP へのトラフィックは、ロードバランサに着信します。ロードバランサが送信元と接続先の IP アドレスを変更した後、トラフィックはクラウド EPG 「App」のエンドポイントの 1 つに転送されます。リターントラフィックは、NAT された IP アドレスを所有するロードバランサに戻ります。ロードバランサが送信元と接続先の IP アドレスを変更すると、トラフィックは外部エンドポイントに転送されます。
前のサブセクションのロードバランサの挿入に関する考慮事項で提供されたガイドラインに加えて、このユースケースには次のガイドラインがあります。
· この例では VNet 内設計を使用していますが、Azure を使用した Cisco Multi-Cloud Networking ソリューションでは、次のような他の組み合わせもサポートされています。
o 同じ VNet 内のコンシューマークラウド EPG、ロードバランサ、プロバイダークラウド EPG。
o コンシューマー VNet のコンシューマークラウド EPG、プロバイダー VNet のロードバランサおよびプロバイダークラウド EPG。
o コンシューマー VNet のコンシューマークラウド EPG、インフラ VNet のロードバランサ、プロバイダー VNet のプロバイダークラウド EPG。
· ALB を使用した AWS での Cisco Multi-Cloud Networking ソリューションは、VPC 内設計のみをサポートします。つまり、コンシューマー、ロードバランサ（ALB）、プロバイダーは同じ VPC に存在する必要があります。
このユースケースでは、サービスグラフに伴うコントラクトを使用した EPG 間のファイアウォール挿入について説明します。現時点では、これは Microsoft Azure を使用した Cisco Multi-Cloud Networking ソリューションでのみサポートされています。Cisco Multi-Cloud Networking ソリューションは、Cisco Adaptive Security Virtual Appliance（ASAv）、Cisco Firepower NGFW Virtual（NGFWv）などのサードパーティ ファイアウォールをサポートしています。Azure Firewall や Azure Web Application Firewall（WAF）などのクラウド ネイティブ セキュリティ サービスは、現在サポートされていません。
Cisco Cloud Network Controller は、ルーティングとセキュリティ ポリシーを管理して、クラウド ネットワーキングにファイアウォールを挿入します。ただし、Cisco Cloud Network Controller はサードパーティのファイアウォールを管理しません（Cisco Cloud Network Controller がサードパーティのロード バランサを管理しないのと同様です）。トラフィックをファイアウォールにリダイレクトするために、Cisco Cloud Network Controller は、サービス グラフを使用するコントラクトに基づいて UDR（ユーザー定義ルート）を構成します。
このセクションでは、以下で説明するファイアウォール挿入のユースケースについて説明し、各オプションのトラフィックフローと関連する展開の考慮事項について説明します。
· NAT を使用したファイアウォールの挿入：クラウドエンドポイントによって開始された外部ネットワークへの垂直方向トラフィックフロー。ファイアウォールは、クラウドエンドポイントのプライベート IP アドレスをパブリック IP アドレスに変換します。
· NAT を使用しないファイアウォール挿入：異なる VRF にあるコンシューマーエンドポイントとプロバイダーエンドポイントの間の水平方向トラフィックフロー。
次の図は、ファイアウォールを使用した設計の例を示しています。垂直方向ファイアウォールは、外部 EPG 「internet」と EPG 「Web」間のコントラクト「external-to-web」に挿入されます。トラフィックリダイレクトは、外部サイトへのトラフィックに対してのみ有効になっています。水平方向ファイアウォールは、EPG「Web」と EPG 「App」間のコントラクト「web-to-app」に挿入されます。トラフィックのリダイレクトは両方向で有効になっています。
· VNet 間トラフィックの場合、VNet ピアリングが必要です。
· リダイレクトの接続先（この例ではファイアウォール インターフェイスの IP アドレス）は、ハブ VNet（インフラ VNet）内にある必要があります。
· ファイアウォール インターフェイスは、クラウド EPG が存在するサブネットとは異なる専用サブネットにある必要があります。
· 現時点では、サイト間トラフィックはサポートされていません。次に例を示します。
o コンシューマーが AWS サイトにあり、プロバイダーが Microsoft Azure サイトにある場合。
o コンシューマーが ACI オンプレミスサイトにあり、プロバイダーが Microsoft Azure サイトにある場合。
このセクションでは例として単一ノードのファイアウォールについて説明しますが、高可用性のために複数のファイアウォールを使用することをお勧めします。ロードバランサを使用してトラフィックを複数のファイアウォールに分散させる方法については、マルチノードサービスの挿入セクションで説明します。
ユースケース #8-1：垂直方向ファイアウォールの挿入：NAT を使用した内部から外部へのトラフィック
次の図は、NAT でファイアウォールを挿入した設計の例を示しています。この設計の一般的なユースケースは、クラウドエンドポイントがインターネットからソフトウェアアップデートをダウンロードするなど、クラウドエンドポイントによって外部ネットワークに対して開始される通信です。この例では、外部 EPG「Internet」がコントラクトのプロバイダーであり、クラウド EPG「Web」がコントラクトのコンシューマーです。ファイアウォールには、異なるサブネットに「FW-External」と「FW-Web」という 2 つのインターフェイスがあります。コンシューマー（Web）からプロバイダー（Internet）へのトラフィックは、ファイアウォールの「FW-Web」インターフェイスにリダイレクトされ、ファイアウォールは「FW-External」インターフェイスを介してトラフィックを外部ネットワークに送信します。ファイアウォール上の送信元 NAT（SNAT）のため、リターントラフィックは、NAT された IP アドレスを所有するファイアウォール信頼インターフェイスに戻ります。
コントラクトを伴うサービスグラフ展開の一環として、Cisco Cloud Network Controller は、Web サブネットと外部 EPG サブネット間の通信でトラフィックをファイアウォールにリダイレクトする出力ルートテーブルを作成します。この例では、Web サブネット（192.168.1.0/24）は、FW-Web サブネット内のファイアウォールの IP アドレスを次のホップとして使用して、外部ネットワーク（0.0.0.0/0）に到達します。NSG もそれに応じて更新されます。
前のサブセクションのファイアウォールの挿入に関する考慮事項で提供されたガイドラインに加えて、このユースケースには次のガイドラインがあります。
· 外部 EPG とコンシューマー EPG は、同じ VNet または異なる VNet に配置できます。
· 外部から内部（垂直型）のトラフィック方向の場合、非 ACI ネットワーク（ExpressRoute 経由の外部 EPG）から Microsoft Azure サイトのクラウドエンドポイントへのトラフィックであれば、リダイレクトがサポートされます。詳細については、「垂直方向トラフィックフローの NLB-FW 挿入」を参照してください。
· 同じ外部ネットワークに接続しているがリダイレクトを必要としない別のクラウド EPG がある場合、そのサブネットは、リダイレクトを必要とするクラウド EPG のサブネットとは異なる CIDR にある必要がある場合があります。詳細については、サードパーティ ファイアウォールの管理ネットワークに関する考慮事項セクションを参照してください。
ユースケース #8-2：水平方向ファイアウォールの挿入：NAT を使用しないスポーク間トラフィック
次の図は、NAT なしでファイアウォールを挿入した設計の例を示しています。この例では、クラウド EPG 「Web」がコンシューマーであり、クラウド EPG 「App」がコントラクトのプロバイダーです。ファイアウォールには、異なるサブネットにある信頼と非信頼の 2 つのインターフェイスがあります。リダイレクトは両方で有効になっています。
コントラクトを使用するサービスグラフ展開の一部として、Cisco Cloud Network Controller は両方向の出力ルートテーブルを作成します。
· 1 つは、トラフィックを Web サブネットから App サブネットにリダイレクトし、次に FW-Web サブネットのファイアウォール IP アドレスにリダイレクトします。
· もう 1 つは、トラフィックを App サブネットから Web サブネットにリダイレクトし、次に FW-App サブネットのファイアウォール IP アドレスにリダイレクトします。
NSG も更新され、コンシューマーサブネットからプロバイダーサブネットへのトラフィックを許可します。そのため、明示的な許可ルールがない場合でも、プロバイダーからコンシューマーへのリターントラフィックは自動的に許可されます。
前のサブセクションのファイアウォールの挿入に関する考慮事項で提供されたガイドラインに加えて、このユースケースには次のガイドラインがあります。
· 同じリージョンに展開されたコンシューマーとプロバイダーの EPG は、同じ VNet の一部にすることはできません。
このセクションでは、ファイアウォールとロードバランサの両方に適用される、サービス挿入に関する次の一般的な設計上の考慮事項について説明します。
· サードパーティ アプライアンスの管理ネットワークに関する考慮事項
· ハブ VNet（overlay-1）のサブネット内のサービスアプライアンス
サードパーティ アプライアンスの管理ネットワークに関する考慮事項
このサブセクションでは、例としてサードパーティ ファイアウォールを使用するサードパーティ アプライアンスの管理ネットワークの設計上の考慮事項について説明します。
これらの例では、ファイアウォールの管理インターフェイスは、コントラクトのプロバイダーであるクラウド EPG「FW-mgmt」の一部であり、EPG または外部 EPG がコンシューマーです。この場合、クラウド サイトのコントラクトは、コンシューマーからプロバイダーへのトラフィックのみに対する許可ルールを作成するため、ファイアウォールによって発信されコンシューマーに向かうトラフィックは許可されません。プロバイダーからコンシューマーへのリターントラフィックは、（明示的な許可ルールがない場合でも）自動的に許可されます。これは、コンシューマーからプロバイダーへのトラフィックが以前に監視されているためです。したがって、サービスデバイスの管理インターフェイスが別の EPG との通信を開始する可能性がある場合、両方の EPG がコントラクトのコンシューマーであり、プロバイダーである必要があります。この考慮事項は、このセクションの両方の例に適用できますが、例ではプロバイダー EPG としてクラウド EPG 「FW-mgmt」を使用します。
オンプレミス ACI ファブリックから管理ネットワークへのアクセス
次の図は、設計例を示しています。オンプレミスの ACI ファブリックとクラウドのファイアウォールの管理インターフェイス間のトラフィックを許可するために、ファイアウォールの管理インターフェイス用に EPG「Client-mgmt」とクラウド EPG「FW-mgmt」の間でコントラクトが構成されます。論理設計は、「ユースケース #2：ユースケース #2：複数のサイトにまたがるアプリケーション（テナント間共有サービス）」に似ています。この例では EPG 間の VRF 間コントラクトを使用しますが、代わりに VRF 内コントラクトにすることもでき、またクライアントは通常の EPG ではなくオンプレミスの外部 EPG にすることもできます。
外部ネットワークから管理ネットワークへのアクセス
このシナリオは、Microsoft Azure を使用する Cisco Multi-Cloud Networking ソリューションで利用可能なリダイレクト機能に適用できます。次の図は、設計例を示しています。外部ネットワークとファイアウォールの管理インターフェイス間のトラフィックを許可するために、ファイアウォールの管理インターフェイス用に外部 EPG とクラウド EPG「FW-mgmt」の間でコントラクトが構成されます。
外部 EPG と、クラウド EPG FW-mgmt と同じ CIDR に展開されているクラウド EPG（以下の例では EPG「Web」）との間のトラフィックに対してリダイレクトが有効になっている場合、他のクラウド EPG コントラクト（以下の例では「external-to-web」コントラクト）用に Cisco Cloud Network Controller によって構成された出力ルートテーブルのために、FW-mgmt サブネットからのトラフィックもリダイレクトされます。リダイレクトを伴うサービスグラフ展開の一部として、Cisco Cloud Network Controller は、以下に示すように、サービス デバイス インターフェイスのサブネットを除き、CIDR 内のすべてのサブネットからファイアウォールにトラフィックをリダイレクトする出力ルートテーブルを作成します。この状況では、外部ネットワークからクラウド EPG FW-mgmt への接続が失われる可能性があります。
その場合、クラウド EPG「FW-mgmt」のファイアウォールの管理インターフェイスにアクセスするには、別の CIDR のジャンプホストを使用する必要があります。次の図で、構成例について説明します。クラウド EPG 「Jump-host」は、クラウド EPG 「Web」とは異なる CIDR にある「Jump-subnet」にあります。CIDR が異なるため、「Jump-host」サブネットは、ファイアウォール挿入のリダイレクトを使用した出力ルートテーブルを参照しません。出力ルートテーブルと、それに応じた「FW-mgmt」と「Jump-host」間のコントラクトを追加することで、管理者はジャンプホスト VM にアクセスし、その後ジャンプホスト VM からファイアウォールの管理インターフェイスにアクセスできます。
ハブ VNet（overlay-1）のサブネット内のサービスアプライアンス
このサブセクションでは、ハブ VNet に CIDR とサブネットを追加するシナリオについて説明します。これらの CIDR とサブネットは、サービスアプライアンスに使用できます。このシナリオは、Microsoft Azure を使用する Cisco Multi-Cloud Networking ソリューションに適用できます。
Azure ポータルの overlay-1 VNet（「インフラ VNet」または「ハブ VNet」とも呼ばれます）は、Cisco Cloud Network Controller によって作成され、Cisco Cloud ルータおよび Cisco Cloud ルータのロードバランシング用の NLB を展開します。
ハブ VNet にサービスアプライアンスを追加する必要がある場合は、以下のいずれかのオプションを使用して、新しい CIDR とサブネットをハブ VNet に追加する必要があります。
リリース 25.0(2) より前は、Cisco Cloud Network Controller は、インフラ VNet に 2 つのオブジェクト、overlay-1 と overlay-2 を内部的に作成していました。
· overlay-1 の CIDR は、Cisco Cloud ルータと、Cisco Multi-Cloud Networking ソリューションの必須コンポーネントである Cisco Cloud ルータ ロード バランシングの NLB を展開するために使用されます。
· overlay-2 の CIDR は、ユーザー定義のサービスアプライアンスの展開に使用できます。overlay-2 に新しい CIDR とサブネットを追加できます。
次の図で、構成例について説明します。
リリース 25.0(2) 以降、Cisco Cloud Network Controller が以前のリリースから 25.0(2) にアップグレードされない限り、overlay-2 は存在しません。overlay-2 を使用する代わりに、新しい VRF をハブ VNet に追加できます。新しい VRF は、ユーザー定義のサービスアプライアンスの新しい CIDR およびサブネットに使用できます。次の図で、構成例について説明します。
overlay-2 に新しい CIDR を追加するとき、または Cisco Cloud Network Controller を介してハブ VNet にユーザー定義の VRF を追加するときは、VNet ピアリングを無効にする必要があるため、最初にサービスデバイスの CIDR を作成することをお勧めします（既存の CIDR に新しいサブネットを追加するために VNet ピアリングを無効にする必要はありません）。
このユースケースは、サービスグラフを伴うコントラクトを使用した EPG 間のマルチノードサービス挿入です。Cisco Multi-Cloud Networking ソリューションは、同じサービス グラフで、サードパーティ ファイアウォール、クラウド ネイティブ ロード バランサ、およびサードパーティ ロードバランサの組み合わせをサポートします。単一ノードサービスの挿入については、「ロードバランサの挿入」セクションおよび「ファイアウォールの挿入」セクションを参照してください。
このユースケースの主な利点は、トラフィックを複数のファイアウォールに分散させることで、高可用性とファイアウォール インスペクションのキャパシティが向上することです。
このセクションでは、さまざまなマルチノードサービス挿入のユースケースについて説明し、各オプションのトラフィックフローと関連する展開の考慮事項について説明します。
· 水平方向トラフィックフローの NLB-FW 挿入：サービスデバイスは、異なる Vnet にあるコンシューマー エンドポイントとプロバイダーエンドポイントの間に挿入されます。ファイアウォールの前に展開された NLB 機能によって、トラフィックフローが複数のファイアウォールに分散されます。
· 垂直方向トラフィックフローの NLB-FW 挿入：サービスデバイスは、非 ACI オンプレミスサイトに向かう外部ネットワークと、プロバイダーエンドポイントの間に挿入されます。ファイアウォールの前にある NLB によって、トラフィックフローが複数のファイアウォールに分散されます。
· NLB-FW-LB 挿入：別のロードバランサ（NLB、ALB、またはサードパーティのロードバランサ）をファイアウォールの背後に追加して、クラウドプラットフォームのプロバイダーエンドポイントにトラフィックを分散させることができます。
他のユースケースのリストについては、『Cisco Cloud APIC for Azure User Guide』の「Deploying Layer 4 to Layer 7 Services section」セクションを参照してください。
次の図は、マルチノードサービスグラフを使用した設計の例を示しています。
· プライベートロードバランサは、EPG「Web」と EPG 「App」間のコントラクト「web-to-app」に挿入されます。
· パブリックロードバランサは、外部 EPG 「internet」と EPG 「web」間のコントラクト「external-to-web」に挿入されます。
次の図は、ファイアウォールの背後に別のロードバランサ（NLB、ALB、またはサードパーティのロードバランサ）を持つ 3 ノードサービス挿入のユースケースを示しています。
マルチノードサービスの挿入には、次のガイドラインがあります。
· サービス デバイス インターフェイスは、クラウド EPG が存在するサブネットとは異なる専用サブネットにある必要があります。
· VNet 間トラフィックの場合、VNet ピアリングが必要です。
· リダイレクト先（この例では NLB IP アドレス）は、ハブ VNet（インフラ VNet）にある必要があります。
· ロードバランサ インターフェイスとそのターゲットは、同じ VNet 内にある必要があります。
· 現時点では、サイト間の水平方向通信はサポートされていません。次に例を示します。
o コンシューマー エンドポイントが AWS サイトにあり、プロバイダーエンドポイントが Microsoft Azure サイトにある場合。
o コンシューマー エンドポイントが ACI オンプレミスサイトにあり、プロバイダーエンドポイントが Microsoft Azure サイトにある場合。
· 外部から内部（垂直型）のトラフィック方向の場合、非 ACI ネットワーク（ExpressRoute 経由の外部 EPG）から Microsoft Azure サイトのクラウドエンドポイントへのトラフィックであれば、リダイレクトがサポートされます。
· マルチノードサービスグラフの場合、サードパーティのロードバランサ インターフェイスは「サブネットベース」のインターフェイスセレクタを使用する必要があります。
ユースケース #9-1：水平方向トラフィックフローの NLB-FW 挿入
次の図は、複数のファイアウォールへの水平方向トラフィックを NLB ロードバランシングする設計の例を示しています。この構成例では、クラウド EPG 「Web」がコントラクトのコンシューマーであり、クラウド EPG 「App」がコントラクトのプロバイダーです。ファイアウォールのインターフェイスは 1 つです。
NLB の双方向でリダイレクトが有効になっています。
コントラクトを使用するサービスグラフ展開の一部として、Cisco Cloud Network Controller は両方向の出力ルートテーブルを作成します。
· 1 つは、Web サブネットから App サブネットへの通信で、NLB IP アドレスにトラフィックをリダイレクトするためのものです。
· もう 1 つは、App サブネットから Web サブネットへの通信で、NLB IP アドレスにトラフィックをリダイレクトするためのものです。
NLB により、着信トラフィックとリターントラフィックの両方が、同じファイアウォールに負荷分散されます。Cisco Cloud Network Controller も、それに応じて NSG および NLB 構成を更新します。たとえば、Cisco Cloud Network Controller は、ファイアウォールの NSG に入力セキュリティルールと出力セキュリティルールを追加し、コンシューマサブネットからプロバイダーサブネットへのトラフィックを許可します。そのため、明示的な許可ルールがない場合でも、プロバイダーからコンシューマーへのリターントラフィックは自動的に許可されます。
前のサブセクションのマルチノードサービスの挿入に関する考慮事項で提供されたガイドラインに加えて、このユースケースには次のガイドラインがあります。
· コンシューマーとプロバイダーの EPG は、同じリージョンに展開されている場合、同じ VNet の一部にすることはできません。
ユースケース #9-2：垂直方向トラフィックフローの NLB-FW 挿入
次の図は、複数のファイアウォールへの垂直方向トラフィックを NLB ロードバランシングする設計の例を示しています。この構成例では、非 ACI オンプレミスサイトに接続された外部 EPG「オンプレミス」がコントラクトのコンシューマーであり、クラウド EPG「Web」がコントラクトのプロバイダーです。ファイアウォールのインターフェイスは 1 つです。NLB の双方向でリダイレクトが有効になっています。
コントラクトを使用するサービスグラフ展開の一部として、Cisco Cloud Network Controller は両方向の出力ルートテーブルを作成します。
· 1 つは、トラフィックを外部 EPG サブネットから Web サブネットにリダイレクトし、次に NLB IP アドレスにリダイレクトするためのものです。
· もう 1 つは、トラフィックを Web サブネットから外部 EPG サブネットにリダイレクトし、次に NLB IP アドレスにリダイレクトするためのものです。
NLB により、着信トラフィックとリターントラフィックの両方が、同じファイアウォールに負荷分散されます。Cisco Cloud Network Controller も、それに応じて NSG および NLB 構成を更新します。
前のサブセクションのマルチノードサービスの挿入に関する考慮事項で提供されたガイドラインに加えて、このユースケースには次のガイドラインがあります。
· 外部 EPG は Azure ExpressRoute を経由する必要があります。これは、外部 EPG が非 ACI オンプレミスネットワークを表すことを示しています。
· 非 ACI ネットワーク（ExpressRoute 経由の外部 EPG 内）からクラウドエンドポイント（クラウド EPG 内）へのトラフィックのリダイレクトを有効にするには、リリース 5.1(2) リリース以降が必要です。
· Azure ExpressRoute を経由しない外部 EPG は、リダイレクトをサポートしていません。
· このドキュメントでは主にリダイレクトのユースケースについて説明していますが、リダイレクトなしでハブ VNet に ExpressRoute ゲートウェイを展開することもできます。
· サイト内の異なる Cisco Cloud Network Controller 管理リージョンに複数のハブ VNet がある場合（リージョン間設計）、次の設計ガイドラインが適用されます。
o 各リージョンには、ハブ VNet に ExpressRoute ゲートウェイが必要です。
o 各 ExpressRoute ゲートウェイは同じルーティングドメインに接続され、お客様のネットワークから同じルートセットを受け取ります。
o 特定のスポークの場合、ローカルリージョンのハブ VNet がトランジット VNet として最初に選択されます。ローカルリージョンの ExpressRoute ゲートウェイが障害のために使用できない場合、代替リージョンが自動的に選択されます。
このユースケースの目的は、次の図に示すように、「水平方向トラフィックフローの NLB-FW 挿入」で説明されているユースケースに別のロードバランサ（NLB、ALB、またはサードパーティのロードバランサ）を追加することです。このサブセクションでは、水平方向トラフィックフローに別のロードバランサを追加する例（ユースケース #9-1）を使用しますが、垂直方向トラフィックフローに別のロードバランサを追加するのも有効な設計です（ユースケース#9-2）。
コントラクトを使用するサービスグラフ展開の一部として、Cisco Cloud Network Controller は両方向の出力ルートテーブルを作成します。
· 1 つは、Web サブネットおよびサードパーティのロードバランサの VIP からのトラフィックを NLB IP アドレスにリダイレクトするためのものです。
· もう 1 つは、LB サブネットおよび Web サブネットから NLB IP アドレスへのトラフィックをリダイレクトするためのものです。
NLB により、着信トラフィックとリターントラフィックの両方が、同じファイアウォールに負荷分散されます。Cisco Cloud Network Controller も、それに応じて NSG および NLB 構成を更新します。Cisco Cloud Network Controller はサードパーティのロードバランサを構成しないため、お客様が適宜構成する必要があります。
前のサブセクションのマルチノードサービスの挿入に関する考慮事項で提供されたガイドラインに加えて、このユースケースには次のガイドラインがあります。
· コンシューマーとプロバイダーの EPG は、同じリージョンにある場合、同じ VNet に置くことはできません。
ユースケース #10：Microsoft Azure でのクラウドネイティブサービスの統合
現時点では、この機能は Microsoft Azure を使用した Cisco Multi-Cloud Networking ソリューションでのみサポートされています。Cisco Cloud Network Controller では、クラウドサービス EPG と呼ばれる新しいタイプの EPG が導入されています。クラウドサービス EPG は、構成されたセレクタに基づくサービスユニットのコレクションです。たとえば、クラウドストレージサービス EPG は、特定のキーと値のペアでタグ付けされたすべてのストレージユニット（Microsoft Azure のコンテナまたは blob）で構成されている場合があります。クラウドサービス EPG は、サービスとしてのプラットフォームやサービスとしてのソフトウェアなどの導入モデルのタイプも示します。
クラウドサービス EPG のプロパティは次のとおりです。
· [名前（Name）]：EPG の名前
· [サービスタイプ（Service Type）]：この EPG が表すサービスのタイプ。例：Azure Storage、AKS、Databricks など。サードパーティのサービス（SaaS）の場合、サービスタイプは「custom」になります。
· [展開タイプ（Deployment Type）]：サービスは、導入モデルに基づいて区別されます。このフィールドは、これがクラウドネイティブか SaaS サービスか、およびホストしているのがお客様の VNet か Azure VNet かを示します。簡単に言えば、この属性は、サービスが展開されている方法と場所を示します。使用可能な展開タイプは次のとおりです。
o [クラウドネイティブ（Cloud Native）]：Microsoft Azure 独自の VNet（Cisco Cloud Network Controller によって作成された VNet ではありません）でホストされるクラウド ネイティブ サービス。
o [クラウドネイティブ管理（Cloud Native Managed）]：お客様の VNet（Cisco Cloud Network Controller によって作成された VNet）でホストされるクラウド ネイティブ サービス。
o [サードパーティ（Third-Party）]：マーケットプレイスを通じてサービスを提供するサードパーティ（Microsoft Azure ではない）のサービス。このサービスへのアクセスは、プライベートリンク機能を通じて提供されます。
· [アクセスタイプ（Access Type）]：サービスへのアクセスの種類。
o [パブリック（Public）]：サービスには、割り当てられたパブリック IP アドレスを使用してアクセスできます。特定のサービスのパブリック IP アドレス範囲へのアクセスは、NSG ルールの Azure「サービスタグ」を使用して行います。
o [プライベート（Private）]：サービスには、割り当てられたプライベート IP アドレスを使用してアクセスできます。この割り当ては、展開が [クラウドネイティブ（Cloud Native）] に設定されている場合に、プライベートエンドポイントを作成することで行われます。[クラウドネイティブマネージド（Cloud Native Managed）] 展開の場合、プライベート IP はサービスによってサブネット IP スペースから割り当てられます。
Azure サービスタグの詳細については、https://docs.microsoft.com/en-us/azure/virtual-network/service-tags-overview を参照してください。
サポートされるクラウドサービス EPG セレクタは、展開タイプによって異なります。たとえば、クラウド サービスがお客様の VNet（Cisco Cloud Network Controller によって作成された VNet）に展開される [クラウド ネイティブ マネージド（Cloud Native Managed）] の場合、次のセレクタを使用できます。タグ、リージョン、サービス名、およびサービスが展開されているサブネット IP アドレス。クラウド サービス EPG が作成されると、Cisco Cloud Network Controller はプライベート エンドポイントとプライベート リンクを自動的に作成します。クライアントマシンからサービスへのアクセスの制御に、コントラクトを適用できます。
次の図は、サービスがクラウドサービス EPG にグループ化される例を示しています。Cisco Cloud Network Controller では、適切な NSG ルールをプログラミングすることで、EPG からクラウド サービス EPG への通信を制御できます。たとえば、Cisco Cloud Network Controller によって作成された VNet に AKS クラスタを展開し、インターネットからポート TCP 80 の AKS サービスに到達するトラフィックのみを許可できます。このポートは、インターネット外部 EPG と AKS クラウドサービス EPG「AzureEKS」の間に適用されるコントラクトのフィルタルールで構成されます。クラウド管理者は、異なるルールを使用して別のコントラクトを構成し、EPG（クライアント EPG など）から AKS クラウドサービス EPG「AzureEKS」への通信を制御することもできます。EPG は、クラウドサービス EPG と同じ VNet または別の VNet に配置できます。
ユースケース #11：Microsoft Azure および AWS でのブラウンフィールド インポート
このユースケースは、Cisco Multi-Cloud Networking インフラストラクチャに接続する必要がある既存のパブリック クラウド リソースがある場合に使用されます。リリース 5.2(1) より前は、Cisco Multi-Cloud Networking ソリューションは、Cisco Cloud Network Controller がリソースグループ、VPC/VNet、CIDR、サブネットなどをゼロから作成するグリーンフィールド環境のみをサポートします。つまり、既存のブラウンフィールド環境（リソースグループ、VPC/ VNET などは Cisco Cloud Network Controller を使用せずにユーザーが作成済み）は、Cisco Cloud Network Controller が管理するリソースでは共存できません。Microsoft Azure の場合はリリース 5.2 以降、AWS の場合はリリース 25.0(2) 以降、「読み取り専用」オプションをもつブラウンフィールド環境との共存機能がサポートされています。Microsoft Azure および AWS のリリース 25.0(4) 以降、「ルーティングとセキュリティ」および「ルーティングのみ」オプションもサポートされています。
Cisco Cloud Network Controller は、既存のブラウンフィールド VPC/VNet のインポートをサポートし、VPC/VNet および SG/NSG を含む Cisco Cloud Network Controller 管理のリソースグループからのネットワークおよびセキュリティポリシーの接続を自動化します。アクセス ポリシーの設定に応じて、ブラウンフィールド VPC/VNet で Cisco Cloud Network Controller が管理するオブジェクトは異なります。アクセス ポリシーは、テナント、VPC/VNet、サブネットなどのリソースごとに Cisco Cloud Network Controller で特権を定義するために使用されます。
アクセス ポリシーの種類は次のとおりです。
· 読み取り専用: Cisco Cloud Network Controller は、テナント、VPC/VNet、サブネットなどの既存のブラウンフィールド オブジェクトを構成またはプロビジョニングしません。既存のブラウンフィールド リソースグループのセキュリティとルーティングは、引き続きユーザーが所有することが前提です。このオプションは、リリース 25.0(4) より前は「管理対象外」と呼ばれていました。
· ルーティングのみ：Cisco Cloud Network Controller は、既存のブラウンフィールド リソース グループのルーティング設定を制御します。既存のブラウンフィールド リソースグループのセキュリティは、引き続きユーザーが所有することが前提です。
· ルーティングとセキュリティ：Cisco Cloud Network Controller は、既存のブラウンフィールド リソース グループのルーティングとセキュリティ構成の両方を制御します。このオプションは、リリース 25.0(4) 以降のデフォルトのアクセス ポリシーです。
現時点では、ブラウンフィールド インポート プロセスは Cisco Cloud Network Controller 自体で実行されます。 NDO ではまだブラウンフィールド インポートはサポートされていません。サポートされているリソースが Cisco Cloud Network Controller にインポートされると、NDO がそれらのリソースを Cisco Cloud Network Controller からインポートできます。NDO から見ると、リソースが NDO テンプレートにインポートされた後、ブラウンフィールドリソースとグリーンフィールドリソースに違いはありません。次のサブセクションでは、Microsoft Azure および AWS でブラウンフィールド インポートを実行するための高レベルの手順と固有の考慮事項について、それぞれ説明します。
Microsoft Azure でのブラウンフィールド インポート
ブラウンフィールドリソースは、グリーンフィールドリソースと同じ Azure サブスクリプションにある場合も、異なる Azure サブスクリプションにある場合もあります。ブラウンフィールドリソースが、グリーンフィールド サブスクリプションとは異なる Active Directory にある別の Azure サブスクリプションにある場合もあります。ブラウンフィールドリソースが別の Azure サブスクリプションにある場合、Cisco Cloud Network Controller は最初にブラウンフィールド Azure サブスクリプションを表す新しいテナントを作成する必要があります。
読み取り専用アクセス ポリシー（管理対象外）
「読み取り専用」アクセス ポリシーを持つブラウンフィールド VNet は、以前は管理対象外仮想ネットワークと呼ばれていました。そのため、Cisco Cloud Network Controller GUI のボタン タイトルには、リリースに応じて「管理対象外仮想ネットワーク」または「ブラウンフィールド仮想ネットワークのインポート」と表示されます。
たとえば、ブラウンフィールド VNet をインポートするには、[インテント（Intent）] ボタンから、[ワークフロー（Workflows）] セクションの [ブラウンフィールド仮想ネットワークのインポート（Import Brownfield Virtual Network）] オプションを選択できます。
ブラウンフィールド インポートの後、Cisco Cloud Network Controller は、インフラ VNet（overlay-1 VNet）からブラウンフィールド（管理対象外）VNet への VNet ピアリング要求を自動的に開始します。ブラウンフィールド VNet からインフラ VNet へのピアリングセッションを開始して VNet ピアリングセッションを完了させるのは、エンドユーザーの責任です。
サブネットベースのセレクタ EPG のみがサポートされているため、Cisco Cloud Network Controller 管理者は、ブラウンフィールド VNet のエンドポイントを表すサブネットベースのセレクタ EPG を作成する必要があります。
Cisco Cloud Network Controller は、Cisco Cloud ルータのルーティング構成を自動化して、グリーンフィールド VNet とブラウンフィールド VNet の間でトラフィックをルーティングします。グリーンフィールド EPG とブラウンフィールド EPG の間にコントラクトが適用されると、Cisco Cloud Network Controller はグリーンフィールド側で NSG ルールを自動化し、グリーンフィールド VNet ルートテーブルに UDR ルートエントリを自動的に追加します。ブラウンフィールド VNet で UDR ルートテーブルエントリを構成または編集し、NSG ルールを構成または編集して、グリーンフィールド EPG とブラウンフィールド EPG 間の適切な通信を許可するのは、エンドユーザーの責任です。
「読み取り専用」アクセス ポリシーを使用したブラウンフィールド インポートには、次のガイドラインがあります。
· ブラウンフィールド リソース グループでは、Cisco Cloud Network Controller によって実行されないものがいくつかあります。これらのポリシーをすべて作成して適用するのは、ブラウンフィールド VNet 所有者の責任です。Cisco Cloud Network Controller は、グリーンフィールド EPG とのコントラクトに基づいてインフラ NLB を指す UDR を含むルート テーブルを作成しません。Cisco Cloud Network Controller は、ブラウンフィールド リソースグループに NSG または ASG を作成しません。これらのブラウンフィールド リソースグループのエンドポイントに対して行われるエンドポイント検出はありません。ブラウンフィールド VNet に関連付けられているクラウドEPGには、サブネットベースのエンドポイントセレクタが必要です（タグベースの EPG はブラウンフィールド VNet には適用されません）。
· ブラウンフィールド VNet 内のすべての構成は、ユーザーが管理する必要があります。Cisco Cloud Network Controller は、グリーンフィールド VNet からブラウンフィールド VNet への接続のみを自動化します。ブラウンフィールド VNet は、どこにでも存在できます(たとえば、同じサブスクリプション、同じ Active Directory ドメイン内の異なるサブスクリプション、または異なる Active Directory ドメイン全体)。また、さまざまなリソースに対する読み取りアクセス許可を持つ、この管理対象外サブスクリプションに関連付けられたサービスプリンシパルも必要です。
· ブラウンフィールド VNet とグリーンフィールド VNet 間のサービスリダイレクトは、まだ正式にはサポートされていません。
ルーティングとセキュリティとルーティングのみのアクセス ポリシー
これらのオプションは、リリース 25.0(4) 以降で使用できます。
この例では、既存のブラウンフィールド "brown1" ルート テーブルに既存のブラウンフィールド VNet ピアリングを介して 10.2.2.0/24（別のブラウンフィールド VNet "brown2"）があり、ブラウンフィールド VNet "brown1" との間で使用可能な通信がまだないと仮定します。グリーンフィールド VNet。
ブラウンフィールド VNet 「brown1」をインポートし、インポートするサブネットを選択した後、Cisco Cloud Network Controller は、ブラウンフィールド VNet 「brown1」とインフラ VNet (overlay-1 VNet) の間で VNet ピアリング要求を自動的に開始し、次の図に示すように、既存の出力ルート テーブルをコピーして、brownfield VNet「brown1」を作成します。この時点で、選択されたサブネットは、Cloud Network Controller によって管理される新しく作成された出力ルート テーブルの使用を開始しますが、ネクストホップ IP アドレスはまだ IP であるため、ブラウンフィールド VNet 「brown1」内の VM は、他のブラウンフィールド VNet への接続を維持する必要があります。既存のブラウンフィールド VNet ピアリングを介してアドレスを指定します。
「brown1」VNet で EPG を作成し、グリーンフィールド EPG とのコントラクトを追加した後 (この例では、EPG 「brown1」と EPG 「green」の間のコントラクトです)、両方の VNet の出力ルート テーブルは、次に示すように、それに応じて更新されます。下の図。これは、ブラウンフィールド VNet "brown1" の VM がグリーンフィールド VNet のサブネットとブラウンフィールド VNet "brown2" のサブネットに到達できるようにするために行われます。
「ルーティングとセキュリティ」アクセス ポリシーを使用すると、ブラウンフィールド エンドポイント (この例では 10.1.1.5) は、EPG セレクターに基づいて新しく作成された EPG 「brown1」に移動し、NSG はコントラクトに基づいて Cisco Cloud Network Controller によって更新されます。 これは、EPG "brown1" のエンドポイントと EPG "green" のエンドポイント間の通信が許可されるように行われます。EPG "brown1" 内のエンドポイントと "brown2" VNet 内のエンドポイント間の通信を維持するには、"brown2" VNet をインポートし、EPG "brown1" と "brown2" VNet 内の別の EPG の間に別のコントラクトを追加する必要があります。 出力ルート「ハブの IP を介した 10.2.2.0/24」は、「インフラ VNet の NLB を介した 10.2.2.0/24」に置き換えられます。
「ルーティングのみ」アクセス ポリシーでは、Cisco Cloud Network Controller はブラウンフィールド VNet の NSG を管理しません。ブラウンフィールド VNet で NSG ルールを構成または編集し、NSG ルールを構成または編集して、グリーンフィールド EPG とブラウンフィールド EPG 間の適切な通信を許可するのは、エンドユーザーの責任です。
Microsoft Azure の「ルートとセキュリティ」および「ルーティングのみ」オプションによるブラウンフィールド インポートには、次のガイドラインがあります。
· ブラウンフィールド VNet とグリーンフィールド VNet 間のサービスリダイレクトは、「ルーティングとセキュリティ」オプションでサポートされています。
· ブラウンフィールド VNet のエンドポイントが EPG に分類されるように、ブラウンフィールド VNet をインポートする前に EPG 分類のタグを追加することをお勧めします。EPG は、ブラウンフィールド VNet のインポート中に Cisco Cloud Network Controller によってプログラムされたルーティングおよびセキュリティ構成を取得します。
詳細な手順については、以下を参照してください。
ブラウンフィールドリソースは、グリーンフィールドリソースと同じ AWS アカウントにある場合も、異なる AWS アカウントにある場合もあります。ブラウンフィールドリソースが別の AWS アカウントにある場合、Cisco Cloud Network Controller は最初に AWS アカウントを表す新しいテナントを作成する必要があります。
読み取り専用アクセス ポリシー（管理対象外）
「読み取り専用」アクセス ポリシーを持つブラウンフィールド VPC は、以前は管理対象外 VPC と呼ばれていました。そのため、Cisco Cloud Network Controller GUI のボタン タイトルは、リリースに応じて「管理対象外 VPC」または「ブラウンフィールド仮想ネットワークのインポート」です。
たとえば、ブラウンフィールド VPC をインポートするには、[インテント（Intent）] ボタンから、[ワークフロー（Workflows）] セクションの [管理対象外 VPC（Unmanaged VPC）] オプションを選択します。
ブラウンフィールド インポートの後、グリーンフィールド TGW（Cisco Cloud Network Controller によって作成された TGW）へのブラウンフィールド VPC アタッチメントを手動で作成する必要があります。
サブネットベースのセレクタ EPG のみがサポートされているため、Cisco Cloud Network Controller 管理者は、ブラウンフィールド VPC のエンドポイントを表すサブネットベースのセレクタ EPG を作成する必要があります。
グリーンフィールド EPG とブラウンフィールド EPG の間にコントラクトが適用されると、Cisco Cloud Network Controller はグリーンフィールド側で SG ルールを自動化します。Cisco Cloud Network Controller は、グリーンフィールド VPC ルートテーブルにルートエントリを自動的に追加します。ブラウンフィールド VPC で VPC ルートテーブルを構成または編集し、SG ルールを構成または編集して、グリーンフィールド EPG とブラウンフィールド EPG 間の適切な通信を許可するのは、エンドユーザーの責任です。
「読み取り専用」アクセス ポリシーを使用したブラウンフィールド インポートには、次のガイドラインがあります。
· ブラウンフィールド VPC では CIDR のすべてまたは特定のセットを選択的にインポートできますが、プライマリ CIDR がなければブラウンフィールド VPC をインポートすることはできません。ブラウンフィールド VPC をインポートする場合、プライマリ CIDR のインポートは必須です。
· グリーンフィールド展開の場合、Cisco Cloud Network Controller は、TGW、TGW ルート テーブル、グリーンフィールド VPC とグリーンフィールド TGW（Cisco Cloud Network Controller 管理の TGW）間の TGW 接続などの構成を引き続き自動化します。Cisco Cloud Network Controller は、ブラウンフィールド VPC の TGW アタッチメントを構成しません。ブラウンフィールド VPC からグリーンフィールド TGW への TGW アタッチメントは手動で構成する必要があります。
· Cisco Cloud Network Controller は、グリーンフィールド VPC のセキュリティ グループ ルールをプログラムして、ブラウンフィールド VPC との間のインバウンドおよびアウトバウンドトラフィックを許可します。Cisco Cloud Network Controller は、ブラウンフィールド VPC のセキュリティ グループ ルールをプログラミングしません。
· Cisco Cloud Network Controller は、 ブラウンフィールド VPC のルートテーブルまたはルートをプログラミングしません。ブラウンフィールド VPC がグリーンフィールド VPC と通信するには、次の構成を手動で行う必要があります。
o グリーンフィールドとブラウンフィールドの EPG 間のコントラクトを作成します。
o インフラ VPC 内のグリーンフィールド TGW を使用して、トランジットゲートウェイ VPC アタッチメントを作成します。
o ブラウンフィールド VPC とサブネットのルートテーブルを作成または編集します。
o 接続先がグリーンフィールド CIDR であり、ネクストホップがグリーンフィールド TGW VPC アタッチメントであるルートを追加します。
· ブラウンフィールド VNPC に関連付けられているクラウドEPGには、サブネットベースのエンドポイントセレクタが必要です（タグベースの EPG はブラウンフィールド VNet には適用されません）。
ルーティングとセキュリティとルーティングのみのアクセス ポリシー
これらのオプションは、リリース 25.0(4) 以降で使用できます。
この例では、既存のブラウンフィールド「brown1」ルートテーブルに既存の TGW を介して 10.2.2.0/24（別のブラウンフィールド VPC 「brown2」）があり、ブラウンフィールド VPC Brown1 とグリーンフィールド VPC の間にはまだ通信がないと仮定します。
ブラウンフィールド VPC「brown1」をインポートし、インポートするサブネットを選択した後、Cisco Cloud Network Controller は、クラウド ネットワーク コントローラーによって管理されるグリーンフィールド TGW に向かってブラウンフィールド VNet 「brown1」の TGW アタッチメントを自動的に構成し、次の図に示すように、既存の出力ルート テーブルをコピーして、ブラウンフィールド VPC 「brown1」の出力ルート テーブルを作成します。この時点で、選択したサブネットは Cisco Cloud Network Controller によって管理される新しく作成された出力ルート テーブルの使用を開始しますが、ブラウンフィールド VPC 「brown1」内の VM は、ブラウンフィールド TGW が引き続きターゲットであるため、他のブラウンフィールド VNet への接続を維持する必要があります。
「brown1」VPC で EPG を作成し、グリーンフィールド EPG とのコントラクトを追加した後 (この例では、EPG 「brown1」と EPG 「green」の間のコントラクトです)、両方の VPC の出力ルート テーブルは、下の図に示すように、それに応じて更新されます。これは、ブラウンフィールド VPC 「brown1」の VM がグリーンフィールド VPC のサブネットとブラウンフィールド VPC 「brown2」のサブネットに到達できるようにするために行われます。
「ルーティングとセキュリティ」アクセス ポリシーを使用すると、ブラウンフィールド エンドポイント (この例では 10.1.1.5) は、EPG セレクタに基づいて新しく作成された EPG 「brown1」に移動し、セキュリティ グループ ルールはコントラクト ベースの Cisco Cloud Network Controller で更新されます。これは、EPG "brown1" のエンドポイントと EPG "green" のエンドポイント間の通信が許可されるように行われます。EPG「brown1」のエンドポイントと「brown2」VPC のエンドポイント間の通信を維持するには、「brown2」VPC をインポートして、EPG「brown1」と別の EPG のbrown2 VPC の間に別のコントラクトを追加する必要があります。出力ルート「ブラウンフィールド TGW 経由の 10.2.2.0/24」は、「グリーンフィールド TGW 経由の 10.2.2.0/24」に置き換えられます。
「ルーティングのみ」アクセス ポリシーでは、Cisco Cloud Network Controller はブラウンフィールド VPC のセキュリティ グループ ルールを管理しません。ブラウンフィールド VPC のセキュリティ グループを構成または編集し、NSG ルールを構成または編集して、グリーンフィールド EPG とブラウンフィールド EPG 間の適切な通信を許可するのは、エンドユーザーの責任です。
AWS の [ルーティングとセキュリティ] および [ルーティングのみ] オプションを使用したブラウンフィールド インポートには、次のガイドラインがあります。
· ブラウンフィールド VPC のエンドポイントが EPG に分類されるように、ブラウンフィールド VPC をインポートする前に EPG 分類のタグを追加することをお勧めします。EPG は、ブラウンフィールド VPC インポート中に Cisco Cloud Network Controller によってプログラムされたルーティングおよびセキュリティ設定を取得します。
ユース ケース #12：災害復旧（DR）のためのワークロード モビリティ
重要なアプリケーションのワークロードは、クラウド ネイティブのロード バランサーまたはサードパーティのロード バランサーによって負荷分散される複数のアベイラビリティ ゾーンとリージョンに分散されることになっています。
他のネットワーク コンポーネントを介してピアリングまたは接続されている場合、VPC 間で IP 範囲が重複しないという一般的な前提がありますが、このセクションでは、スタンバイ VM インスタンスがプライマリ VM インスタンスの VPC と同じ IP 範囲を使用する DR ユース ケースの例について説明します。このユースケースの利点は、プライマリ VPC から別のリージョンのセカンダリ VPC へのスイッチオーバー中に IP アドレスを再割り当てする必要がないことです。
このセクションの例では、AWS サイト内のプライマリ/セカンダリ VPC スイッチオーバーについて説明していますが、Microsoft Azure サイトにも適用できるはずです。Cisco Cloud Network Controller リリース 25.1(1) の時点では、GCP サイトには適用されません。
次の図は、プライマリおよびセカンダリ VPC の設計例を示しています。重要な前提は、プライマリ VPC が Cisco Cloud Network Controller および NDO を介して作成され、セカンダリ VPC がプライマリ VPC と同じ IP プレフィックスを使用して Cisco Cloud Network Controller の外部で作成されたことです。スイッチオーバー中に、セカンダリ VPC が Cisco Cloud Network Controller にインポートされ、Cisco Cloud Network Controller がセカンダリ VPC のネットワークとセキュリティ構成の移行を自動化します。
この例では、プライマリ VPC は us-east-2 リージョンにあり、セカンダリ VPC は us-west-2 リージョンにあります。プライマリ VPC が起動すると、us-east1 リージョンの VM1 は、Cisco Cloud Network Controller によって管理される TGW を介して、us-east-2 リージョンの VM2 と通信できます。
設計上の重要な考慮事項は次のとおりです。
· VM インスタンスは、プライマリ VPC と同じ IP プレフィックスを使用してセカンダリ VPC に展開されます。この例では、セカンダリ VPC の VM インスタンスはプライマリ VPC の VM インスタンスと同じ IP アドレスを使用することさえあります。これは、アプリケーション内で DNS ではなく IP アドレスが使用されている場合に役立つ可能性があります。この例では、VM2 と VM3 が同じ IP アドレスを使用しています。
· セカンダリ VPC の VM インスタンスは、プライマリ VPC の VM インスタンスと同じタグを使用します。これは、スイッチオーバー後に、同じセキュリティ設定がセカンダリ VPC の VM インスタンスに適用されるようにするためです。この例では、VM2 と VM3 が同じタグを使用しています。
· セカンダリ VPC は、スイッチオーバーの前に TGW に接続されません。つまり、セカンダリ VPC の VM インスタンスは、実際にアプリケーションを提供するために使用されません。
このセクションでは、重大な障害が発生し、アプリケーション層をプライマリ VPC からセカンダリ VPC にスイッチオーバーの決定が行われた場合に、セカンダリ VPC への接続を有効にするワークフローについて説明します。
スイッチオーバーのワークフローの例は次のとおりです。
1. Cisco Cloud Network Controller の場合：プライマリ VPC（VRF）のクラウド コンテキスト プロファイルを削除します。そうしないと、サブネット（この例では 192.168.2.0/24）宛てのトラフィックは引き続きプライマリ VPC に転送される可能性があります。これは、プライマリ VPC の VM2 とそのサブネットがまだアクティブである可能性があるためです。
2. Cisco Cloud Network Controller の場合：「ルーティングとセキュリティ」アクセス ポリシーでブラウンフィールド インポートを使用して、セカンダリ VPC を同じ VRF にインポートします。
注: クラウド コンテキスト プロファイルがステップ 1 で削除されたため、新しいクラウド コンテキスト プロファイルが作成され、セカンダリ VPC に関連付けられますが、EPG と関連付けられたコントラクトはまだテナント設定にあります。これは、セカンダリ VPC の次の設定が、プライマリ VPC の設定と同等である EPG およびコントラクト構成に基づいて自動的に実行されることを意味します。
· セカンダリ VPC が存在するリージョンでの TGW の展開
· リージョン間ピアリングや TGW アタッチメントなどの TGW 構成
· セカンダリ VPC のルート テーブル
· セカンダリ VPC の EPG のセキュリティ グループ（この例では EPG2）
3. （オプション）NDO を使用してプライマリ VPC（この例では VPC1）のテナント構成を管理する場合、新しくインポートされたセカンダリ VPC（この例では VPC2）情報を Cisco Cloud Network Controller から NDO に同期する必要があります。
NDO 上: テナント構成の管理に使用されるテンプレートで、ステップ 2 で作成された VRF（例では VRF-2 を使用）を Cisco Cloud Network Controller からインポートします。これにより、古いプライマリ VPC リージョン情報が NDO のセカンダリ VPC リージョン情報に置き換えられます。
4. （オプション）後でプライマリ VPC に切り替える場合は、Cisco Cloud Network Controller で、クラウド コンテキスト プロファイルを削除し、新しいクラウド コンテキスト プロファイルを作成して、ステップ 1 と 2 と同様にプライマリ VPC をインポートします。NDO が使用されている場合は、手順 3 と同様に、VRF を Cisco Cloud Network Controller から NDO にインポートして戻します。
5. （ステップ 4 の後のオプション）プライマリ VPC からセカンダリ VPC へのスイッチオーバーを再度実行する場合は、AWS のセカンダリ VPC のタグを削除します。タグは、ステップ 2 のブラウンフィールド インポート中に Cisco Cloud Network Controller によって追加されました。そうしないと、セカンダリ VPC のブラウンフィールド インポートを再度実行することはできません。これらのタグが VPC に存在する場合、Cisco Cloud Network Controller はブラウンフィールド インポート用の VPC を識別しないためです。
このユース ケースには、次の考慮事項があります。
· このシナリオは、「ルーティングとセキュリティ」アクセス ポリシーを使用したブラウンフィールド インポートがサポートされている場合、クラウド サイトに適用できます。「ルーティングのみ」アクセス ポリシーの場合、セキュリティ構成は自動的に更新されませんが、ルーティング構成は上記の手順 2 で引き続き自動的に更新されます。
· これは、重大な障害が発生した場合に使用することを目的とした DR ユース ケース用です。必要な構成更新の量に応じて、スイッチオーバー後の収束に 5 ～ 10 分以上かかる場合があります。
· スイッチオーバー後にアプリケーションを提供できるように、セカンダリ VPC で実行されているアプリまたは VM インスタンスを適宜設定および更新する必要があります。
· セカンダリ VPC は、同じクラウド サイトにあっても、別のクラウド サイトにあってもかまいません。セカンダリ VPC（または Microsoft Azure サイトの場合は VNet）が別のクラウド サイトにある場合、サイト間接続を確立するために、クラウド サイトの Cisco Cloud Networking Controller からセカンダリ VPC/VNet をインポートするために NDO が必要です。
ユースケース #13: AWS GWLB（ゲートウェイ ロード バランサー）によるファイアウォールの冗長性
このセクションでは、AWS Gateway Load Balancer（GWLB）を使用した次のサードパーティ ファイアウォール挿入のユース ケースについて説明します。
· インターネットとクラウド サイトの VM インスタンス間の垂直方向のトラフィック フロー
· 異なる VPC 内の VM インスタンス間の水平方向のトラフィック フロー
· グリーンフィールド VPC とブラウンフィールド VPC 間の水平方向のトラフィック フロー
AWS GWLB は、クラウド内のファイアウォール、侵入防御システム（IPS）、ディープ パケット インスペクション（DPI）システムなどのサードパーティ アプライアンスの可用性を、簡単かつ費用対効果の高い方法で展開、スケーリング、および管理できるようにするサービスです。
以下の図に例を示します。VPC1 は VM インスタンス用で、Service-VPC はファイアウォールと GWLB 用です。次の項目は、この例の主要なコンポーネントです。
1. 各サードパーティのファイアウォールには、トラフィック転送用の 1 つのインターフェイスと 1 つの管理インターフェイスがあります。ファイアウォール インターフェイスは、Service-VPC のサブネット (または複数のサブネット) にあります。ファイアウォールは必ずしもクラスタ化する必要はありません。
· トラフィック転送用のインターフェイスは、プライベート サブネット「FW-data」にあります。
· 管理インターフェイスは、プライベート サブネット「FW-mgmt」にあります。パブリック サブネット「FW-JumpHost」内のインスタンスは、FW 管理インターフェイスへのアクセスに使用されます。
2. この例では、パブリック サブネット「App1-data」および「App2-data」内の VM インスタンスが、ファイアウォールを通過する垂直方向および水平方向のトラフィック フローの説明で使用されます。
· VM インスタンス コンソールへのアクセスには、パブリック サブネット「JumpHost」内のインスタンスが使用されます。
3. プライベート サブネット「GWLB」内の GWLB には、ファイアウォールに関連付けられたターゲット グループがあります。
4. Geneve カプセル化は、GWLB とファイアウォールの間で使用されます。ファイアウォールは Geneve カプセル化をサポートする必要があります。
5. プライベートサブネット「GWLB」内の GWLB VPC エンドポイント サービスは、Service-VPC 内の GWLB 上に作成されます。
6. パブリックサブネット「GWLBe」内の GWLB エンドポイント（GWLBe）は、GWLB VPC エンドポイント サービスに関連付けられています。これは、GWLBe から GWLB への AWS プライベート リンクです。
このユース ケースには、次の考慮事項があります。
· このシナリオは、AWS を使用するクラウド サイトに適用できます。
· この例では AWS TGW を使用していませんが、GWLB を使用したファイアウォール挿入設計を AWS TGW で使用できます。トラフィックがアベイラビリティ ゾーンにまたがる場合、同じ仮想アプライアンスを使用するには、TGW でアプライアンス モードを有効にする必要があります。詳細については、AWS Transit Gateway のドキュメントを参照してください。
· ファイアウォールは Geneve カプセル化をサポートする必要があります。
· ファイアウォールと GWLB は、VM インスタンスとは別の VPC にある必要があります。
· ファイアウォールと GWLB は、VM インスタンスと同じリージョンにある必要があります。
· GWLB と GWLB エンドポイントは、同じ可用性ゾーンにある必要があります。
· クラウド サイトのファイアウォールはアクティブ/スタンバイまたはクラスタリング機能を一般的にサポートしていないため、AWS ターゲット グループでスティッキー セッションを有効にする必要があります。
· Cisco Cloud Network Controller は現在、AWS GWLB を使用したネットワークおよびセキュリティ構成の自動化をサポートしていないため、VM インスタンスとファイアウォール（この例では VPC1 および Service-VPC）の VPC およびカスタム出力ルートは、Cisco Cloud Network Controller の外部で適宜構成する必要があります。「読み取り専用」アクセス ポリシーを使用して、VPC を Cisco Cloud Network Controller にインポートできます。詳細はサブセクションを参照してください。
VPC の各サブネットは、トラフィック パスにファイアウォールを挿入するように設定する必要があります。次の図は、出力ルート テーブルの構成例を示しています。
サードパーティのアプライアンスには、通常、トラフィック検査用のインターフェイスに加えて管理インターフェイスがありますが、このセクションでは主にトラフィック検査用のネットワークに焦点を当てています。以下の例には、管理に使用されるサブネットも含まれています。
Service-VPC のサブネットは次のとおりです。
· VM インスタンスがファイアウォール管理インターフェイスにアクセスするために使用される「FW-JumpHost」サブネット。次の出力ルートがあります。
o ローカル サブネット（CIDR）としての 192.168.0.0/16
o インターネットへのアクセスに使用されるインターネット ゲートウェイ経由で 0.0.0.0/0
· 「GWLB」、「FW-data」、および「FW-mgmt」サブネット。次の出力ルートがあります。
o ローカルサブネット（CIDR）としての 192.168.0.0/16
VPC1 のサブネットは次のとおりです。
· 「JumpHost」および「GWLBe」サブネット。次の出力ルートがあります。
o ローカルサブネット (CIDR) としての 10.0.0.0/16
o インターネットへのアクセスに使用されるインターネット ゲートウェイ経由で 0.0.0.0/0
· 「App1-data」サブネット。次の出力ルートがあります。
o ローカルサブネット（CIDR）としての 10.0.0.0/16
o VPC エンドポイント（以下の図の GWLBe、または VPC-ep-id）経由の 0.0.0.0/0。ファイアウォールを介して「App2-data」サブネット内のインターネットおよび VM インスタンスにアクセスするために使用
· App2-data」サブネットには、次の出力ルートがあります。
o ローカル サブネット（CIDR）としての 10.0.0.0/16
o ファイアウォール経由で「App1-data」サブネット内の VM インスタンスにアクセスするために使用される VPC エンドポイント（下図の VPC-ep-id）経由で 10.0.11.0/24
· VPC1 の IGW には、次の入力ルートがあります。
o ローカルサブネット（CIDR）としての 10.0.0.0/16
o ファイアウォール経由で「App1-data」サブネット内の VM インスタンスにアクセスするために使用される VPC エンドポイント（下図の VPC-ep-id）経由で 10.0.11.0/24
インターネットとクラウド サイトの VM インスタンス間の垂直方向トラフィック フロー
次の図は、インターネットからクラウド サイトの VM インスタンスへのトラフィック フローを示しています。この例では、宛先 IP アドレスは 10.0.11.0/24 サブネットにあります。
1. インターネットから「App1-data」サブネットへのトラフィックは、IGW イングレス ルート テーブル（この例では VPC-ep-id 経由で 10.0.11.0/24）に基づいて GWLBe に転送されます。
2. トラフィックは、AWS Private Link 経由で Service-VPC 上の GWLB に転送されます。
3. GWLB は、Geneve カプセル化を使用して、ファイアウォールの 1 つにトラフィックを転送します。
4. ファイアウォールはトラフィックにセキュリティ ポリシーを適用し、Geneve カプセル化を使用してトラフィックを GWLB に送り返します。
5. GWLB は、AWS プライベート リンクを介してトラフィックを GWLBe に送り返します。
6. GWLBe サブネットには、宛先サブネット（この例では 10.0.0.0/16）へのローカル ルートがあります。したがって、トラフィックは宛先に転送されます。
次の図は、VM インスタンスからインターネットへのリターン トラフィックを示しています。
7. VM インスタンスから外部サブネットへのトラフィックは、出力ルート テーブル（この例では VPC-ep-id 経由で 0.0.0.0/0）に基づいて GWLBe に転送されます。
8. トラフィックは、AWS Private Link 経由で Service-VPC 上の GWLB に転送されます。
9. GWLB は、Geneve カプセル化を使用してトラフィックを同じファイアウォールに転送します。これは、ファイアウォールに関連付けられたターゲット グループでセッション スティッキネスが有効になっているためです。
10. ファイアウォールはトラフィックにセキュリティ ポリシーを適用し、Geneve カプセル化を使用してトラフィックを GWLB に送り返します。
11. GWLB は、AWS プライベート リンクを介してトラフィックを GWLBe に送り返します。
12. GWLBe サブネットには、インターネットのデフォルト ルートがあります（IGW 経由で 0.0.0.0/0）。したがって、トラフィックは宛先に転送されます。
異なる VPC 内の VM インスタンス間の水平方向のトラフィック フロー
以下の図は、異なる VPC 内の VM インスタンス間のトラフィック フローを示しています。10.0.11.0/24 サブネットから 10.0.12.0/24 へのトラフィックは、「App1-data」サブネットの出力ルート テーブルに基づいて GWLB エンドポイントに転送されます。
10.0.12.0/24 サブネットから 10.0.11.0/24 へのトラフィックは、「App2-data」サブネットの出力ルート テーブルに基づいて GWLB エンドポイントに転送されます。
NDO および Cisco Cloud Network Controller との統合
このセクションの前の 2 つのトラフィック フローの例では、Cisco Cloud Network Controller によって管理されていない VPC を使用しています。また、「読み取り専用」アクセス ポリシーを使用して VPC を Cisco Cloud Network Controller にインポートすることもできます。これにより、Cisco Cloud Network Controller によって管理される VPC から「読み取り専用」へのネットワーク接続の構成を自動化できます。サイト内の VPC（ただし、「読み取り専用」VPC 内の構成は、Cisco Cloud Network Controller の外部で適切に行う必要があります）。クラウド サイトを NDO に追加することで、その利点はサイト間通信にも適用されます。
下の図は、シナリオの例を示しています。左側のインフラ VPC と VPC2 は Cisco Cloud Network Controller によって管理されますが、VPC1 と Service-VPC は Cisco Cloud Network Controller によって完全には管理されませんが、「読み取り専用」アクセス ポリシーでインポートされます。
VPC を Cisco Cloud Network Controller にインポートするには、次の考慮事項があります。
· Cisco Cloud Network Controller は現在、AWS GWLB を使用したネットワークおよびセキュリティ構成の自動化をサポートしていないため、アクセス ポリシーは「読み取り専用」である必要があります。つまり、VPC1 および Service-VPC のネットワークおよびセキュリティ構成は Cisco Cloud Network Controller によって管理されません。Cisco Cloud Network Controller は、他の VPC のネットワークとセキュリティの構成を引き続き自動化します。
· 「読み取り専用」アクセス ポリシーを使用してブラウンフィールド VPC をインポートすることにより、Cisco Cloud Network Controller は、グリーンフィールド VPC のネットワークとセキュリティ構成を自動化し、インポートされたブラウンフィールド VPC のネットワークに到達できます。この例では、グリーンフィールド VPC と Service-VPC の間に直接通信がないため、Service-VPC をインポートする必要はありません。詳細については、次のサブセクションのルート テーブルの説明を参照してください。
· GWLB の VPC（この例では Service-VPC）を Cisco Cloud Network Controller にインポートする必要はありません。
· ブラウンフィールド VPC（この例では VPC1）には、VPC を TGW にアタッチするために、アベイラビリティ ゾーンごとに追加のサブネットが必要です。VPC が TGW にアタッチされている場合、各アベイラビリティ ゾーンから 1 つのサブネットが必要です。この例では、「TGW-attach」、「GWLBe」、および「App1-data」サブネットが同じアベイラビリティーゾーンにあることが前提となっています。
· VPC1 を Cisco Cloud Network Controller にインポートするときは、TGW VPC アタッチメントごとに個別の TGW ゲートウェイ サブネットを使用して、異なるネットワーク ACL セットを適用できるようにすることをお勧めします。たとえば、VPC1 から VPC3 への別の TGW VPC アタッチメントがある場合は、10.0.20.16/28 などの別のゲートウェイ サブネットを作成することをお勧めします。詳細については、「トランジット ゲートウェイ設計のベスト プラクティス」を参照してください。
· Cisco Cloud Network Controller によって管理されるインフラ VPC の TGW でアプライアンス モードを有効にする必要はありません。アベイラビリティ ゾーン間のトラフィック フローに別の TGW がある場合、同じ仮想アプライアンスを使用するには、TGW でアプライアンス モードを有効にする必要があります。詳細については、「AWS Transit Gateway のドキュメント」を参照してください。
グリーンフィールド VPC とブラウンフィールド VPC 間の水平方向のトラフィック フロー
このサブセクションでは、グリーンフィールド VPC と呼ばれる Cisco Cloud Network Controller によって管理される VPC 内の VM インスタンスから、ブラウンフィールド VPC と呼ばれる Cisco Cloud Network Controller によって管理されない VM インスタンスへのトラフィック フローについて説明します。
前の例と同様に、VPC の各サブネットは、トラフィック パスにファイアウォールを挿入するように構成する必要があります。次の図は、出力ルート テーブルの構成例を示しています。
前の例に加えて、ブラウンフィールド VPC1 には、次の追加のサブネットと出力ルート テーブルがあります。
· 「TGW 接続」サブネットには、次の出力ルートがあります。
o ローカルサブネット（CIDR）としての 10.0.0.0/16
o ファイアウォールを介して「App1-data」サブネット内の VM インスタンスにアクセスするために使用される VPC エンドポイント（下図の VPC-ep-id）経由で 10.0.11.0/24。
· 「GWLBe」および「App1-data」サブネットには、追加の出力ルートがあります。
o 172.16.0.0/24（グリーンフィールド VPC 「VPC2」の「App3-data」サブネット）は、ファイアウォールを介してグリーンフィールド VPC にアクセスするために使用される VPC エンドポイント（下の図の VPC-ep-id）を経由します。
グリーンフィールド VPC 「VPC2」には、次のサブネットがあります。
· 「App3-data」サブネットには、次の出力ルートがあります。
o ローカル サブネット（CIDR）としての 172.16.0.0/16
o TGW を介した 10.0.11.0/24。ファイアウォールを介して「App1-data」サブネット内の VM インスタンスにアクセスするために使用されます。
VPC1 は、「読み取り専用」アクセス ポリシーで Cisco Cloud Network Controller にインポートされたブラウンフィールド VPC であるため、VPC1 の出力ルートは Cisco Cloud Network Controller の外部で構成する必要があることに注意してください。一方、VPC2 の出力ルートは、 VPC2 がグリーンフィールド VPC であるため、クラウド ネットワーク コントローラー Cisco によって自動的に構成されます。この例では、VPC2 から Service-VPC のサブネットへの直接通信がないため、Service-VPC をインポートする必要はありません。
次の図は、グリーンフィールド VPC 「VPC2」の VM インスタンスからブラウンフィールド VPC 「VPC1」の VM インスタンスへのトラフィック フローを示しています。
1. VPC2 の VM インスタンスからのトラフィックは、Cisco Cloud Network Controller によって管理されるインフラ VPC の TGW を介して到着します。
2. トラフィックは、ゲートウェイ サブネット（この例では VPC-ep-id を介して 10.0.11.0/24）のルート テーブルに基づいて GWLBe に転送されます。
3. トラフィックは、AWS Private Link を介して Service-VPC 上の GWLB に転送されます。
4. GWLB は、Geneve カプセル化を使用して、ファイアウォールの 1 つにトラフィックを転送します。
5. ファイアウォールはトラフィックにセキュリティ ポリシーを適用し、Geneve カプセル化を使用してトラフィックを GWLB に送り返します。
6. GWLB は、AWS プライベート リンクを介してトラフィックを GWLBe に送り返します。
7. GWLBe サブネットには、宛先サブネット（この例では 10.0.0.0/16）へのローカル ルートがあります。したがって、トラフィックは接続先に転送されます。
次の図は、ブラウンフィールド VPC 「VPC1」の VM インスタンスからグリーンフィールド VPC 「VPC2」の VM インスタンスへのリターン トラフィック フローを示しています。
8. VPC1 のVM インスタンスからのトラフィックは、出力ルート テーブル（この例では VPC-ep-id 経由で 0.0.0.0/0）に基づいて GWLBe に転送されます。
9. トラフィックは、AWS Private Link を介して Service-VPC 上の GWLB に転送されます。
10. GWLB は、Geneve カプセル化を使用して、同じファイアウォールの 1 つにトラフィックを転送します。これは、ファイアウォールに関連付けられたターゲット グループでセッション スティッキネスが有効になっているためです。
11. ファイアウォールはトラフィックにセキュリティ ポリシーを適用し、Geneve カプセル化を使用してトラフィックを GWLB に送り返します。
12. GWLB は、AWS プライベート リンクを介してトラフィックを GWLBe に送り返します。
13. GWLBe サブネットには、インフラ VPC の TGW を介した VPC2（この例では 172.16.0.0/24）へのルートがあります。したがって、トラフィックはインフラ VPC の TGW 経由で接続先に転送されます。
詳細な手順については、以下を参照してください。
詳細については、以下を参照してください。