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

VPCアドレッシングの深淵：RFC 1918の設計が「ネットワークの寿命」を決める

クラウドインフラの設計において、VPCのIPアドレス設計を「適当なクラスCでいいか」と軽視してはいないだろうか。オンプレミスからクラウドへ移行する際、あるいは急成長するスタートアップがマルチリージョン・マルチクラウド化する際、真っ先に足枷となるのがこの「IPアドレス枯渇」と「ルーティングの衝突」だ。

RFC 1918に基づくプライベートIP設計は、単なる「箱の割り当て」ではない。それは、将来のサービスメッシュ、クロスアカウントVPCピアリング、そしてVPN接続を通じたオンプレミスとの接続性を考慮した、極めて戦略的な「論理的領土の確定」である。

今回は、単なる設計論を超え、パケットの挙動とカーネルレベルのチューニングまで踏み込んだ「攻めのVPCアドレッシング」を解説する。

—

1. RFC 1918の再考：アドレス重複という「技術的負債」との戦い

10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。これらのアドレス空間は広大に見えるが、AWSやGCPにおける「将来のVPN接続」や「買収・合併によるネットワーク統合」を考慮すると、実は非常に脆い。

特に、安易に 192.168.0.0/16 を選定するのは避けるべきだ。多くの自宅ルーターや小規模オフィスネットワークがこの範囲を採用しており、将来的にVPN接続を行う際、ルーティングテーブルの衝突で頭を抱えることになるのは目に見えている。

ベストプラクティス：階層的アドレッシングの構築

大規模な環境では 10.0.0.0/8 をベースに、サブネットごとに第2オクテットをリージョン、第3オクテットを環境（Staging/Prod）や機能（App/DB/DMZ）に割り当てる設計が定石だ。

10.10.0.0/16: Tokyo Region
10.11.0.0/16: US-East Region
10.10.10.0/24: App Tier (Prod)
10.10.20.0/24: DB Tier (Prod)

このように設計することで、CIDRブロックの集約が可能となり、ルートテーブルの肥大化を防げる。ルーターのオーバーヘッドを減らすことは、マイクロ秒単位のパケット処理遅延を削ることに直結する。

—

2. パケットレベルの最適化：TCPバッファとカーネルチューニング

VPC内でアプリケーションが期待するパフォーマンスを出せない場合、原因の多くはアプリケーションレイヤーではなく、LinuxカーネルのTCPスタックの「デフォルト値」にある。

特にコンテナネットワーク（Overlay Network）を通る通信では、TCPウィンドウサイズがボトルネックになりやすい。VPC内の通信であっても、高スループットを求めるなら以下のカーネルパラメーターを調整してほしい。

# sysctl.conf での推奨設定
# TCP受信ウィンドウの最小・デフォルト・最大値を拡大
net.ipv4.tcp_rmem = 4096 87380 16777216
# TCP送信バッファの拡大
net.ipv4.tcp_wmem = 4096 65536 16777216
# 高速ネットワークでの輻輳制御アルゴリズムを BBR に変更
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

BBR（Bottleneck Bandwidth and Round-trip propagation time）は、パケットロスを輻輳と誤認する従来のリノアルゴリズムと異なり、実際の帯域幅とRTTを計測して送信レートを動的に制御する。VPC間の相互接続や、バックボーンが太いクラウドネットワークにおいて、その真価は圧倒的だ。

—

3. TLSハンドシェイクの短縮とMTUの最適化

VPC内の通信において、TLS 1.3の採用は必須だ。TLS 1.3はハンドシェイクを1往復（1-RTT）に短縮しているが、ネットワーク層のMTU設定が適切でないと、パケットの断片化（Fragmentation）が発生し、RTTが増大する。

特に、トンネリング（VXLAN/Geneve）を使用するK8sネットワークでは、オーバーヘッド分を考慮してMTUを 1450 等に絞る必要がある。これを見落とすと、TCPの3ウェイハンドシェイク後のデータ転送でパケットがドロップし、通信が不安定になる「隠れたネットワークトラブル」に直面する。

MTU確認のためのコマンド例

# パケットのフラグメンテーションを許容しない（DFフラグ）Pingテスト
# MTU 1500の環境なら、ヘッダー分を引いて1472で試行する
ping -M do -s 1472 <ターゲットIP>

—

4. 脆弱性回避：VPC内ネットワーク境界の「ゼロトラスト」

VPC内だからといって安全だという神話は、今や崩壊している。攻撃者は一度侵入すると、L2/L3レベルでネットワークをスキャンし、横展開（Lateral Movement）を試みる。

セキュリティグループの最小権限: 0.0.0.0/0 を許可するルールは論外だ。必ず「特定のセキュリティグループID」または「特定のIPレンジ」に絞る。
フローログの分析: VPC Flow LogsをAmazon Athenaなどでクエリし、異常な接続試行を検知するパイプラインを構築する。
マイクロセグメンテーション: Kubernetes環境であれば、NetworkPolicy を利用し、Pod間通信を明示的に許可する構成を徹底せよ。

# NetworkPolicyの例：DBへの通信をAppのPodからのみに制限
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-app-to-db
spec:
  podSelector:
    matchLabels:
      role: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: app
    ports:
    - protocol: TCP
      port: 5432

—

結びに代えて：アーキテクトとしての矜持

VPCの設計は、一度デプロイすると変更が極めて困難な「インフラの骨格」だ。今回触れたRFC 1918の計画的な割り当て、カーネルレベルのTCP最適化、そしてゼロトラストに基づいたネットワーク境界の制御。これらはすべて、将来の自分たちを技術的負債から守るための防波堤である。

ネットワークは「繋がって当たり前」の世界ではない。パケットが一秒間に何回カーネルを通り、どれだけのバッファを経て目的地に届くのか。その内部挙動を想像し、設計に落とし込める者だけが、真にスケーラブルなシステムを構築できるのだ。

さあ、あなたの次のインフラ設計が、より堅牢で、より速いものになることを期待している。