通信サービスプロバイダのデータセンターを Amazon VPC に相互接続するデザインパターン

従来から、通信サービスプロバイダ (CSP) は Virtual Routing and Forwarding (VRF) 技術を使用して、データセンター (DC) ネットワークをネットワークドメインごとに分離しています。例えば、運用管理 (OAM)、シグナリング、ローミング、ユーザートラフィックネットワークなどのドメインなどです。また、データセンターの各 VRF ドメインを他のデータセンターと同等の VRF に接続して、ネットワークを地域的および全国的にカバーする必要があります。さらに、CSP がエンドカスタマーに提供するサービスでは、CSP がマルチ VRF ベースのネットワークをネットワーク分離したまま、外部のプライベートネットワークに拡張する必要があることもよくあります。従って、DC 間接続と通信ネットワーク拡張の両方で、ネットワーク分離（VRF）を維持し、複数の自律システム（AS）サポートを相互接続するための特定の要件が生じます。一般的な解決策として、RFC4364 ではこの要件に対応する 2 つのオプションが導入されています。オプションA は、RFC 4364 の VRF to VRF 接続により、ネットワーク間相互接続（NNI）の両側のルーティングコンテキストが 1:1 で調整されることを意味します。また、オプションB は、NNI のラベルスイッチングパラダイムに基づくマルチプロトコルラベルスイッチング（MPLS）AS 間接続を、グローバル QoS ポリシー、強化スキーム、および単一のMP-eBGPセッションを備えた単一の MPLS 対応論理インターフェイスで使用します。AWS で実行されているアプリケーションを、既存のマルチ VRF で分離されたネットワーク上のワークロードに相互接続する場合、この要件とソリューションを実装する必要があります。最初で最も簡単な方法として、RFC4364 オプションAの方法で、アプリケーションを個別の Amazon Virtual Private Cloud（Amazon VPC）に分離し、各 VRF にマッピングすることを考えることができます。これは次の図1に示すように、オンプレミスの VRF と AWS 上にマップされた VPC の間に個別の AWS Site to Site (S2S) VPN または AWS Direct Connect (DX) で接続することにより実現します。

図1 VRF から VPC への相互接続 (RFC4364 オプション A)

これはうまく機能し分かり易いですが、ネットワークアプリケーションをそれぞれの VPC に分離できる場合にのみ機能します。ただし、仮想ネットワーク機能（VNF）やコンテナネットワーク機能（CNF）などの通信ネットワークアプリケーション/アプライアンスのほとんどの場合、特定のアプライアンス（EPC（evolved packet core）や 5GC（5G Core）等）では、複数のネットワークドメインを1つの VPC 内に限定する必要があります（OAM VRF、シグナリングネットワーク VRF、ユーザープレーン VRF、ローミングインターフェイス VRF 等）。これにより通常、ネットワーク分離の要件を維持したまま通信サービスプロバイダのネットワークと AWS 間のネットワーク拡張を実装しようとすると、複雑さとコストが増えます。そのため、特に AWS 上の通信アプリケーションに 1 つの VPC アーキテクチャを使用する場合は、ベストプラクティスを検討することが合理的です。

図 2 VRF から単一 VPC への相互接続

この記事では、AWS と複数の VRF で分離された CSP ネットワーク間にハイブリッドネットワークを構築するための 5 つの実行可能なデザインパターンを紹介します。1) Customer Gateweay (CGW) のルートフィルター オプション設定によるパターン、2) AWS Transit Gateway (Transit Gateway) ルートテーブルの分離によるパターン、3) Transit Gateway ルートテーブルの分離と Transit Gateway Connect によるパターン、4) VPC 内の仮想ルータアプライアンスによるパターン、及び 5) Multi-VPC ENI Attachments 機能を使用したパターン、の5つです。パターン 1 ～ 3 及び 5 では、オンプレミス側プロバイダエッジ (PE) ルーターまたは Transit Gateway の各側で微調整された構成を持つネイティブ AWS ネットワーキング構造を使用します。一方パターン 4 では、RFC4363 オプション B 構成を実装するために、VPC 内に仮想ルータアプライアンスが必要になります。これら 5 つのパターン以外にも他のオプションが存在する可能性がありますが、これらを一般的なアプローチとして、また AWS の VPC アーキテクチャと既存の VRF 分離ネットワークの両方への影響を最小限に抑えるベストプラクティスとして紹介します。

