※現職でスキルアップ発表会等で作成していたものをQiitaに書き起こすシリーズ④
元がppt資料で口頭説明ありきな文章なのでちょっと分かりづらい部分はごめんなさい。
現象
-
DirectConnectを介してAWSリソースに接続する端末について、IPv4アドレスを宛先とした場合は成功していたが…
-
FQDNを宛先とすると接続失敗してしまった
原因
- インフラ費を抑えるため、1つのDirect Connect Gatewayに複数のVPCを紐づけ
高額なDirectConnectの回線費用を1本分に抑えていた。
ここまでは良いのだが…
- Direct Connectに設定されているDNSサーバがQA環境のもので、そのDNSサーバはSTG環境の名前解決には使えないことが発覚
- 接続元でDNSサーバをSTG環境のものに指定できれば問題なかったが、端末のF/Wはそれを指定できるような作りにはなっていなかった…
対策までの道筋…
端末をDNSサーバが指定できるように改修しよう！
⇒ その時点で改修は困難と端末F/Wチームに言われる。
もう一本DirectConnectを構成しよう！！
⇒追加費用はもとよりスケジュールが許容できない（開通に数か月かかる）
いっそ全てIPアドレスで通信するようにポリシー変えよう！！！
⇒EC2等のサーバはそれで問題ないが、API Gateway&Lambdaの部分はFQDNを使わないと接続が難しい。
orz...
辿り着いた対策！！！
QAとSTGでVPCピアリング構成を構築する
- VPCピアリングをすることで、QAのDNSサーバでもSTGのモジュールの名前解決ができるようになる。
DirectConnect->VPC1->VPC2というトラフィックは許されないと思っていたがこの場合の名前解決には使えるとのこと。びっくり。 - VPCピアリングはトラフィックの従量課金式だが、名前解決のための通信であれば金額は誤差程度に抑えられる。
起死回生のウルトラＣ！！！
が・・・駄目っ・・・
- VPC Peeringを構成するVPCはSubnetのSegmentが被ってはいけないという制約がある
- 今回両VPCであまりその部分を意識せず構築しており、後からSegment構成を修正しようにも
モジュールの量が多く影響範囲があまりに大きいため挫折…
最終的な結果
- 新しく3つ目のVPCを用意し当初求めていた役割はそのVPCに担ってもらった。
- VPCひとつ分の追加費用がかかるが致し方なし
まとめ
- DNSサーバを指定できない融通の利かない端末・ソフトウェアからDirectConnectを介して接続する場合は名前解決に注意
- ただしVPC Peeringが可能な環境であればVPCをまたいだ名前解決ができる