VPCと外部NW、別VPCのIPアドレスの重複や枯渇に対応する方法

# はじめに
大規模NWにVPCを接続する際にIPアドレスレンジが課題になることって結構多いですよね。
今回は、IPアドレスを効果的に利用する方法や、節約する方法を解説していきます。
※IPアドレスの管理方法などには触れません。

# 課題
以下のような大規模NWの構成を考えてみます。
各NWは相互に通信を行うため、全体で、IPアドレスが重複しないような管理方式を取るか、どこかでNATするかなど構成を大きく検討する必要があります。また、NWは変更、拡張していくものですので、できる限りIPアドレスは効果的に利用する必要があります。
![スクリーンショット 2024-06-09 22.31.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/f305380e-cb9e-2e55-fbfe-09f4b5bc9269.png)

そもそも、ローカルNW上はプライベートIPアドレスを利用することが一般的です。プライベートIPアドレスのクラスAレンジを利用したとしてもせいぜい約１６００万個程度、予備のIPアドレスや、拡張性を考えたCIDR構成を取っていることが一般的であることを考えるととても余裕のある構成とはいえません。

# 解決策
考えうる解決策は以下です。
| # |案  |概要  |
|---|---|---|
|1  |IPv6を利用する  | 外部通信を行う場合、枯渇しやすいIPv4ではなく、IPv6アドレスを利用してしまうという案です。対抗側が対応しているかなどにもよりますが、新規NWを考える場合は、第一に検討することをおすすめします。|
|2  |外部通信するサブネットを限定する  | 外部通信を行うVPCサブネットを限定してしまう方法です。外部通信を行うコンポーネントに限ってIPアドレスレンジを切り、その他サブネットはIPアドレスレンジの重複を許容する方式です。|
|2' |アウトバウンド通信の際にプライベートNATを行う|アウトバウンド通信の際に特定のIPアドレスにプライベートNATする方式です。NATGWを利用し、プライベートNATを行います。これにより、AZ毎に１IPアドレスで済むため、IPアドレスの消費を最小限に抑えることができます。|
|2'' |ALBを最小限の台数にする|ALBの台数を最小限に抑える方式です。ALB毎に少なくとも８個のIPアドレスを確保しておく必要があるため、できる限り集約すると、IPアドレスの消費を抑えることができます。ALBは複数証明書をアタッチし、ホスト名毎にターゲットを切り替えることができるため、IPアドレスの消費を抑えることができます。|
|3 |VPC間通信の場合はPrivateLinkを利用する|これはもはや常識だと思いますが、VPC間通信においては、PrivateLinkを原則利用することがおすすめです。これにより、セキュアかつ、IPアドレスが重複していても問題なく通信できるため、管理対象のIPアドレスを払い出す必要がありません。|

## 案１　IPv6を利用する
![スクリーンショット 2024-06-09 22.55.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/9901c45c-c012-61f0-bac2-3d5318b5e909.png)
VPC、サブネットにIPｖ６アドレスを追加します。デュアルスタック構成を取ることで、IPｖ４アドレスと併用した利用が可能です。ELBもデュアルスタック構成を取ることで、IPv4とv6を並行利用できます。

https://docs.aws.amazon.com/ja_jp/whitepapers/latest/ipv6-on-aws/amazon-vpc-internet-access.html

また、TransitGateway、VPCPeering、Direct Connectを利用した構成でもデュアルスタック構成を取ることが可能です。１つだけ、Site to SiteVPNに関しては同一トンネルでのIPv6、ｖ４の併用がサポートされていないため、v4、v6それぞれでトンネルを用意してあげる必要があります。
なお、どのパターンでも、ルートテーブル、SG、NACL等へのｖ６レンジの追加をお忘れなきように
名前解決なども要注意です。
詳細は以下参照

https://aws.amazon.com/jp/blogs/news/adual-stack-ipv6-architectures-for-aws-and-hybrid-networks-jp/

大規模NWで特に制限がなければ、ｖ６への以降をまじめに考える時期なのかもしれませんね。

# 案2 外部通信するサブネットを最小限にする
![スクリーンショット 2024-06-09 23.10.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/47dbf600-40c5-e7a4-3e04-f0d6416f7b3f.png)
外部通信を実施するサブネットのみに重複しないCIDRを割り当てる方式です。VPCでは、セカンダリCIDRを割り当てることができるため、重複しないIPを追加アタッチしても良いでしょう。そのCIDRを切り出し、通信をする最小限のサブネットに割り当てることで、IPアドレスの消費を最小限にします。

## 案2' アウトバウンド通信の際にプライベートNATを行う
![スクリーンショット 2024-06-09 23.15.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/11f7f1e5-1a1f-07d7-ba7a-c3ae7de90bac.png)
    外部へのアウトバウンド通信を行う際に、NATGWにより、プライベートNATを行う方式です。アウトバウンド通信を行うコンポーネントが多い場合に有効です。NATGWのIPアドレスに変換することが可能ですので、IPアドレスの消費を最小限に抑えることができます。
    
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-gateway.html

## 案2'' ALBを最小限の台数にする
![スクリーンショット 2024-06-09 23.19.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/37d4a206-3557-d84c-18a8-221c9e616feb.png)
ALBでは最低８つのIPアドレスを確保することが推奨されています。そこで、ドメインごとにALBを分けるのではなく、ALBをできる限り集約し、SNIにより、複数ドメインを一つのALBで受ける方式を取ることで、IPアドレスの消費を抑えることができます。

https://aws.amazon.com/jp/blogs/news/new-application-load-balancer-sni/

# 案3 VPC間通信の場合はPrivateLinkを利用する
![スクリーンショット 2024-06-09 23.34.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/c3bfeec9-b80b-67ca-95a7-0e7424d08fcd.png)
言わずもがなの方式です。PrivateLinkを利用するとNLB配下のサービスを他VPCにPrivateLinkで公開することができます。IPアドレスレンジが重複していても問題なく、送信元側からは、同一VPC内のエンドポイント宛への通信ができれば、PrivateLinkを経由してNLB宛に通信ができます。IPアドレスが重複していても問題ないため、管理対象IPを保つ必要がありません。
https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/privatelink-share-your-services.html

# まとめ
まじめにIPｖ４アドレスの枯渇を考える時期になってきたのかもしれませんね。今回触れた件とは直接の関係はないですが、AWSではパブリックIPｖ４アドレスの利用を有料化に踏み切りました。ｖ６への移行を前向きに考えるのが良い時期です。また、案２以降で触れた、工夫などを組み合わせることで、既存のIPｖ４アドレスレンジへの通信を並行利用するなど、今後の拡張性、互換性を考えた最適なNW設計をしていきたいものです。