Dev Study
AWSサービスの内部原理 コース

106. VPCは32bitの数値空間の区画である — CIDRという『ネットワーク部/ホスト部』の線引き

マネージドの仮想ネットワークを作るとき最初に求められる「10.0.0.0/16」という呪文が、実は32bitの整数をどこで折るかという2進数の算数だったことを、ビット列の図で追っていきます。

① IPアドレスは「4つの数字」ではなく「32bitの整数」である

10.0.0.1見慣れたドット区切り表記
各数字を8bit(1バイト)の2進数に展開すると…
32bitの整数8bitずつ4回に区切って読んだもの
桁の重みで足し算すると1つの整数になる
00001010= 10
00000000= 0
00000000= 0
00000001= 1
167,772,161= 10×2^24 + 0×2^16 + 0×2^8 + 1
単一の整数
  • 8bitで表せる範囲は 0〜255(2^8 = 256通り)。だから各数字は0〜255に収まる。
  • 32bit全体で表せるアドレスは 2^32 = 約43億個。

「10.0.0.1」は4つの数字ではなく、32bitの整数を8bitずつ4回に区切って人間が読みやすくしただけのもの。IPアドレスの世界では数値そのものが住所になる——DynamoDB編ではキーをハッシュで数値に変換して住所を決めたが、ここでは数値がそのまま住所である、という対になる発想。

② スラッシュの数字が「どこで折るか」を決める — CIDR表記

10.0.0.0/16スラッシュの後ろの16が線引きの位置
ネットワーク部左16bit = 区画の住所
00001010 00000000 — ここは固定
ホスト部右16bit = 区画内の番号
00000000 00000001 — 自由に使える
  • 「/16」= 左から16bitがネットワーク部、という意味。CIDR = Classless Inter-Domain Routing(クラスレス・ドメイン間ルーティング)表記。
  • ネットワーク部が同じアドレスは「同じ区画に属する」。ホスト部だけが各ホストで異なる。

CIDR表記のスラッシュの数字は、32bitの列を「ネットワーク部(区画の住所)」と「ホスト部(区画内の番号)」のどこで折るかを指定する目盛り。VPCとは、この線引きで切り出された32bit数値空間の一区画にほかならない。

③ プレフィックスが1増えるごとにアドレス数が半分になる — /16〜/28の階段

/1665,536アドレス
VPCで許される最大
…以降も半分ずつ縮んでいく
/1732,768
/1816,384
/198,192
/204,096
/2816アドレス
VPCで許される最小
  • アドレス数 = 2^(32 − プレフィックス長)。/16 なら 2^16 = 65,536、/28 なら 2^4 = 16。
  • プレフィックスが1増える = 線引きが右に1bitずれる = ホスト部が1bit縮む = 表せる番号が半分になる。
  • VPC作成時はIPv4 CIDRブロックの指定が必須。許される範囲は公式に「/16(65,536アドレス)〜/28(16アドレス)」。

プレフィックス長を1増やすと、ホスト部のビットが1つ減り、区画に入るアドレス数がきっちり半分になる——すべて2の冪で動く。プレフィックス長とアドレス数が2の冪で対応するのは、キャッシュ編の16,384スロット(2^14)で見た「2進数で世界を切る」発想と同じ。

④ どこから切り出すか — 推奨レンジと、指定できない予約区画

推奨レンジRFC 1918 のプライベートレンジから切り出す
10/810.0.0.0〜10.255.255.255
172.16/12172.16.0.0〜172.31.255.255
192.168/16192.168.0.0〜192.168.255.255
指定不可の予約区画用途が予約されていて区画の住所に使えない
127.0.0.0/8ループバック(自分自身)
169.254.0.0/16リンクローカル
コンテナ編で暗記した 169.254.169.254(IMDS)はこの区画の住人だった
224.0.0.0/4マルチキャスト
0.0.0.0/8(これも不可)
172.17.0.0/16Cloud9・SageMaker AI が使用
衝突しやすいのでVPC作成時に使わないこと(公式注記)
  • RFC 1918 の3レンジは公式ドキュメントの表そのまま。VPC作成時はこれらからの切り出しが推奨。
  • 指定不可の区画は「用途が予約されているから」区画の住所には使えない。169.254.0.0/16 はリンクローカルアドレス範囲。
  • 172.17.0.0/16 は一部のAWSサービス(AWS Cloud9・Amazon SageMaker AI)が使うため、IPアドレス衝突を避けるためVPC作成時に使わないことと公式が注記。

区画を切り出す場所には推奨(RFC 1918のプライベートレンジ)と禁止(ループバック・リンクローカル・マルチキャストなどの予約区画)がある。コンテナ編でマジックナンバーとして暗記していた 169.254.169.254 は、実はリンクローカルという予約区画の住人——だからVPCの住所には使えなかった、という種明かし。

⑤ ホスト部のビットは区画の名前には使えない — 自動で正規形に直される

100.68.0.18/18CLI/API で指定
ホスト部のビットは「区画の名前」には使えない → 全部0に戻す
左18bit01100100 01000100 00
ネットワーク部 — ここで折る
右14bit000000 00010010
ホスト部に 18(=…10010)が乗っている
100.68.0.0/18正規形(canonical form)
  • 公式仕様: CLI/APIで 100.68.0.18/18 と指定すると、自動的に正規形 100.68.0.0/18 に修正される。
  • 区画の住所(ネットワーク部)を名乗るには、ホスト部は全ビット0でなければならない。ホスト部に値が乗っていると「区画そのもの」ではなく「区画内の1台」を指してしまう。

CIDRブロックは区画の「住所」なので、ホスト部のビットには意味がない——だからAWSはホスト部を0に戻した正規形へ自動修正する。この挙動こそ「ネットワーク部/ホスト部という線引きが本当に効いている」何よりの証拠で、②の線引きが図の上の話ではなくAPIの実挙動として現れる。

⑥ 区画は後から足せる — セカンダリCIDRと自動で載る local ルート

10.0.0.0/16プライマリCIDR(作成時)
追加した瞬間、VPCの各ルートテーブルに自動で1行載る
10.2.0.0/16セカンダリCIDR(追加)
ただし、できないことも明確
10.0.0.0/16Target: local(プライマリ)
VPCのルートテーブル
10.2.0.0/16Target: local(自動追加)
サイズ変更は不可既存ブロックの拡大・縮小はできない
プライマリは不可最初に作った区画は取り外せない
  • セカンダリCIDRの追加サイズも /16〜/28。既存CIDRと重複してはいけない。
  • 「既存のCIDRブロックはサイズを増減できない」「最初にVPCを作ったCIDR(プライマリ)は取り外せない」と公式明記。
  • CIDRを関連付けると「宛先=そのCIDR / ターゲット=local」のルートがVPCの各ルートテーブルに自動追加される(ルートテーブルの仕組みは次々レッスンで詳しく)。
  • IPv6は範囲を選べない: Amazonのプールから借りる方式で、/44〜/60 を /4 刻みで最大5個まで関連付けできる(例: 2001:db8:1234:1a00::/56 のように割り当てられ、範囲は自分では選べない)。

区画は固定ではなく後からCIDRブロックを足せる——ただし既存ブロックのサイズ変更もプライマリの取り外しも不可。追加した区画には「そのCIDR→local」というルートが自動で載り、VPC内の通信が成立する(この local ルートの意味は次々レッスンの主役)。マネージドの仮想ネットワークで最初に下す設計判断は、GUIの難しいボタンではなく「32bitをどこで折るか」という2進数の算数だった。

公式ドキュメントで詳しく ↗