以前にチームで取り組みを行なった際に発生した問題のふりかえりとなります。
背景
前提
- 自分が所属しているチームは、通信要件に応じ、主にVPC関連リソース、VPC Endpoint などネットワークリソース構築を担当している
- サービス提供は、別チームで構築する分業制を採用している
- そのため、VPC関連リソース提供後に、サービス提供側の EC2インスタンス、RDS、EKS、ECS や それに関連するSGや、NLB, ALB などの仕様については、サービス提供チームの領域であるため把握していない
- 今回の取り組みにあたり、通信要件一覧を改めて確認し最新化を行なった
- しかしながらそれでも、サービス間通信要件のみの確認に留まっていた
- ある一部のVPCが3AZ構成である
- NLB にはSGを設定していないサービスが多数（SGがサポートされた後に構築したサービスについては対応済）
これまで
- サービス間通信は、Internet 経由 または VPC Peering, PrivateLink を利用して行なっていた
取り組み
- Transit Gateway の導入に伴い、各VPCを Transit Gateway に接続し経路を構築した
- Route 53 Private Hosted Zone へのレコード登録
- VPCES の ターゲットとなっていた NLB はそのまま活用
- 関連するチームと移行日程を調整し、まずは 開発環境でリハーサルを実施
事象
- Transit Gateway への切り替え後に名前解決と疎通確認を実施したところ下記の事象を確認
- 名前解決は正常に行われていることを確認
- 疎通確認について、あるサービスから対向側への疎通確認が不能となっていた
- 逆方向からの疎通は確認できた
- 疎通確認で不能となっているサービスチームからも切り替え後の動作確認で、対向側との通信が確立できず疎通不能状態であることの連絡を受けた
移行前と、移行後のAWS構成図の違い
移行前
ここでのAWS構成図については、片方向からのみの図となっているが、実際は、双方向でPrivateLink を構築していた
移行後
解決まで
名前解決
- ターゲット先：Internal NLB の Private IP Address が返却されていることから問題ないことを確認
対向先 Internal NLB の設定確認
- 対向側の NLB までは到達できていることを確認できており、そこから先の経路について問題があると考え、それぞれの設定を確認
NLB - クロスゾーン負荷分散
クロスゾーン負荷分散については、下記の AWSドキュメントを参照ください。
- あるサービスでは、環境毎で統一が図れておらず、有効化、無効化バラバラであった
- ある検証のため設定を変更しているようであった、そのため本来の設定値を確認した
- 無効化しているケースで、一部疎通が出来ない状態があることから、クロスゾーン負荷分散の設定にも注目
NLB ターゲット設定 - クライアントIPアドレス保持
- クライアントIPアドレス保持については、こちらも有効化、無効化バラバラであった
主な要因
- 対向側が2AZ構成で、3AZ のサービスに通信を行う際に、3AZ側サービスの NLB でクロスゾーン負荷分散が無効化されているケースにて、疎通出来ないことが判明した
- クロスゾーン負荷分散を無効化にしている場合は、起点→終点までの経路は、同一AZ間通信となるため、通信先にサービスがない場合は、疎通不能となる
- 3AZ → 2AZ でも然り
対応
今後もそのような事態を防ぐため、NLB 設定について共通指針を纏め、Transit Gateway に接続しているVPC内でサービスを提供している各チームに対し提示し協力依頼を行なった
クロスゾーン負荷分散
- 有効化
クライアントIPアドレスの保持
- 有効化
- 通信元CIDR を許可することについても併せて依頼
さいごに
この投稿を執筆中に、改めてAWSドキュメントを確認したところ
Network Load Balancer のターゲットグループ属性を編集する - クライアント IP の保存
このドキュメントの記載内容で、気になる文面を確認した
トランジットゲートウェイを介してターゲットに到達した場合、クライアント IP 保存はサポートされていません。
ターゲットが Network Load Balancer と同じ VPC にある場合でも、Gateway Load Balancer エンドポイントを使用して Network Load Balancer Load Balancerとターゲット (インスタンスまたは IP アドレス) 間のトラフィックを検査する場合、クライアント IP 保存はサポートされていません。
インスタンスタイプが C1、CC1、CC2、CG1、CG2、CR1、G1、G2、HI1、HS1、M1、M2、M3、T1である場合、クライアント IP 保存をサポートしません。クライアント IP 保存を無効にして、これらのインスタンスタイプを IP アドレスとして登録することをお勧めします。
- トランジットゲートウェイを介してターゲットに到達した場合、クライアント IP 保存はサポートされていません
すなわち、クライアントIPアドレス保持を有効化していたとしても、Transit Gateway 経由だと、クライアントIPアドレス保持は無効化されること
ターゲットのSG に、通信元CIDR の許可設定をしても意味がない
そのため、通信元からのアクセスを制御するためには、NLB の SG に対し、通信元CIDR 許可の設定を行う必要があることに気づきができた
また、インスタンスタイプでも制限事項が存在していることも気づいたので、これからの改善に努めていきたい