パターン 1 – CGW（プロバイダエッジ（PE）ルータ）でルートマップ IN フィルタを使用して VRF を単一の VPC に接続する

最初のデザインパターンは、最もシンプルな AWS ネットワーク構成方法で、VRF ごとに個別 Site to Site (S2S) 仮想プライベートネットワーク (VPN) または Direct Connect (DX) 仮想インターフェイス (VIF) を利用し、PE ルータ側に特定の構成を行います。前の章で説明したように、1つの VPC が AWS ネットワークの 1つのルーティングドメインになります。したがって、S2S VPN または DX を介して VRF 分離が存在するオンプレミスネットワークに Amazon VPC を接続すると、すべての VPC CIDR 範囲が接続されているすべてのピア VRF に広報されます。この際、各 VRF ルータ（VPC への各 S2S 接続の CGW としても見られます）のルートポリシーマップは、各 VRF 向け他 Amazon VPC サブネットからの干渉を受けないように実装されることができます。このインバウンドルートポリシーは、Amazon VPC 内の Amazon Virtual Private Gateway (VGW) との BGP 関連付けを介した現在の VRF とは関係のない、広報されたサブネットをフィルタで除外するために、適用される必要があります。つまり、このパターンでは、オンプレミス VRF ルータ側での事前設定が必要ですが、各 VRF 対応にマッピングする事前定義された Amazon VPC サブネットに関する情報も必要になります。このプライベートネットワーク側の構成に加えて、インスタンスとサブネットインターフェイスでセキュリティグループとアクセス コントロールリスト (ACL) を使用して、セキュリティ及び分離の適切な境界を設定する必要もあります。これにより、VPC 内でのネットワーク分離を実装可能とします。

図3 デザインパターン1; PE ルータでルートフィルタを使用する

図 3 の VRF1 ルータの場合、VPC が VPC CIDR 10.0.0.0/16 範囲全体を広報している一方で、VRF-1 サブネットが VPC で 10.0.10.0/24 として事前に設定されている場合に、ルートマップフィルタ設定例を次のように記載できます。S2S VPN または DX 接続を介して広報された複数の VPC CIDR 範囲を受信してフィルタリングするには、広報するプレフィックスごとに新しいセカンダリ VPC CIDR を設定し、その CIDR から VPC サブネットを作成する必要があることに留意ください。DXと S2S VPN は、プライマリ VPC CIDR だけでなく、セカンダリ VPC CIDR ごとに1つの VPC CIDR プレフィックスを広報します。これにより、オンプレミスの CIDR に基づいてフィルタリングできます。

router bgp 65001
network 169.254.205.58
neighbor 169.254.205.57 remote-as 64512
neighbor 169.254.205.57 route-map SET-LOCAL-PREF in
!
route-map SET-LOCAL-PREF permit 10
match ip address 2
set local-preference 120
!
route-map SET-LOCAL-PREF permit 20
!
access-list 2 permit 10.0.10.0 0.0.0.255
access-list 2 deny any

パターン2 – Transit Gateway ルートテーブル分離を使用する

マルチ VRF 用の個別の S2S VPN または DX VIF がある（つまり、各 S2S VPN または VIF が各 VRF に個別にある）場合は、それらを使用して各 VRF を単一の VPC に接続できます。この環境では、AWS Transit Gateway (TGW)と Transit Gateway ルートテーブルを使用して、VPC CIDR のルート伝播を各 VRF に分けることができます。このアプローチ（および次のパターン3）で覚えておくべく留意点の1つは、Transit Gateway はデータトラフィックの料金がかかるため、大量のトラフィックを処理する必要がある通信サービスプロバイダの 4G/5G コアネットワークのユースケースにてユーザートラフィックの伝送には、最適なオプションとはならない可能性がある点です。次の図4に示すように、このデザインパターンの重要な考え方は、VRF 側への Amazon VPC の伝播を無効にし、代わりに各 VRF 専用ルートテーブルで静的ルートを定義して、VPC CIDR 範囲内の対応するサブネットのみを含むようにすることです。次の図例では、結果として、PE ルータの VRF1 側は Transit Gateway 側の BGP 広報から Private-VRF1 サブネット範囲のみを受信し、VRF2 側では Private-VRF2 サブネット範囲のみを参照します。前のデザインパターンと同様に、VPC 内のネットワーク分離は、各サブネットレベルとインスタンスレベルで NACL とセキュリティグループを介して実装する必要があります。

