オンプレのプライベート IP 足りない問題を PrivateLink で解決する（前編）

オンプレのプライベート IP 足りない問題とは？

• AWS 上に新しいシステムを構築するとします。
• この時、あなたは AWS 上に構築する新システムの設計者だとします。
• ただし、新しいシステムは、オンプレにあるいくつかのシステムと DirectConnect などを介して通信する必要があるとします。
• この時、通常ですと、ルーティング上、オンプレにあるシステムと通信可能なプライベート IP レンジを AWS 側の新規システム側に払い出して割り当てる必要があります。
• このため、あなたはオンプレ側のネットワーク担当者、またはそれに相当する方と、AWS 上の新システムに払い出すプライベート IP レンジについて協議している状況だとしましょう。

この状況で、あなたは衝撃の事実を告げられます。

 オンプレのネットワーク担当者：
  「AWS 側の新システムに払い出すプライベート IP レンジって、/26 を１個で足りる？」

 あなた：「えっ！？」

 　　（ ええっと、/26 のサブネットマスクって、IP たったの64個分、ってこと？！
 　　　 大きいシステムなのに、そんな小さいレンジで新システムのVPC作れるわけないじゃーん ） ※ 心の声

 オンプレのネットワーク担当者：
   「いやぁ … 払い出せるプライベートIPに余裕がなくて、カツカツなんだよね。
     じゃ、クラスC を 1個 くらいまでなら払い出せるけど？」

 あなた：「ええっ！？」

　 　（ えーっと、クラスC って、IP 254 個分、だよね…
 　　　 さっきよりマシだけど、それでも全然足りなそうだよな…
  　　　っていうか、プライベートIPレンジって、クラスAだったら IP 1677万個分もあるのに、
　 　　 カツカツで空きがないって、どうゆうこと？！ ）  ※ 心の声

上記のような状況が、オンプレのプライベート IP 足りない問題です。

あなたは、クラウドに作るシステムが プライベート IP 64 個くらいで足りるっしょ、って思われていた、オンプレ感覚とのギャップに軽いカルチャーショックを受けつつも、心の中で疑問の声が消えません。「ホントに、プライベート IP レンジ使い切って、枯渇してるの？！」

オンプレのプライベート IP 足りない問題が生まれる背景

前述した、ちょっと誇張された状況かどうかは別としても、オンプレのプライベート IP 足りない問題は、意外に存在する、と言うことが分かりました。筆者 1 人の少ない経験の中でも、これまで複数回、前述のような経験をしています。

筆者は、いわゆる大手システムインテグレーターの案件で仕事をすることが多いですので、必然的に顧客になる企業は、いわゆる歴史ある大手企業であることが多くなります。そうした企業では、何十年にも渡る自社システム開発の中で、さまざまなネットワークや自社システムにプライベート IP レンジを払い出しては割り当ててきているため、未割り当てのプライベート IP レンジが潤沢に余っているような状況では無くなってきているわけです。

もちろん、実際に全てのプライベート IP アドレスを使い切るくらいの 膨大な数の PC やサーバーなどを抱えているわけではなく、さまざまなネットワークやシステムに、それぞれ必要十分なサイズの プライベート IP レンジを払い出してきた結果、枯渇してきている、ということだと思います。

このため、例えば歯抜けにならないように、ひとまとまりで大きなプライベート IP レンジを確保しようとすると、どこかの不要になったシステムに割り当てた分の IP レンジを回収したり、既存の割り当てをどこかに移動させたりしないといけない、という状況になるわけです。

このような状況に対応するための手段はいくつか考えられますが、AWS のネージドサービスである PrivateLink を活用する、というのがお手軽な対策の一つになるかと思います。

PrivateLink とは？

• ひとことでいうと、アベイラビリティーゾーンごとの ENI （VPC エンドポイント）を入り口とし、NLB（エンドポイントサービス）を出口として構成された、片方向の通信トンネルにおける、ステートフルな NAPT（ネットワークアドレス＆ポート変換）通信のマネージドサービス、だと言えると思います。

  • AWS 上の新システムからオンプレ環境への下り通信時の例：

    

  • オンプレ環境から AWS 上の新システムへの上り通信時の例：

    

• 上図のように、NAPT 通信の入り口となる ENI と、出口となる NLB 配下の ENI が、AZ ごとに配置されます。

• VPC エンドポイント による DNS レコードは、呼び出し元の AZ に応じて、同じ AZ 内の入り口 ENI のプライベート IP を回答します。

• PrivateLink は基本的に、入り口 ENI と同じ AZ の出口 ENI へ通信トンネルを繋げる仕組み、と言えますので、例えば AZ-a で PrivateLink に入った通信は AZ-a の出口 ENI から出てきます。

• ただし、障害発生時のことなどを考慮して、AZ 跨ぎのルーティングを可能にするように設定することもできます。

• 最初に注意する点は、PrivateLink は「片方向」のステートフルな NAPT 通信を行なってくれるマネージドサービスですので、オンプレ環境と AWS 上の新システムの間で、お互いに通信の起点となるような、両方向の通信要件がある場合、前掲の図のように、上り方向と下り方向の 2 本、PrivateLink を張る必要がある、ということです。

• ただし、片方向とはいえ「ステートフル」な NAPT 通信になるため、例えば、AWS 上の新システムからオンプレ環境のシステムへリクエストを送信すると、下り方向の PrivateLink が使用されますが、オンプレ環境のシステムから返されるレスポンス通信については、上り方向の PrivateLink が使用されるわけではなく、通ってきたのと同じ、下り方向の PrivateLink の経路を通ってレスポンスが戻ってくる、という点について理解しておくことが大切です。

• また、PrivateLink には下記の３種類の VPC エンドポイントを使う方式がありますが、ここでは前述した文脈上、最も主要な、インターフェース VPC エンドポイントを使った PrivateLink のことを指していることに注意してください。今回の文脈では、ゲートウェイエンドポイントと Gateway Load Balancer エンドポイントについては触れません。

  1. ゲートウェイエンドポイント
  2. インターフェイスエンドポイント
  3. Gateway Load Balancer エンドポイント

なぜ PrivateLink なのか？

• オンプレ環境との NAT 通信方法として、独自の NAT インスタンスや仮想アプライアンスなどを立てて通信する方法もあるかと思います。

• しかし、多数の NAT ルールのメンテナンスや、独自に NAT インスタンスを立てた時の可用性の確保や管理の手間等を考えると、マネージドサービスである PrivateLink は魅力的だと思います。

具体的にどうやるのか？

• 前掲の図のように、まずオンプレ側から払い出し可能な小さなプライベート IP レンジに収まる VPC を設けて、そこをオンプレ側と DirectConnect 等で繋ぎます。
• そして、オンプレ環境とルーティング可能な、小さなプライベート IP レンジの VPC と、新システム用に別に立てた VPC を、PrivateLink 越しに NAPT させて繋ぎます。
• 新システム用に別に立てた VPC は、PrivateLink によって完全に切り離されているため、オンプレ環境側と重なるプライベート IP レンジでも構いません。このため、自由なプライベート IP レンジを振ることができます。

（後編 へ続く）