TGW 併用時 DXGW の許可されたプレフィックスの更新作業が必要な場合を理解する

記事タイトルとURLをコピーする

マネージドサービス部 佐竹です。
本ブログでは、Transit Gateway (TGW) と Direct Connect (DXGW) 併用時に、DXGW の許可されたプレフィックス (Allowed Prefixes) の設定を更新する必要が出る場面について、ネットワーク運用の観点から記載します。

はじめに結論

TGW と DXGW 併用時に、DXGW の許可されたプレフィックスの設定を更新する必要が出る条件は以下の通りです。

  1. 新しく VPC を作成した、または既存の VPC にセカンダリ CIDR を追加した場合
  2. 且つそれらの CIDR が DXGW の許可されたプレフィックスに含まれていない場合
  3. 追加された CIDR に対して、オンプレミスから DXGW を通じてアクセスを行いたい場合

これらの条件が満たされた場合には、DXGW の許可されたプレフィックス (Allowed Prefixes) の設定を更新する必要があります。

仕様について

先に理解の前提となる AWS の仕様についてです。

以下の AWS 公式ドキュメントに DXGW の許可されたプレフィックスの仕様について詳しく説明が記載されています。

docs.aws.amazon.com

上記ドキュメント内で 2 パターンの記載に分かれている通り、DXGW と TGW を併用する場合としない場合で「許可されたプレフィックス」の挙動が変わる点が少々理解を困難にさせているのですが、今回は DXGW と TGW とを併用するパターンのみを説明します。

では、今回の解説ブログの前提となるネットワーク構成例についてまずは記載していきます。

AWS 環境構成図

上図の構成を例とします。本構成では、図の左側にオンプレミス環境があり、中央にネットワークハブとしての「ネットワークアカウント」が存在しています。

そして、ネットワークアカウントに敷設されています Direct Connect、DXGW、さらに TGW を通じてアカウント A とアカウント B はオンプレミスと通信しています。

この時、DXGW には許可されたプリフィックスとしてアカウント A とアカウント B に作成されている VPC の CIDR がそれぞれ記載されています。

このように設定を行っている今回の構成では、許可されたプレフィックス(図では Allowed Prefixes と記載)が BGP で広報されることで、オンプレミスの各サーバへアカウント A 及びアカウント B の各 VPC への宛先が伝わります。

つまり「DXGW の許可されたプレフィックス」の記載内容によって経路が制御されることになります。

もし DXGW の許可されたプレフィックスに正しい CIDR の記載がない場合、各 VPC への通信が不可能となってしまうことになります。

許可されたプリフィックスの上限について

補足となりますが、今現在は DXGW の許可されたプリフィックスは、以下のマネジメントコンソール画面に Specify up to 200 prefixes, each prefix separated by a comma. Or, put each prefix on separate lines. と記載があるように、200 まで記載が可能となっています。

Direct Connect gateway association settings

本緩和が AWS 側で行われたのは、2023年4月末頃となります。このリストへの最大記載可能数は長らく 20 であり、AWS Site-to-Site VPN と併用する場合に、経路制御において課題が出る場合があったのですが、現在はその懸念はほぼ払しょくされております*1

許可されたプレフィックスの仕様を鑑みた運用対応

それでは本題です。

AWS 環境構成図

先に掲載しました上図の構成から、それぞれ以下の状態に遷移したとします。

新しく VPC を作成した場合

今回の例ではアカウント B に新しく VPC を作成したとします。CIDR は他の VPC と重複をなくし「10.3.0.0/16」としました。

ただしこの状態のままでは、オンプレミス環境は追加された新しい VPC 「10.3.0.0/16」へとアクセスができない状態となってしまいます。

オンプレミス環境から新しい VPC へとアクセスを可能とされたい場合は、上図の通り DXGW の許可されたプレフィックスへ、新しい VPC の CIDR「10.3.0.0/16」を忘れずに追加する運用が必要となります。

既存の VPC にセカンダリ CIDR を追加した場合

VPC セカンダリ CIDR を利用する場合でも同様です。

