ネットワークの知識
- AWSクラウド基盤案件に携わって6年程度。
- それまでは（オンプレミス）アプリケーション開発に従事することが多かったので、苦手にしていた分野でもある。
- まだまだ分からない事が多いですがメンバーにも助けられ、日々の業務や自己研鑽の時間でキャッチアップを行なっています。
きっかけ
- AWS Certified Advanced Netwoking Speciality の 受験勉強していた時に、聞いたことのなかったキーワードが出てきたぞ！
- 『非対称ルーティング』
- ん？ 何それ？
- 『非対称ルーティング』
- リクエスト側サブネット構成が3AZで、対向側サブネットの構成が2AZで、PrivateLink を構成した場合、『非対称ルーティング』になるのではないか？という疑問から
そもそも非対称ルーティングってなんぞや？？？
ChatGPT o4 先生に聞いてみると下記回答で応答がありました。
非対称ルーティング（Asymmetric Routing）は、送信経路と受信経路が異なるルーティングパスを通る状況を指します。
これは、ネットワークパケットが送信元から宛先に到達する際の経路と、返信パケットが宛先から送信元に戻る際の経路が異なる場合に発生します。
下記AWSでは、Transit Gateway を利用したケースがドキュメントが検索でHITしてきます。
AWS Transit Gatewayトラフィックフローと非対称ルーティング
非対称ルーティングの発生要因
非対称ルーティングが発生する要因は、下記の４つが列挙されるらしい
- ネットワーク上に複数のルーティングパスが存在し、それぞれのパスが異なるルートテーブルやルーティングポリシーを持つ場合
- トラフィックを複数の経路に分散するためのロードバランサーが設定されている場合
- 送信と受信が異なるルーティングポリシーを使用している場合
- ネットワーク構成の変更やルーティングテーブルの変更により、一部のパケットが異なる経路を通るようになる場合
PrivateLink は、サービス側に NLB を構築しているので、2. には合致する。
他は特に問題なさそうだ
自分の理解
前述でも例に出したように、リクエスト側サブネット構成が3AZ で、
対向側サブネット構成が2AZ のケースで考えてみる。
前提条件
- ルートテーブル、Network ACL の設定は、制限をかけるような設定を行なっていない。
- 前述の「非対称ルーティングの発生要因」に記載の内容で、1, 3, 4 の設定
送信経路
- ap-northeast-1d の EC2インスタンスから、対向側へのリクエストを送信
- ap-norheast-1d の Endpoint から 対向側の VPC Endpoint Ssrvice(NLB) へ
- 対向側には、ap-northeast-1d にサブネットが構成されていないため、NLBの動作としては、ap-northeast-1a, 1c のいずれかのEC2インスタンスが応答する。
- この場合は、ap-northeast-1a の EC2インスタンスが応答した。
受信経路
- ap-northeast-1a からの応答なので、戻ってくる経路としては、ap-northeast-1a の VPC Enndpoint を経由してくる
- その後、ap-northeast-1d に配置されているEC2インスタンスへ戻る
AWSサポートに問い合わせた回答
AWSサポートに問い合わせてみました。
今回のケースにおいては、非対称ルーティングとはならない旨の回答が説明とともに返信がありました。
送信経路
- ap-northeast-1d の EC2インスタンスから、対向側へのリクエストを送信
- ap-northeast-1a, 1c の Endpoint から 対向側の VPC Endpoint Service(NLB) へ
- この場合は、ap-northeast-1a の EC2インスタンスが応答
受信経路
- ap-northeast-1a からの応答なので、戻ってくる経路としては、ap-northeast-1a の VPC Enndpoint を経由してくる
- その後、ap-northeast-1d に配置されているEC2インスタンスへ戻る
違い
- 送信経路で、リクエスト側のEC2インスタンスから、VPC Endpoint への経路が、先を見通して ap-northeast-1a, 1c を選択する
- 最初の経路選択で非対称ルーティングとならないように制御されているようだ
まとめ
- PrivateLink では、「非対称ルーティング」にはなり得ない
- ただし、「非対称ルーティングの発生要因」 に 2. 以外の設定を行なっているケースは起こり得る事がある。
- 今回のケースでは比較的構成も単純でしたが、複雑なケースやTransit Gateway を導入したケースについてはまだ理解が追いついていないところもある
- 今後、試験の復習、業務での経験も深めながら、またこのテーマで深掘りできたら良いと感じた。
- 色々、確認しながら試験勉強も進めていたおかげもあり、AWS Certified Advanced Networking Speciality には２回目の挑戦でなんとか合格できました。