図4 デザインパターン2; TGW ルートテーブル分離を使用する

パターン3 – 単一の DX Transit VIF を介して Transit Gateway Connect を使用する

前のパターンと似ていますが、DX 接続が1つだけ存在する場合は、Transit Gateway Connect 機能がより効果的です。Transit Gateway Connect は、単一の DX Transit VIF を介して複数の AS 及び複数の VRF ネットワークを AWS に相互接続する方法を提供します。これにより、Generic Routing Encapsulation (GRE) と Border Gateway Protocol (BGP) を使用したオンプレミスデータセンタと AWS ドメイン間の物理ネットワーク接続を簡素化できます。

図5 デザインパターン3; TGW Connect と TGW ルート テーブルの分離を使用する

上の図は、複数の VRF を使用した複数の Transit Gateway attachment タイプ Connect の実装を示しています。Direct Connect Gateway（DX-GW）はTransit VIF で構成され、Transit Gateway の CIDR 範囲を広報します。DX-GW は Transit Gateway に接続されるため、DX-GW アタッチメントが作成されます。DX-GW アタッチメントは、Transit Gateway attachment タイプ Connect のトランスポートになります。Transit Gateway attachment タイプ Connect を作成したら、Connect ピア (GREトンネル) を作成してオンプレミス VRF で GRE + BGP を設定します。Transit Gateway の GRE 外部 IP アドレス (ピア IP アドレス) は、Transit Gateway CIDR からの任意の IP になり、VRFアプライアンス側の GRE 外部 IP アドレスは、オンプレミスの PE ルータから広報されたアドレスのいずれかになります。CIDR ブロック内の BGP は、169.254.0.0/16 範囲の /29 CIDR である必要があります。/29 IPv4 範囲の最初のアドレスは、 VRF アプライアンスの BGP ピア IP アドレスになり、他の 2 つのアドレスが Transit Gateway BGP ピア用に選択されます。すべての GRE 接続に対して 2 つの BGP ピアを設定でき、これにより各 GRE トンネル内に組み込みの冗長性が提供されます。各 Transit Gateway タイプ Connect には、トラフィックを分離するための独自の Transit Gateway ルーティングテーブルがあります。VPC アタッチメントがルーティングテーブルの伝播に追加されると、VPC CIDR は VRF に動的に伝播されます。オンプレミス VRF は、対応する Transit Gateway attachment タイプ Connect がルーティング テーブルの伝播に追加されると、それぞれのルーティングテーブル上でそのネットワークを広報します。前のパターンと同様に、この場合も NACL とセキュリティグループを使用して VPC 内のネットワーク分離を確認する必要があります。

パターン 4 – 仮想ルーターアプライアンスを使用した VRF 分離 (RFC4364-オプション B)

VPC 内の仮想ルータアプライアンスによって構築されたオーバーレイネットワークの使用を考慮できます。次の図が示すように、オンプレミスネットワークの PE ルータとこの仮想ルータアプライアンスの間に、MPLS over GRE 接続を介して確立されたオプション B のネットワーク間インターフェイス (NNI) を作成できます。

図6 デザインパターン4; 仮想ルータアプライアンスによるオーバーレイネットワークの使用

簡単な検証のため、このアーキテクチャは、AWS Marketplace の Juniper Networks Virtual SRX (vSRX) を使用して、次の図の例示的な構成でテストできます。VPC1 のルータアプライアンスの左側はオンプレミスの PE ルータを模倣し、別の VPC2 のルータアプライアンスの右側は、オーバーレイネットワークを提供する VPC 内の仮想ルータアプライアンスを表します。これにより、両方の VPC がインターネット上の S2S VPN 経由で接続されるようになります。