新しく VPC を作成したのではなく、セカンダリ CIDR を利用して既存の VPC へ CIDR を追加した場合でも、オンプレミスとの通信が必要な場合には DXGW の許可されたプリフィックスへ CIDR「10.3.0.0/16」を忘れずに追加する運用が必要となります。

ご紹介したそれぞれの CIDR 追加のどちらの場合でも、オンプレミスとの通信が必要となる場合は、DXGW の許可されたプレフィックスの更新を運用でカバーする必要があり、これを漏らさず行うようにします。

許可されたプレフィックスの更新作業が不要となる場合

ブログの冒頭に記載しました「結論」の3つの条件では、2つ目の条件として「2. 且つそれらの CIDR が DXGW の許可されたプレフィックスに含まれていない場合」と記載しました。

この条件が満たされていない場合、つまり「許可されたプレフィックスの更新作業が不要」となる構成についてみていきます。

最初にご紹介した構成から、少し変更された上図の構成があるとします。

本構成においては、DXGW の許可されたプレフィックスは「10.0.0.0/16」と記載されており、アカウント A と アカウント B の持つ VPC CIDR である「10.0.4.0/24」と「10.0.5.0/24」はその範囲内に含まれています。

このような記載は「AWS には 10.0.0.0/16 から払い出しを行うこととする」と予め決定されているエンドユーザ様等で行われる場合があります。

この状況下で、アカウント B の VPC にセカンダリ CIDR として「10.0.6.0/24」を追加したとします。

先の例の通りであれば、DXGW の許可されたプレフィックスの更新が必要なように思われるのですが、許可されたプレフィックス「10.0.0.0/16」は既に「10.0.6.0/24」を含んでいます

この場合、2つ目の条件である「2. 且つそれらの CIDR が DXGW の許可されたプレフィックスに含まれていない場合」が満たされないため、作業が不要となります。

よって、DXGW の許可されたプレフィックスの更新作業なしにオンプレミスから「10.0.6.0/24」へと通信が可能となります。

余談

DXGW の許可されたプレフィックスに「予め AWS に利用すると決めた CIDR 範囲を集約して全て記載しておく」というエンドユーザ様もいらっしゃれば「存在しない CIDR が BGP で広報されるのは許容できない」として、CIDR が増える都度プレフィックスに追記を求められるエンドユーザ様もいらっしゃいます。

TAM や CSM は、担当しているエンドユーザ様がどちらの方針なのか予め把握しておき、本対応作業を漏らさずに実施したいものです。

まとめ

本ブログでは、Transit Gateway (TGW) と Direct Connect (DXGW) 併用時に、DXGW の許可されたプレフィックス (Allowed Prefixes) の設定を更新する必要が出る場面について、ネットワーク運用の観点から記載しました。

今一度、以下に結論を記載します。

TGW と DXGW 併用時に、DXGW の許可されたプレフィックスの設定を更新する必要が出る条件は以下の通りです。

  1. 新しく VPC を作成した、または既存の VPC にセカンダリ CIDR を追加した場合
  2. 且つそれらの CIDR が DXGW の許可されたプレフィックスに含まれていない場合
  3. 追加された CIDR に対して、オンプレミスから DXGW を通じてアクセスを行いたい場合

これらの条件が満たされた場合には、DXGW の許可されたプレフィックス (Allowed Prefixes) の設定を更新する必要があるため、運用で漏らさずカバーしましょう。

この更新作業を行わなかった場合には、新規に追加された CIDR に対してオンプレミスから通信が到達しない、といったトラブルが発生することがあります*2

AWS を利用されているエンドユーザ様では Direct Connect を利用した専用線と Transit Gateway を合わせて敷設されるということが増えています。このため、VPC の新規の追加やセカンダリ CIDR の追加作業があれば、それと同時に本ブログの内容を思い出してみてください。

以上になります。

では、またお会いしましょう。

*1:詳しくは、以下の資料における「経路制御:ルート設計上の課題」スライドをご覧ください https://d1.awsstatic.com/webinars/jp/pdf/services/202110_AWS_Black_Belt_Site-to-Site_VPN.pdf

*2:実際に私もこの事象に何度か出くわしたことがあります

佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ

マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。