【入門編】 CIDR（Classless Inter-Domain Routing）とIPアドレス設計 – クラウド＆コンテナネットワーク実践ガイド

「IPアドレスが足りない！」を未然に防ぐ。クラウド時代のCIDR設計・超入門

こんにちは！インフラエンジニアとして日々クラウドの海を泳いでいるSREです。

皆さんはクラウド環境で新しいプロジェクトを立ち上げるとき、VPC（仮想ネットワーク）を作る最初のステップで、こんな画面に遭遇しませんか？

「IPv4 CIDRブロックを入力してください」

正直なところ、最初は「とりあえず 10.0.0.0/16 でいいや！」と深く考えずに進めてしまいがちですよね。でも、その選択が数年後のあなたを苦しめる「負債」の種になるかもしれない……と言われたら、少し身構えてしまいますよね。

今日は、ネットワークの「番地」であるIPアドレスを、どうやって賢く、枯渇しないように割り振っていくのか。難しいビット計算は一旦置いておいて、身近な例えを交えながら紐解いていきましょう！

—

1. そもそも「CIDR」って何？郵便配達で例えてみよう

CIDR（サイダー）という言葉、呪文みたいで怖いですよね。でも、これは「住所の範囲指定」のことなんです。

例えば、ある大きなマンション（VPC）を想像してください。
そのマンション全体の住所が 10.0.0.0/16 だとします。

/16 という数字は、「左から16個のビット（部屋番号の固定部分）は絶対に動かさないでね」というルールです。
このルールを守ることで、そのマンションの中には約6万5千個もの「部屋（IPアドレス）」が作れることになります。

もし、ここを /24 にしてしまったらどうなるでしょう？
マンションの敷地が極端に狭くなり、たった256世帯しか住めない小さなアパートになってしまいます。クラウドの世界では、サーバーやコンテナが増えるたびに「部屋が足りない！」という悲劇が起こるわけです。

—

2. 賢いサブネットの切り分け：大・中・小の箱を用意する

VPCという「マンション」を手に入れたら、次は「サブネット」という「フロア」を作りましょう。ここでのポイントは、「用途ごとに箱の大きさを変える」ことです。

現場でよくある構成を例に、CIDRの設計を見てみましょう。

| 用途 | 推奨プレフィックス | 理由 |
| :— | :— | :— |
| フロントエンド（Web等） | /24 | サーバー台数が変動しやすいため、余裕を持たせる |
| バックエンド（API等） | /24 | 同上。拡張性を考慮 |
| データベース（RDS等） | /28 | データベースは台数が急増しないため、あえて小さくしてセキュリティを高める |

「データベースに /28？少なすぎない？」と思うかもしれませんが、ネットワークは広ければ良いというものではありません。「広すぎると、万が一どこかが乗っ取られた時の被害範囲が広がる」というデメリットもあるんです。まさに、「必要な分だけ確保する」のがプロの設計術です。

—

3. 実践！AWS VPC設定のサンプル

では、実際にAWSなどで構築する際のイメージをコード（Terraform風）で見てみましょう。

# VPC全体を確保（マンションの敷地）
resource "aws_vpc" "main_vpc" {
  cidr_block = "10.0.0.0/16" # 10.0.0.0 ～ 10.0.255.255 まで使える広大な土地
  tags = { Name = "production-vpc" }
}

# Webサーバー用サブネット（大きめに確保）
resource "aws_subnet" "web_subnet" {
  vpc_id     = aws_vpc.main_vpc.id
  cidr_block = "10.0.1.0/24" # 10.0.1.0 ～ 10.0.1.255（256個の住所）
  tags = { Name = "web-subnet" }
}

# DB用サブネット（小さく絞って安全に）
resource "aws_subnet" "db_subnet" {
  vpc_id     = aws_vpc.main_vpc.id
  cidr_block = "10.0.2.0/28" # 10.0.2.0 ～ 10.0.2.15（16個の住所）
  tags = { Name = "db-subnet" }
}

このように、10.0.1.0/24 と 10.0.2.0/28 を綺麗に分けることで、アドレスが重複することなく、整然としたネットワークが作れます。

—

4. なぜ「拡張性」を考える必要があるのか？

初学者の皆さんが一番陥りやすい罠が、「今のプロジェクトだけで考えてしまうこと」です。

他のVPCと「ピアリング（ネットワーク接続）」をする予定はありませんか？
将来、オンプレミスの社内ネットワークとVPNで繋ぐ予定はありませんか？

もし、社内ネットワークが既に 10.0.0.0/16 を使っていたら、後から繋ごうとした時に「IPアドレスが被っていて接続できない！」という絶望的な事態になります。

SREからのアドバイス：
「将来的に他の拠点と繋ぐ可能性があるなら、被らないアドレス帯（例えば 172.16.0.0/12 など）を最初から選んでおく」のが、百戦錬磨のエンジニアの知恵です。

—

まとめ：ネットワーク設計は「地図作り」

ネットワークのCIDR設計は、都市計画に似ています。
最初は小さな町でも、数年後には高層ビルが立ち並ぶ大都会になるかもしれません。その時に「道路が狭くて消防車が通れない！」とならないように、「今は余裕があるけれど、将来を見越して少し大きめに区切っておく」。

この感覚を大切にしてください。

今日の内容で、「IPアドレスの割り当てって、意外と人間味のある作業なんだな」と感じていただけたら嬉しいです。一歩ずつ、強固なインフラを作っていきましょう！

それでは、また次回の記事でお会いしましょう。Happy Hacking!