AWS Direct Connect ゲートウェイの許可されたプレフィックス(Allowed Prefix)とは何かを整理してみた

AWS Direct Connect ゲートウェイの許可されたプレフィックス(Allowed Prefix)とは何かを整理してみた

AWS Direct Connect ゲートウェイに仮想プライベートゲートウェイやトランジットゲートウェイを関連付けする際に「許可されたプレフィックス」を指定します。それがどんな意味を持つのか、ゲートウェイの種類によって挙動がどう変わるのかをまとめました。

コンバンハ、千葉(幸)です。

AWS Direct Connect ゲートウェイ(DXGW)には許可されたプレフィックス(Allowed Prefix)というパラメーターがあります。これは、DXGWからオンプレミスのルーター(カスタマーゲートウェイ/CGW)に対してDirect Connectを通じてアドバタイズするルート情報をコントロールするものです。

DXGWに関連付けられるゲートウェイは以下の2種類があります。

  • 仮想プライベートゲートウェイ(VGW
  • トランジットゲートウェイ(TGW

関連付けるゲートウェイによって 許可されたプレフィックス の挙動が異なります。初見でその内容に混乱したので、このブログで整理してみます。

先にまとめ

DXGWの 許可されたプレフィックス は以下のように作用する。

  • VGWと関連づける場合
    • 関連付けの際に指定は任意(オプション)
      • 明示的に指定しない場合、自動的にVGWと関連づいたVPCのCIDRが指定される
    • アドバタイズされるルート情報はVGWと関連づいたVPCのCIDRの単位
    • 許可されたプレフィックス はフィルタとして機能する
      • プレフィックスがVPCのCIDRと同じかそれより広い場合:VPCのCIDRをアドバタイズする
      • プレフィックスがVPCのCIDRより小さいか異なる場合:何もアドバタイズしない
  • TGWと関連づける場合
    • 関連付けの際に指定が必須
    • アドバタイズ情報と「TGWが関連づいたVPCのCIDR」は関連しない
    • カスタマーが指定したプレフィックスがそのままアドバタイズされる

許可されたプレフィックス とは何か

冒頭の繰り返しになりますが簡単にイメージを押さえておきましょう。

allowed Prefix

DXGWには以下のいずれかのゲートウェイを関連付けできます。

  • 仮想プライベートゲートウェイ(VGW
  • トランジットゲートウェイ(TGW

図では2つのゲートウェイを1つのDXGWに関連づけているように表現していますが、実際には異なる種類のゲートウェイを同時に関連付けられません。また、詳細は後述しますがそれぞれのゲートウェイを使用する際に必要となる仮想インターフェース(VIF)が異なります。

DXGWには同じ種類のゲートウェイを複数関連づけられます。関連付けを作成する際に、 許可されたプレフィックス を指定します。ゲートウェイとDXGWが異なるアカウントにある場合、「関連付けの提案」「提案の承諾」という2つのプロセスを経ることになり、「提案の承諾」のタイミングで 許可されたプレフィックス を上書きすることもできます。

DXGWは関連付けごとの 許可されたプレフィックス の内容に応じ、Direct Connectを通じた対向のCGWに対してルートをアドバタイズします。

許可されたプレフィックス の詳細については以下ドキュメントを参照してください。

https://docs.aws.amazon.com/directconnect/latest/UserGuide/allowed-to-prefixes.html

VGWとDXGWを関連づける際の 許可されたプレフィックス

VGWとDXGWを関連づけるケースを考えます。この構成の場合、Direct ConnectのVIFにはプライベートVIFを用います。

VGW

アドバタイズされるのは、VGWが関連づけられたVPCのCIDRです。それより広い範囲でも狭い範囲でもありません。 許可されたプレフィックス によって以下のいずれかになります。

  • VPCのCIDRがアドバタイズされる
  • VPCのCIDRがアドバタイズされない

関連付け時に 許可されたプレフィックス を指定しない場合、デフォルトでVPCのCIDRが 許可されたプレフィックス になります。意図をもってフィルタリングしたい際に、 許可されたプレフィックス を指定します。

VGWと関連づける際の 許可されたプレフィックス はフィルタ?

初見で一番混乱したのがAWSドキュメントの以下の記述です。

仮想プライベートゲートウェイの関連付け

プレフィックスリスト (IPv4 と IPv6) は、同じ CIDR またはより小さな範囲の CIDR が Direct Connect ゲートウェイにアドバタイズされることを許可するフィルタとして機能します。プレフィックスは、VPC CIDR ブロックと同じ範囲またはより広い範囲に設定する必要があります。

注記

許可リストはフィルタとしてのみ機能し、関連付けられた VPC CIDR のみがカスタマーゲートウェイにアドバタイズされます。

https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/allowed-to-prefixes.html

「より小さな範囲が〜」という記述から、VPCのCIDRより小さな範囲をアドバタイズできるのか?と捉えてしまいました。そうではありません。

同じドキュメントに記載されているシナリオを見て理解が追いつきました。

CIDR 10.0.0.0/16 が仮想プライベートゲートウェイにアタッチされた VPC があるシナリオを考えてみます。

  • 許可されたプレフィックス リストが 22.0.0.0/24 に設定されている場合、ルートは受け取りません。これは、22.0.0.0/24 が 10.0.0.0/16 と同じあるいはより広くないためです。
  • 許可されたプレフィックス リストが 10.0.0.0/24 に設定されている場合、ルートは受け取りません。これは、10.0.0.0/24 が 10.0.0.0/16 と同じでないためです。
  • 許可されたプレフィックス リストが 10.0.0.0/15 に設定されている場合、10.0.0.0/16 は受け取ります。これは、IP アドレスが 10.0.0.0/16 より広いためです。

このシナリオでは、VGWがアタッチされたVPCのCIDRである10.0.0.0/16がアドバタイズされるか否かが、 許可されたプレフィックス の指定により変わります。

VGW Filter2

10.0.0.0/16と同じかそれより大きいCIDRを指定した際にフィルタを通過しアドバタイズされます。「同じ CIDR またはより小さな範囲の CIDR が Direct Connect ゲートウェイにアドバタイズされることを許可するフィルタとして機能します。プレフィックスは、VPC CIDR ブロックと同じ範囲またはより広い範囲に設定する必要があります。」は、フィルタ目線では自身(フィルタ)より小さなCIDRも許可する、ただしVPCのCIDRより大きなものを指定してね、という記述でした。

あえてVPCのCIDRより大きなCIDRを許可するケースとは?

どのみちアドバタイズされるのがVPCのCIDRなのであれば、それより大きいCIDRをフィルタ(許可されたプレフィックス)として指定する意味がどこにあるのかが気になります。

ケースのひとつとして、「VPCへのCIDR追加を見越しておく」があると考えました。

以下のナレッジセンターに各種接続方式におけるルートのアドバタイズについて記載があります。

Direct Connect private VIF connecting to a VGW

The VGW-associated VPC's IPv4/IPv6 CIDR advertise automatically to an on-premises BGP peer. For example, a VPC with CIDR 10.55.0.0/16 VGW is associated directly with a private VIF. The prefix 10.55.0.0/16 advertises to on-premises automatically. If there are additional CIDRs that are associated with the VPC, then those prefixes advertise over to the BGP peer.

Direct Connect Private VIF connected to a Direct Connect gateway associated with VGW

You can have up to 20 VGWs associated with a Direct Connect gateway. All VPC CIDR prefixes are advertised to the on-premises BGP Peer. The allowed prefixes list filters BGP advertisements from AWS towards the on-premises BGP peer.

The allowed prefix list allows the same CIDRs or a smaller subnet of the CIDRs to advertise to the Direct Connect gateway.

https://repost.aws/knowledge-center/direct-connect-vpc-bgp

DXGWを経由せず直接VGWとプライベートVIFを関連づけるパターンでは、「 If there are additional CIDRs that are associated with the VPC, then those prefixes advertise over to the BGP peer.(追加のCIDRがVPCに関連づけられたらそれらのプレフィックスはアドバタイズされる)」と記述があります。

DXGW+VGWのパターンでは直接同じ記述はありませんでしたが、同様の挙動を示すと考えられます。その際に 許可されたプレフィックス が元のVPCのCIDRのままだと少なくとも追加分のCIDRがフィルタを通過できなくなるため、そのためにあらかじめ広めに取っておく、というアプローチがあるのではと考えました。

VGW Filter

このあたりはあまり具体的に想像ができていないので、「そもそも挙動が違う」「こういったケースもあるよ」というのがあれば教えてください。(画面下部のお問い合わせフォームやX(Twitter)などからお願いします🙇)

TGWとDXGWを関連づける際の 許可されたプレフィックス

続いてTGWとDXGWを関連づけるケースを考えます。この構成の場合、Direct ConnectのVIFにはトランジットVIFを用います。

TGW

VGW+DXGWの構成と異なり、こちらはシンプルです。許可されたプレフィックス がそのままアドバタイズされます。 VGW+DXGWの場合と異なりVPCのCIDRをアドバタイズするという機能はないため、明示的に指定する必要があります。

TGWを経由してVPC以外の環境と通信することもあるため、任意のプレフィックスを指定できるようになっているということでしょう。それゆえ、複数のTGWをDXGWに関連づける場合はそれぞれの 許可されたプレフィックス が重複しないよう気を付ける必要があります。

VPCを接続する用途のTGWであれば、VPC CIDRをそのまま 許可されたプレフィックス として指定するのがシンプルかと思います。一方で、将来的な拡張に備えて広めに許可しておく、という考え方もあります。

このあたりの詳細は以下が分かりやすくまとまっていたためご参考ください。

https://blog.serverworks.co.jp/understanding-the-need-to-update-allowed-prefixes-on-dxgw-when-using-tgw

まとめ(再掲)

DXGWの 許可されたプレフィックス は以下のように作用する。

  • VGWと関連づける場合
    • 関連付けの際に指定は任意(オプション)
      • 明示的に指定しない場合、自動的にVGWと関連づいたVPCのCIDRが指定される
    • アドバタイズされるルート情報はVGWと関連づいたVPCのCIDRの単位
    • 許可されたプレフィックス はフィルタとして機能する
      • プレフィックスがVPCのCIDRと同じかそれより広い場合:VPCのCIDRをアドバタイズする
      • プレフィックスがVPCのCIDRより小さいか異なる場合:何もアドバタイズしない
  • TGWと関連づける場合
    • 関連付けの際に指定が必須
    • アドバタイズ情報と「TGWが関連づいたVPCのCIDR」は関連しない
    • カスタマーが指定したプレフィックスがそのままアドバタイズされる

終わりに

AWS Direct Connect ゲートウェイの 許可されたプレフィックス (Allowed Prefix)とは何か整理してみました。

これまで特に深く意識せずVPCのCIDRをそのまま 許可されたプレフィックス として指定してきましたが、細かい部分を押さえることができました。関連づけるゲートウェイがVGWかTGWかで挙動が変わる、という点が一番印象的でした。

多くのケースではVPCのCIDRと同じものを指定する、で事足りるかと思いますが、詳細な設計が必要な場面で思い出してください。

以上、チバユキ (@batchicchi)がお送りしました。

参考

この記事をシェアする

facebookのロゴhatenaのロゴtwitterのロゴ

© Classmethod, Inc. All rights reserved.