【入門編】プライベートIPアドレス範囲（RFC 1918）のVPC内割当ルール – クラウド＆コンテナネットワーク実践ガイド

VPCネットワークの「住所」設計：迷子にならないIPアドレスの割り当て方

こんにちは！クラウドの海を泳ぐSREの皆さん、そしてこれからインフラという地図を描こうとしている初学者の皆さん。

クラウドの世界に飛び込んでまず直面する難所、それは「VPCのIPアドレス設計」ですよね。「どこに何を置くか」という住所の割り当ては、家を建てるときの土地の区画整理と同じです。ここを適当にしてしまうと、あとでサービスが大きくなったときに「あれ、あっちのビルと住所が被っちゃった！」という悲劇（IPアドレスの重複）が起きてしまいます。

今回は、VPC内のIPアドレス設計を、郵便配達の仕組みに例えて紐解いていきましょう。

—

郵便配達で考える「プライベートIPアドレス」

私たちの住む現実世界には、郵便番号や番地がありますよね。でも、マンションの部屋番号（例：101号室）はどうでしょうか？別のマンションにも同じ「101号室」は存在しますよね。

クラウドの世界における「プライベートIPアドレス」は、まさにこの「マンションの部屋番号」です。外の世界（インターネット）には出られないけれど、建物の中（VPC内）では唯一無二の場所を示すためのもの。

この「建物内だけで使っていいよ」と約束されたルールが、有名な RFC 1918 という規格です。

使える「部屋番号」の範囲は3種類

以下の3つが、プライベートネットワークで使っていいよ！と決められた「魔法の住所」です。

10.0.0.0/8（10.0.0.0 ～ 10.255.255.255）：超巨大な団地。大規模なシステム向け。
172.16.0.0/12（172.16.0.0 ～ 172.31.255.255）：中規模なマンション。
192.168.0.0/16（192.168.0.0 ～ 192.168.255.255）：個人の一軒家や小規模なオフィス向け。

「/（スラッシュ）」の後ろの数字は、「どこまでが建物の名前（ネットワーク部）」で「どこからが部屋番号（ホスト部）」かを決める境界線です。今は「数字が小さいほど、たくさんの部屋が作れる！」と覚えておけばOKです。

—

VPC設計で守るべき「3つの鉄則」

現場でSREが設計するとき、以下の3つを必ず意識しています。これさえ守れば、将来のトラブルを未然に防げます。

1. 将来を見据えた「余裕を持たせた切り分け」

最初からカツカツの住所割り当てをすると、サーバーが増えるたびに「住所変更」という地獄の作業が待っています。少し大きめの範囲を確保しておきましょう。

2. 他のVPCと重複させない

将来的にVPNや専用線で他のクラウドやオンプレミスと繋ぐとき、相手と同じ住所だとパケットはどこに行っていいか分からなくなります。なるべく被りにくい 10.0.0.0/8 を使い、部署や環境ごとに綺麗に分けるのが王道です。

3. サブネットは「役割」で分ける

郵便配達員さんが「手紙はポストへ、荷物は宅配ボックスへ」と分けるように、VPC内も「公開サーバー用」「DBサーバー用」とサブネットを分けます。

—

実践：AWS VPCでのIPアドレス設計例

例えば、AWSで 10.0.0.0/16 という広大な土地を確保し、それを小分けにする設定（Terraformイメージ）を見てみましょう。

# VPCの土台を作る（10.0.0.0/16）
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16" # 全体の住所範囲
  tags = { Name = "Main-VPC" }
}

# パブリックサブネット（Webサーバー用）
resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24" # 10.0.1.0～10.0.1.255を割り当て
  tags = { Name = "Public-Subnet" }
}

# プライベートサブネット（DBサーバー用）
resource "aws_subnet" "private" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.2.0/24" # 10.0.2.0～10.0.2.255を割り当て
  tags = { Name = "Private-Subnet" }
}

このように、/24 という区画を綺麗に並べていくと、後から見ても「ああ、10.0.1.x はWeb用、10.0.2.x はDB用だな」と一目でわかりますよね。

—

最後に：完璧を目指さず「拡張性」を愛そう

インフラ設計に「絶対にこれが正解！」という唯一の回答はありません。しかし、「将来、自分以外の誰かが見てもすぐに構造が理解できるか？」という視点は、どんな優れたツールを使うよりも重要です。

これからVPCを作るなら、まずは紙に「どんな部屋（サブネット）がいくつ必要か」を描いてみてください。最初は少し難しく感じるかもしれませんが、パケットが迷わず目的地に届く仕組みを設計するのは、インフラエンジニアにとって一番ワクワクする瞬間です。

さあ、次はあなたの番です。最高のネットワークの地図を描いてみませんか？

応援しています！