図7 デザインパターン4の検証環境例

このデモ環境では、異なる MPLS L3 VPN から/へのトラフィックは、AWS Transit VPC の仮想ルーターアプライアンス上で終端される単一のオプション B オーバーレイ接続を介して多重化されます。この仮想ルータアプライアンスは、対応するルートターゲットをインポートおよびエクスポートすることで、ローカルに設定された複数の VRF にフローを明確化し、AWS Transit VPC 内の 1 つまたは複数のサブネットにバインドできます。以下は自律システム境界ルータ (ASBR) として機能する vSRX の構成例です。

[edit configuration]
routing-instances {
    vSRXForWorkload-LAN1 {
        interface ge-0/0/1.0;
        instance-type vrf;
        route-distinguisher 65002:1;
        vrf-import import-vSRXOnPrem1;
        vrf-export export-vSRXForWorkload1;
        vrf-table-label;
    }
    vSRXForWorkload-LAN2 {
        interface ge-0/0/2.0;
        instance-type vrf;
        route-distinguisher 65002:2;
        vrf-import import-vSRXOnPrem1; 
        vrf-export export-vSRXForWorkload2;
        vrf-table-label;
    }
} 

共通または異なるルートターゲットに基づくインポート及びエクスポートポリシーの適格な組み合わせも実装できます。AWS 側では、これらの各サブネットを同じ VPC に属する共通または専用のルートテーブルに関連付けることができます。サブネットルートテーブルごとに、VPC 内で異なるルーティングルックアップを実装できます。さらに、ルーティングコンテキスト間の分離を実現でき、前のパターンと同様に NACL とセキュリティグループを使用することもできます。

パターン 5 – Multi-VPC ENI Attachments を使用した VRF 分離

Multi-VPC ENI Attachments は、VPC レベルの分離を通じてアプライアンスが複数の個別のネットワークインターフェイスを持つことをサポートする機能です。この機能により、図 8 及び 図 9 に示すように、VPC の分離を維持しながら、アプライアンスなどのネットワーク機能が複数の ENI を持つことが可能になります。

図8 – デザインパターン5 の検証環境例 (TGW 使用)

図9 – デザインパターン5の検証環境例（VGW 使用）

図 1 で前述したように、このアーキテクチャは RFC4364 オプション A に準拠しており、各オンプレミス VRF を専用 VRF VPC に接続します。Multi-VPC ENI Attachments 機能により、ネットワーク機能アプライアンスを複数の VRF に接続できます。このアーキテクチャを使用する場合、パターン 2 と同様に、VRF-VPC ごとに個別の TGW ルートテーブルを使用する (図 8) か、ネットワーク要件に基づいて各 VPC で VGW を使用する (図 9) かを選択できます。

まとめ

一般的なクラウドの概念では、Amazon VPC は 1 つのルーティングドメインを提供する単一のフラットネットワークであるため、一致する VRF ごとに個別の VPC を持つことが最もシンプルな方法になります。ただし、4G/5G コア ネットワーク (UPF や PGW など) のようなアプリケーションでは、ルータをプライベートネットワークの複数の VRF に接続する必要がありますが、これらアプリケーションは通常、複数の VPC に分割することが出来ません。従って、VRF で分離されたプライベートネットワークへの単一 VPC の統合というこの課題は、AWS 上でのモバイルネットワーク実装のコンテキストで表面化することがよくあります。この記事では、Amazon VPC を VRF で分離されたオンプレミスのプライベートネットワークに接続するための 5 つの異なるアプローチについて説明しました。これは、AWS 上に 5G コアネットワークやプライベート 4G/5G ネットワークを構築するなど、通信業界のユースケースで必要になることがよくあります。各アプローチには、実装の複雑さ、運用コスト、スケーラビリティと性能要件の制約に関して長所と短所があります。よって、リストされたアプローチを使用した詳細な実装は、ユースケースの環境に応じて決定されることを推奨します。

この記事はアマゾン ウェブ サービス ジャパンの黒田由民が翻訳を担当しました。 (原文はこちら)

著者