 本記事は 夏休みクラウド自由研究2025 8/27付の記事です。 |
こんにちは、SCSKでAWSの内製化支援『テクニカルエスコートサービス』を担当している貝塚です。
5か月ほど前(もうそんな昔になるのですね…)、AWS Transit Gateway・AWS Direct Connect経由でオンプレミス環境と接続しているVPCの検証に関する記事を書きました。AWSのVPC間でAWS Site-to-Site VPNを構成する
今回は、テクニカルエスコートサービスによくご相談いただくDirect Connectまわりのご質問について解説します。
よくあるご相談：オンプレミスから既存とは別のVPCにつなぎたい
過去にオンプレミス環境からAWS上に構築したシステムに接続する要件があり、下図のようにvGW(仮想プライベートゲートウェイ)をDirect Connectにアタッチする形でVPCと接続しているケースがよくあります。
そして、AWSの利用が進み、別のVPCに構築したシステムをオンプレミス環境と接続したい(下図)。どのような構成にすればよいか？というご質問をよく頂きます。
構成案：VPC間をVPC Peeringで接続する
ご相談いただく際、ご相談者から、以下の案の実現性を訊かれることがあります。
この構成ですが、オンプレミスとVPC2は通信ができません。
VPC間の接続について調べたことがある方であれば推移的ピアリング(はできない)という制約について聞いたことがあるかと思います。VPC A, B, CがあってA – B, A – C をVPCピアリングの機能で接続したときに、A経由でB←→Cの通信はできないというものです。
vGWもVPCピアリングに似た性質を持っているため、前の図のVPC2 ←→ オンプレミスの通信はできないのです。
「vGWもVPCピアリングに似た性質を持っている」という点についてですが、IPルーティングの基礎的な知識をお持ちであれば、以下のように考えると理解しやすいかと思います。
VPCピアリングは、VPCとVPCの間に仮想的なVPCピアリング用ルータがあると考えることができます。(ユーザは確認することができませんが)この仮想VPCピアリング用ルータは、直接接続しているVPCのCIDRへの経路しか登録されていません。したがって、図で言うオンプレミス環境への経路を持っていないため、VPC2からオンプレミス環境へ向けた通信は仮想VPCピアリング用ルータで破棄されます。
vGWは、オンプレミス側からBGPで経路を受け取れるなど、仮想VPCピアリング用ルータよりも柔軟な経路設定ができるという違いはあるものの、他のVPC(この例ではVPC2)のCIDRへの経路を登録する方法がありません。このため、オンプレミス環境からVPC2へ向けた通信はvGWで破棄されます。
上記の通りVPCピアリング案は(そのままでは)うまくいかないため、正攻法として私がまず相談者の方にお話しするのは以下の2パターンです。
Direct Connect Gateway導入
Direct ConnectとvGWの間にDirect Connect Gateway (DXGW)をはさむようにします。DXGWはvGWを20個までアタッチできますので、この構成でオンプレミス環境と20個までのVPCの接続を実現できます。DXGWは料金無料ですので、利用料も上がりません。
設定次第ではあるのですが、注意点として、基本的にはオンプレミス←→VPC通信用であり、VPC間の通信はできないことが挙げられます。
Direct Connect Gateway + Transit Gateway導入
Direct Connect – Direct Connect Gateway – Transit Gateway – VPC という形で構成します。接続可能なVPCの数がDXGWよりずっと大きく(5,000 ※1)、VPC間通信も問題なく行えるため、自由度の高いネットワークを作るのであればお勧めの構成です。ただし、接続するVPC 1つごとに接続料金(50USD/1VPCくらい)が発生します。
2案の実現性について
上記どちらのパターンでも、一度vGWにアタッチしたDirect Connectの仮想インターフェイスは取り外す(デタッチして別のリソースにアタッチしなおす)ことができず、削除しかできないため、多くの場合(※2)、Direct Connectを提供している通信事業者に依頼して新しい仮想インターフェイスを作成してもらい、既存の仮想インターフェイスから切り替える形になります。
上記2案は、複数のVPCをオンプレミスと接続する場合にAWS公式ドキュメントなどを調べればすぐに発見できる構成案であり、拡張性や運用性の観点から優れた構成です。しかし、このようなご相談を頂くケースは、オンプレミスとの通信要件の発生したシステムの構築プロジェクトの中でネットワークの検討もしていることが多いため、そのシステムの管理・責任範囲とは言い難い(共用リソースである)Direct Connect GatewayやTransit Gatewayの新規導入や、予期していなかった通信事業者との調整などは高いハードルとなり、これら2案がすんなり受け入れられることはまずありません。
VPCピアリングとNATを組み合わせる
Direct Connectまわりは触りたくないという話になると、NATを組み合わせて解決を図ることになります。下図が解決策の一例です。
オンプレミスから見るとVPC2ではなくVPC1と、VPC2から見るとオンプレミスではなくVPC1と、それぞれ通信しているように見えるようにVPC1でNAT(双方向NAT)をしてあげます。この構成であれば宛先への経路がないというルートテーブルの問題を解決できることがお分かり頂けるかと思います。
通信要件が片方向であれば、Network Load Balancer (NLB)を入れるのが簡単です。デフォルトの設定で実質的に双方向NATが実現できます。通信要件が増えるたびにNLBを増やす必要があるので、数が増えると運用管理上の問題が出てきますが、通信要件が少ないうちは手軽で負荷の少ない解決策と言えます。
双方向NATできるものであればなんでもよいので、EC2でNAT用のインスタンスを構築するのも一案です。ENIに複数のIPアドレスを割り当ててやれば、NLBのように通信要件増加ごとにEC2インスタンスを増やさなくてもよいというメリットがあります。ただし、ENIに割り当てられるIPアドレス数上限はさほど多くない(m5.largeで10、t3.smallで4)ため、EC2はマネージドサービスではなくユーザーの運用負荷が大きいことも踏まえると、私見ではNLBに軍配が上がると考えています。
なお、NAT Gatewayでも実現できないか？と考えたくなるところですが、あて先NAT機能を持っていないため本ケースでは不適格となります。
まとめ
普通に何らかのシステム用のリソースが置かれているVPC1上に、突如、VPC2へ通信を中継するためのリソースを配置することになるわけで、ネットワーク設計上きれいな設計とは言い難いですが、通信要件がさらに増えたときにはDirect Connect Gateway導入またはDirect Connect Gateway + Transit Gateway導入した方がよいという助言をしつつ、双方向NAT(NLB)+VPCピアリングとするのが落としどころでしょうか。もしもっと良い案ありましたら教えてください！