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 アドレスの背後に多数のデバイスを配置できるようになり、アドレス枯渇を緩和しました。ここで混同されやすいのが、AWS における 2 つの「デフォルト」です。アカウント作成時に各リージョンへ自動で用意されるデフォルト VPC の CIDR は 172.31.0.0/16 で、これは 172.16.0.0/12 の範囲から切り出されています (サブネットは各 AZ に /20 で作成されます)。一方、マネジメントコンソールで VPC を新規作成するときにウィザードが初期入力する値が 10.0.0.0/16 で、こちらは 10.0.0.0/8 の範囲から切り出した値です。どちらも /16 ですが、出自の異なる別物です。
| CIDR 表記 | アドレスの範囲 | アドレス数 | VPC 設計での位置づけ |
|---|---|---|---|
| 10.0.0.0/8 | 10.0.0.0 〜 10.255.255.255 | 約 1,677 万 | 最も広い。コンソールのウィザードが初期入力する 10.0.0.0/16 はこの中から切り出した値 |
| 172.16.0.0/12 | 172.16.0.0 〜 172.31.255.255 | 約 104 万 | 中間の広さ。デフォルト VPC の 172.31.0.0/16 はこの範囲に含まれる。他組織との重複を避けたいときの逃げ場にもなりやすい |
| 192.168.0.0/16 | 192.168.0.0 〜 192.168.255.255 | 約 6.5 万 | 家庭用ルーターで最も使われるため、オンプレミス側との衝突を招きやすい |
なぜ /16 なのか - 大きすぎず小さすぎない絶妙なサイズ
/16 の CIDR ブロックは 65,536 個の IP アドレスを含みます。AWS がデフォルト VPC とコンソールのウィザードの双方で /16 を採用しているのは、ほとんどのワークロードに十分な IP アドレス空間を提供しつつ、/8 の親空間から 256 個の /16 ブロックを切り出せるバランスの良さにあります。VPC の CIDR は /16 から /28 まで指定可能です。/28 は 16 アドレス (うち使用可能は 11) で、最小の VPC です。/16 は 65,536 アドレスで、VPC に指定できる最大サイズです。実際には、/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 アドレスが足りない」という問題に直面します。
| アドレス | サブネット内の位置 | 用途 |
|---|---|---|
| 10.0.1.0 | 先頭 | ネットワークアドレス |
| 10.0.1.1 | 先頭から 2 番目 | VPC ルーター |
| 10.0.1.2 | 先頭から 3 番目 | DNS サーバー |
| 10.0.1.3 | 先頭から 4 番目 | 将来の利用のために AWS が予約 |
| 10.0.1.255 | 末尾 | ブロードキャストアドレス |
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 アドレスが枯渇します。逆に、1 つのサブネットを大きく取りすぎるのも設計としては窮屈です。サブネットは 1 つの AZ にしか属せないため、マルチ AZ 構成にするには AZ ごとに別のサブネットを切る必要があり、最初に VPC の CIDR を使う AZ 数で等分しておかないと、後から AZ を増やすときに空き range が残っていないという事態になります。
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 アドレス空間を一元管理することが推奨されます。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。