VPC のデフォルト CIDR /16 はなぜ /16 なのか - IP アドレス設計の雑学と落とし穴
VPC のデフォルト CIDR が /16 に設定されている理由、RFC 1918 のプライベートアドレス空間の歴史、サブネットで使えない 5 つの IP アドレス、CIDR 設計の失敗パターンを雑学的に解説します。
RFC 1918 とプライベート IP アドレスの歴史
VPC の CIDR 設計を理解するには、まず RFC 1918 の歴史を知る必要があります。1996 年に公開された RFC 1918 は、インターネットに直接接続しないプライベートネットワーク用に 3 つのアドレス範囲を予約しました。10.0.0.0/8 (約 1,677 万アドレス)、172.16.0.0/12 (約 104 万アドレス)、192.168.0.0/16 (約 6.5 万アドレス) です。この 3 つの範囲が予約された背景には、1990 年代のインターネットの急速な成長があります。IPv4 のアドレス空間は約 43 億個しかなく、すべてのデバイスにグローバル IP アドレスを割り当てると枯渇することが明らかでした。プライベートアドレスと NAT (Network Address Translation) を組み合わせることで、1 つのグローバル IP アドレスの背後に多数のデバイスを配置できるようになり、アドレス枯渇を緩和しました。VPC のデフォルト CIDR 10.0.0.0/16 は、この RFC 1918 の 10.0.0.0/8 の範囲内から /16 を切り出したものです。
なぜ /16 なのか - 大きすぎず小さすぎない絶妙なサイズ
/16 の CIDR ブロックは 65,536 個の IP アドレスを含みます。AWS がデフォルトで /16 を選んだ理由は、ほとんどのワークロードに十分な IP アドレス空間を提供しつつ、10.0.0.0/8 の範囲内で 256 個の /16 ブロックを切り出せるバランスの良さにあります。VPC の CIDR は /16 から /28 まで指定可能です。/28 は 16 アドレス (うち使用可能は 11) で、最小の VPC です。/16 は 65,536 アドレスで、デフォルトの最大サイズです。実際には、/16 は多くのケースで過剰です。100 台の EC2 インスタンスを動かすだけなら /24 (256 アドレス) で十分です。しかし、VPC の CIDR は後から縮小できないため (拡張は可能)、最初に大きめに設定しておくのが安全です。/16 は「将来の拡張に備えた余裕」を持たせるデフォルト値として合理的です。ただし、マルチ VPC 環境では /16 を乱発すると 10.0.0.0/8 の空間をすぐに使い切ります。256 個の VPC で枯渇するため、計画的な CIDR 割り当てが必要です。
サブネットで使えない 5 つの IP アドレス
VPC のサブネットでは、各サブネットの最初の 4 つと最後の 1 つ、合計 5 つの IP アドレスが AWS によって予約されており、EC2 インスタンスなどに割り当てることができません。/24 サブネット (10.0.1.0/24) の場合、10.0.1.0 はネットワークアドレス、10.0.1.1 は VPC ルーター用、10.0.1.2 は DNS サーバー用、10.0.1.3 は将来の利用のために AWS が予約、10.0.1.255 はブロードキャストアドレスです。つまり、/24 サブネットの 256 アドレスのうち、実際に使えるのは 251 アドレスです。この「5 つの予約」は、小さなサブネットほど影響が大きくなります。/28 サブネット (16 アドレス) では 5 つが予約されるため、使えるのは 11 アドレスだけです。約 31% が使えないことになります。Lambda の VPC 接続や NAT Gateway のように、少数の ENI (Elastic Network Interface) しか必要としないリソース用のサブネットでも、最低 /28 が必要です。この予約アドレスの存在を知らずにサブネットを設計すると、「IP アドレスが足りない」という問題に直面します。
CIDR 設計の失敗パターン
VPC の CIDR 設計で最も多い失敗は、CIDR の重複です。VPC Peering や Transit Gateway で VPC 間を接続する場合、接続する VPC の CIDR が重複しているとルーティングが不可能になります。デフォルトの 10.0.0.0/16 をすべての VPC に使い回すと、VPC 間の接続が一切できなくなります。オンプレミスネットワークとの接続 (Direct Connect、Site-to-Site VPN) でも同様の問題が発生します。オンプレミスのネットワークが 10.0.0.0/8 を使用している場合、VPC の CIDR が 10.x.x.x の範囲にあるとルーティングが衝突します。この場合、VPC には 172.16.0.0/12 や 100.64.0.0/10 (CGN 用アドレス、RFC 6598) の範囲を使用する必要があります。もう一つの失敗パターンは、サブネットの分割が細かすぎることです。/24 サブネットを大量に作ると、各サブネットの IP アドレスが 251 個に制限され、Auto Scaling でインスタンスが増えた際に IP アドレスが枯渇します。逆に、サブネットが大きすぎると、AZ 間の分散が不均等になるリスクがあります。
IPv6 と VPC の未来
AWS は 2016 年から VPC での IPv6 をサポートしています。IPv6 の VPC CIDR は /56 で、AWS が自動的に割り当てます。IPv6 のアドレス空間は 2^128 (約 340 澗) と事実上無限であるため、IPv4 のような CIDR 設計の悩みはありません。しかし、IPv6 への完全移行はまだ先の話です。多くの企業のオンプレミスネットワークが IPv4 のみであり、一部の AWS サービスも IPv6 を完全にはサポートしていません。現実的なアプローチは、デュアルスタック (IPv4 + IPv6) で VPC を構成し、新しいワークロードから段階的に IPv6 を導入することです。VPC の CIDR 設計は、一度決めると変更が困難 (VPC の CIDR は追加はできるが削除や変更はできない) なため、最初の設計が極めて重要です。マルチアカウント・マルチリージョン環境では、IPAM (IP Address Manager) を使用して組織全体の IP アドレス空間を一元管理することが推奨されます。ネットワーク設計の基礎を体系的に学ぶには、専門書籍 (Amazon)が参考になります。