セクション 01 · タスク 1.1 · SAP-C02-002

VPC・サブネット・IPアドレス設計

VPC CIDR / サブネット / パブリックサブネット / プライベートサブネット / IPv4 / IPv6 / CIDR重複 / ネットワークセグメンテーション

このページのゴール

このページを終えた時点で、次の設計判断ができる状態を目指します。

新しいVPCを作る。
何個のIPアドレスが必要か。
何個のAZを使うか。
ウェブ / アプリケーション / データベースをどのサブネットへ分けるか。
将来ほかのVPCやオンプレミスと接続する可能性があるか。
IPv4だけでよいか、IPv6を併用するか。
IPv6をインターネットへ公開するのか、プライベートネットワークだけで使うのか。

最終的には、現在必要なIP数だけではなく、将来の接続・拡張・分離まで含めてCIDRを決めることが重要になります。

1. Amazon VPCとは何か

Amazon VPCは、AWS上に作成する論理的に分離されたネットワークです。

VPCを作成するときにはIPv4 CIDRブロックを指定する必要があり、必要に応じてIPv6 CIDRブロックも関連付けられます。VPCはリージョン内のAZ全体にまたがります。

東京リージョン

VPC 10.0.0.0/16
│
├─ AZ-A
│   ├─ サブネット
│   └─ サブネット
│
├─ AZ-B
│   ├─ サブネット
│   └─ サブネット
│
└─ AZ-C
    ├─ サブネット
    └─ サブネット

ここで重要なのは、

VPC
→ リージョンにまたがる

サブネット
→ 必ず1つのAZ内に収まる

という違いです。1つのサブネットが複数AZへまたがることはできません。

2. VPCのCIDRをサブネットへ分割する

例えばVPCを、

10.0.0.0/16

で作成したとします。このVPC全体を1つの巨大なネットワークとして使うのではなく、必要に応じて、

VPC 10.0.0.0/16
│
├─ 10.0.0.0/24
├─ 10.0.1.0/24
├─ 10.0.10.0/24
└─ 10.0.11.0/24

のようにサブネットへ分割します。サブネットCIDRはVPC CIDRの範囲内でなければならず、同一VPC内のサブネットCIDR同士は重複できません。

3. CIDRの数字が意味するもの

IPv4は32ビットなので、CIDRのアドレス数は、

2^(32 - プレフィックス長)

CIDR	IPv4アドレス総数
/16	65,536
/20	4,096
/24	256
/26	64
/28	16

例えば、

10.0.0.0/24

なら、

2^(32 - 24)
= 2^8
= 256

個です。ただし、サブネットで実際にリソースへ割り当てられる数は総数とは異なります。

4. IPv4 VPC CIDRの現在の制約

AWSでVPCに指定できるIPv4 CIDRサイズは、

/16 ～ /28

です。

最大：/16 = 65,536アドレス
最小：/28 = 16アドレス

AWSはVPC作成時にはRFC 1918のプライベートIPv4範囲を利用することを推奨しています。

範囲	CIDR
10.0.0.0 ～ 10.255.255.255	10.0.0.0/8
172.16.0.0 ～ 172.31.255.255	172.16.0.0/12
192.168.0.0 ～ 192.168.255.255	192.168.0.0/16

ただしAWSでは、RFC 1918以外のパブリックルーティング可能なIPv4 CIDRをVPC CIDRとして使用すること自体は可能です。

ここで、

パブリックにルーティング可能な数字をVPC CIDRにした
= そのVPCのEC2へインターネットから直接アクセスできる

とはなりません。VPC CIDRのIPv4アドレスはVPC内部で利用され、インターネット接続にはゲートウェイ等の構成が別途必要になります。

5. VPCに使用できない主なIPv4範囲

使用不可	主な意味
0.0.0.0/8	特殊用途
127.0.0.0/8	ループバック
169.254.0.0/16	リンクローカル
224.0.0.0/4	マルチキャスト

またAWSは、一部サービスとの競合を避けるため 172.17.0.0/16 をVPC設計で避けることを案内しています。

SAP-C02では、この表をすべて機械的に暗記することより、既存ネットワークやAWSサービスと衝突しないアドレス空間を計画することの方が重要です。

6. サブネットのIPv4 CIDR

IPv4サブネットも、

/16 ～ /28

の範囲で作成できます。ただし通常のAWSサブネットでは、各IPv4サブネットの最初の4アドレスと最後の1アドレスをAWSが予約します。

例えば、

10.0.1.0/24

では、

10.0.1.0
10.0.1.1
10.0.1.2
10.0.1.3
10.0.1.255

が通常リソースへ割り当てられません。したがって、

/24
256個 - 5個
= 251個

が通常利用可能です。最小の /28 では、

16 - 5
= 11

となります。

※BYOIPでIPv4範囲をAWSへ持ち込む場合には予約アドレスの扱いに例外があるため、「どんな場合でも必ず5個失う」とまで一般化しません。

7. 最小サイズだけを選べばよいわけではない

現在10台しかEC2を使わないから、

/28
→ 11個使える
→ 足りる

としてしまうと、後で、

Application Load Balancer
NAT ゲートウェイ
RDS
ENI
コンテナ
自動スケーリング
障害時の一時リソース

などが追加されたときにアドレス不足になる可能性があります。

特にSAP-C02では、現在の台数ではなく、最大スケール時に必要なIP数を考えます。

8. VPC CIDRは後から単純に拡大できない

例えば、

10.0.0.0/24

で作ったVPCを、

10.0.0.0/16

へそのまま「拡張」することはできません。既存CIDRブロックのサイズ自体を増減することはできません。

一方、条件を満たす追加のIPv4 CIDRブロックをVPCへ関連付けることはできます。追加されたCIDRにはVPCルートテーブルへ local ルートが自動追加されます。

VPC
├─ プライマリ CIDR   10.0.0.0/16
└─ セカンダリCIDR 10.2.0.0/16

という構成は可能です。ただし、後からCIDRを追加すれば何でも解決するわけではありません。将来接続する他ネットワークとの重複や、AWSのCIDR関連付け制約を考える必要があります。

9. パブリックサブネット / プライベートサブネット

ここは非常に重要です。

パブリックサブネットとプライベートサブネットは、

IPアドレスの数字

で決まるわけではありません。

サブネットに関連付けられたルートテーブルによって決まります。

AWSでは、インターネットゲートウェイへのルートを持つサブネットをパブリックサブネット、持たないサブネットをプライベートサブネットと定義しています。

10. パブリックサブネット

IPv4なら典型的には、

宛先    ターゲット
10.0.0.0/16    local
0.0.0.0/0      igw-xxxxxxxx

サブネット
  │
  │ 0.0.0.0/0
  ▼
インターネットゲートウェイ
  │
  ▼
インターネット

のようにインターネットゲートウェイへのルートを持つため、パブリックサブネットと呼ばれます。

11. パブリックサブネットならEC2が必ずインターネットへ出られるわけではない

IPv4でEC2がインターネットと直接通信するには、ルーティングだけでなく、

パブリックIPv4アドレス
または
Elastic IPアドレス

も必要になります。

パブリックサブネット
+
インターネットゲートウェイ
+
0.0.0.0/0 ルート

が存在しても、そのEC2がプライベートIPv4しか持っていなければ、IPv4で直接インターネットとは通信できません。

12. プライベートサブネット

例えば、

宛先    ターゲット
10.0.0.0/16    local

しかなく、インターネットゲートウェイへのルートを持たない場合はプライベートサブネットです。

インターネット
   ×
   │
プライベートサブネット

ただし、

プライベートサブネット = インターネットを一切利用できない

という意味ではありません。

NAT ゲートウェイなどを経由して、プライベートサブネットから外向き通信だけを可能にする設計もできます。

13. サブネット分割は「公開 / 非公開」だけではない

サブネット分割には、ネットワークセグメンテーションという意味もあります。

例えば3層アプリケーションなら、

インターネット
   │
   ▼
パブリックサブネット
   ウェブ / ロードバランサー
        │
        ▼
プライベート アプリケーション サブネット
        │
        ▼
プライベート データベース サブネット

のように役割を分離します。

これにより、

インターネットから到達させる層
アプリケーション内部だけで使用する層
データベースを配置する層

を分けられます。

ただし、サブネットに分けただけでセキュリティが完成するわけではありません。ルートテーブル、セキュリティグループ、ネットワークACLなども合わせて設計します。

14. AZごとにもサブネットを分ける

複数AZ配置を実際のVPCへ適用すると、

                 VPC 10.0.0.0/16

          AZ-A                    AZ-B
           │                       │
   パブリックサブネット A         パブリックサブネット B
   10.0.0.0/24            10.0.1.0/24

   アプリ サブネット A            アプリ サブネット B
   10.0.10.0/24           10.0.11.0/24

   DB サブネット A             DB サブネット B
   10.0.20.0/24           10.0.21.0/24

のようになります。

重要なのは、

ウェブ用サブネット
アプリケーション用サブネット
データベース用サブネット

という機能の分離と、

AZ-A
AZ-B

という障害範囲の分離を組み合わせることです。

15. IPv6もIPアドレス設計の対象

VPC設計ではIPv4だけでなくIPv6も考えます。現在のAmazon VPCでは、VPCはIPv4のみまたはデュアルスタック、サブネットはIPv4のみ・デュアルスタック・IPv6のみを要件に応じて選択できます。

対象	IPv4のみ	デュアルスタック	IPv6のみ
VPC	○	○	×
サブネット	○	○	○

重要なのは、IPv6だから別物として扱うのではなく、必要なアドレス空間を設計することです。

16. パブリック IPv6とプライベート IPv6

現在のAmazon VPCでは、パブリック IPv6とプライベート IPv6の両方を利用できます。パブリック IPv6はAWSからインターネットへ広告されるアドレス空間ですが、パブリック IPv6を持つだけでインターネットから到達可能になるわけではありません。

IPv6アドレス
+
ルート
+
インターネットゲートウェイ
+
セキュリティ制御
↓
実際の到達性

したがって、アドレスの種類と通信経路が成立しているかを分けて判断します。

AWS内やハイブリッドネットワークではIPv6を使いたい一方、パブリックインターネットへAWSから広告したくない場合は、Amazon VPC IPアドレスマネージャー（IPAM）を利用したプライベート IPv6を評価できます。プライベート IPv6ではULAやプライベート GUAを利用でき、AWSからパブリックインターネットへ広告されません。

インターネットへAWSから広告する
→ パブリックIPv6

インターネットへAWSから広告しない
→ プライベートIPv6を評価
   → IPAM

17. IPv6 CIDRの現行仕様

現在のAmazon VPCでは、IPv6 CIDR サイズはアドレスの割り当て方式も含めて判断します。IPAM / BYOIP等を含むVPCのIPv6 CIDRは /44〜/60 を4ビット刻みで設計できます。一方、AmazonのIPv6 プールからAmazon提供のIPv6 CIDRを要求する代表的な構成では、Amazonから /56 が割り当てられます。

対象	IPv6 CIDR
VPC	/44〜/60、4ビット刻み
サブネット	/44〜/64、4ビット刻み

サブネットは /44〜/64 を4ビット刻みで利用できるため、IPv6 サブネット = 必ず /64 ではありません。同時に、Amazon提供のIPv6 CIDRの代表値である /56 をすべてのIPv6 VPCへ一般化もしません。割り当て元と必要なネットワーク規模を確認します。

18. IPv4とIPv6で共通する設計判断

判断	IPv4	IPv6
CIDR設計	必要	必要
サブネット設計	必要	必要
ルート設計	必要	必要
ネットワーク分離	必要	必要
インターネット到達性	アドレスとルート等を確認	アドレスとルート等を確認
プライベートアドレス	RFC 1918等	IPAMによるプライベート IPv6も利用可能
将来ネットワークとの重複	事前に考慮	事前に考慮

必要なアドレス空間
↓
サブネット
↓
ルート
↓
ネットワーク分離
↓
将来接続

IPv4とIPv6では細かな仕様が異なりますが、アーキテクチャとして一体で設計する点は同じです。

19. CIDR重複がなぜ危険なのか

次の2つのVPCを考えます。

VPC-A
10.0.0.0/16

VPC-B
10.0.0.0/16

独立して使っている間は問題が表面化しないことがあります。

しかし将来、

VPC-A
   │
   └──── VPC-B

と接続しようとすると、

10.0.1.10

が、

VPC-A側なのか
VPC-B側なのか

判別できません。

20. VPCピアリングでは重複CIDRを接続できない

VPCピアリングでは、IPv4またはIPv6 CIDRが一致または重複するVPC間にピアリング接続を作成できません。

Transit Gatewayでも、重複するCIDRを持つVPC同士のルーティングはサポートされず、後からアタッチされた重複VPCのルートはTGWルートテーブルへ伝達されません。

VPC接続方式を選ぶ際にも、このCIDR重複が重要な制約になります。

このページで覚えるべきなのは、CIDR重複は、将来のアーキテクチャ選択肢そのものを減らすということです。

21. オンプレミスとの重複も考える

AWSだけ見てCIDRを決めてはいけません。

例えば企業ネットワークが既に、

10.0.0.0/8

を広く使用している場合、AWS側へ安易に、

10.0.0.0/16

を割り当てると、将来のVPNやAWS Direct Connect接続で問題になる可能性があります。

したがってVPC設計前に、

AWS内の既存VPC
+
他AWSアカウント
+
他AWSリージョン
+
オンプレミス
+
将来作成予定のネットワーク

まで確認します。

22. 「今は接続しない」は安全な理由にならない

SAP-C02では、

現在VPC同士は接続しないので、全AWSアカウントで 10.0.0.0/16 を使う

という設計は避けます。

将来、

組織統合
共有サービス
一元監視
Transit Gateway
Direct Connect
VPCピアリング

などが必要になったとき、CIDR重複が大きな再設計要因になります。

IPアドレス設計は、ネットワークを接続する前に行うアーキテクチャ設計です。

23. Amazon VPC IPアドレスマネージャー

VPC数やAWSアカウント数が増えてくると、

ExcelでCIDR管理

では重複・払い出しミスが起こりやすくなります。

Amazon VPC IPアドレスマネージャー（IPAM）は、AWS環境のIPアドレスを計画、追跡、監視するための機能です。

IPAMを使用すると、中央でCIDRプールを管理し、

企業IPプール
│
├─ 日本
│   ├─ 本番
│   └─ 開発
│
└─ 米国
    ├─ 本番
    └─ 開発

のように階層的な払い出しルールを構成できます。

24. IPAMが解決する問題

例えば100個のAWSアカウントがあり、各担当者が自由にCIDRを選択すると、

アカウント A → 10.0.0.0/16
アカウント B → 10.0.0.0/16
アカウント C → 10.1.0.0/16
アカウント D → 10.0.0.0/16

のような状態になり得ます。

IPAMでは、リソースCIDRの重複状態や、IPAMプールの割り当てルールへの準拠状態を監視できます。

SAP-C02で、

多数のAWSアカウント / VPCに対してIPアドレスを中央管理したい
重複を防ぎたい
割り当てルールを標準化したい

という要件なら、IPAMを検討します。

25. CIDR設計では「余らせる」ことにも意味がある

例えば、

VPC 10.0.0.0/16

を作ったからといって、最初からすべての範囲をサブネットへ割り当てる必要はありません。

例：

10.0.0.0/24   パブリック-A
10.0.1.0/24   パブリック-B

10.0.10.0/24  アプリ-A
10.0.11.0/24  アプリ-B

10.0.20.0/24  DB-A
10.0.21.0/24  DB-B

残り
→ 将来拡張用

としておけば、

3つ目のAZ
新しいアプリケーション層
新しいコンテナクラスター
新しいデータベース層

などへ対応しやすくなります。

26. ただし「とにかく巨大なVPC」にもしない

余裕を持つことは重要ですが、

全VPCを最大サイズ /16 にする

ことが常に最適なわけではありません。

例えば 10.0.0.0/8 のプライベート空間は有限であり、すべてのVPCへ過剰な範囲を配ると、多数のVPCを持つ企業ではアドレス空間を浪費します。

判断すべきなのは、

現在必要数
+
最大スケール
+
AZ数
+
将来追加する層
+
他ネットワークとの接続
+
組織全体のアドレス計画

です。

27. ネットワークセグメンテーションの設計例

企業が3AZを使用し、ウェブ / アプリケーション / データベースを分離したいとします。

VPC 10.20.0.0/16

              AZ-A            AZ-B            AZ-C

パブリック       10.20.0.0/24    10.20.1.0/24    10.20.2.0/24

アプリケーション  10.20.10.0/24   10.20.11.0/24   10.20.12.0/24

データベース     10.20.20.0/24   10.20.21.0/24   10.20.22.0/24


10.20.30.0～
       ↓
将来用として未割当

この設計では、

役割
×
AZ

でサブネットを分けています。

これにより、アプリケーション構造と障害分離の両方がアドレス設計から読み取りやすくなります。

28. 良いCIDR設計は人間にも読める

例えば、

10.20.10.0/24 → アプリ AZ-A
10.20.11.0/24 → アプリ AZ-B
10.20.12.0/24 → アプリ AZ-C

のように一定の規則を設けておくと、

ルートテーブル
ファイアウォール
Direct Connect
Transit Gateway
トラブルシューティング

を扱うときにも理解しやすくなります。

IPアドレス空間は単に「空いている数字」を割り当てるのではなく、運用可能なアーキテクチャとして設計する。

29. SAP-C02での判断フロー

新しいVPCを設計
      │
      ▼
既存AWS / オンプレミスのCIDRを確認
      │
      ▼
将来接続する可能性は？
      │
      ▼
重複しないCIDRを確保
      │
      ▼
最大リソース数を見積もる
      │
      ▼
AZ数を決める
      │
      ▼
ウェブ / アプリ / DBなど役割を分ける
      │
      ▼
パブリック / プライベートのルート要件を決める
      │
      ▼
IPv4のみ？
デュアルスタック？
IPv6専用サブネット？
      │
      ▼
IPv6はパブリックかプライベートか？
      │
      ▼
多数アカウント / VPCならIPAMを検討
      │
      ▼
将来拡張用のCIDRを残す

30. よくある失敗

失敗1：現在のEC2台数だけでサブネットサイズを決める

Auto Scaling、ENI、ロードバランサー、コンテナ、障害時リソースなどを考慮していません。

失敗2：全アカウントで同じ `10.0.0.0/16`

独立している間は動作しても、将来接続するとCIDR重複が問題になります。

失敗3：パブリックIPを持つからパブリックサブネット

誤りです。サブネット種別はインターネットゲートウェイへのルーティングで決まります。

失敗4：パブリックサブネットだからIPv4インターネット接続可能

EC2側にパブリックIPv4 / Elastic IPがなければIPv4の直接通信はできません。

失敗5：IPv6はすべてパブリック

現在はプライベートIPv6があります。

失敗6：IPv6サブネットは必ず `/64`

現在は /44～/64 の /4 刻みでサポートされます。

失敗7：パブリックIPv6なら必ずインターネットから到達可能

実際の到達性はルーティングやセキュリティ制御にも依存します。

失敗8：VPC CIDRが不足したら既存CIDRを拡大すればよい

既存CIDR自体のサイズは変更できません。条件を満たせば追加CIDRを関連付けます。

31. このページで最終的に判断できること

VPC
→ リージョン単位のネットワーク

サブネット
→ 1つのAZ内のIPアドレス範囲

パブリックサブネット
→ インターネットゲートウェイへのルートあり

プライベートサブネット
→ インターネットゲートウェイへのルートなし

IPv4 VPC
→ /16～/28

IPv4 サブネット
→ /16～/28

IPv6 VPC
→ /44～/60、/4刻み

IPv6 サブネット
→ /44～/64、/4刻み

パブリックIPv6
→ AWSからインターネットへ広告

プライベートIPv6
→ IPAM経由
→ ULA または プライベート GUA
→ AWSからインターネットへ広告しない

CIDR重複
→ 将来のVPC / ハイブリッド接続を阻害

大量のVPC
→ IPAMで中央管理を検討

最も重要なのは、CIDRは「今空いている数字」ではなく、将来どのネットワークと接続するかまで考えて設計することです。

主要AWS公式資料

理解確認

このページの内容を23問で確認します。

理解確認23問へ →

このページのゴール

1. Amazon VPCとは何か

2. VPCのCIDRをサブネットへ分割する

3. CIDRの数字が意味するもの

4. IPv4 VPC CIDRの現在の制約

5. VPCに使用できない主なIPv4範囲

6. サブネットのIPv4 CIDR

7. 最小サイズだけを選べばよいわけではない

8. VPC CIDRは後から単純に拡大できない

9. パブリックサブネット / プライベートサブネット

10. パブリックサブネット

11. パブリックサブネットならEC2が必ずインターネットへ出られるわけではない

12. プライベートサブネット

13. サブネット分割は「公開 / 非公開」だけではない

14. AZごとにもサブネットを分ける

15. IPv6もIPアドレス設計の対象

16. パブリック IPv6とプライベート IPv6

17. IPv6 CIDRの現行仕様

18. IPv4とIPv6で共通する設計判断

19. CIDR重複がなぜ危険なのか

20. VPCピアリングでは重複CIDRを接続できない

21. オンプレミスとの重複も考える

22. 「今は接続しない」は安全な理由にならない

23. Amazon VPC IPアドレスマネージャー

24. IPAMが解決する問題

25. CIDR設計では「余らせる」ことにも意味がある

26. ただし「とにかく巨大なVPC」にもしない

27. ネットワークセグメンテーションの設計例

28. 良いCIDR設計は人間にも読める

29. SAP-C02での判断フロー

30. よくある失敗

失敗1：現在のEC2台数だけでサブネットサイズを決める

失敗2：全アカウントで同じ 10.0.0.0/16

失敗3：パブリックIPを持つからパブリックサブネット

失敗4：パブリックサブネットだからIPv4インターネット接続可能

失敗5：IPv6はすべてパブリック

失敗6：IPv6サブネットは必ず /64

失敗7：パブリックIPv6なら必ずインターネットから到達可能

失敗8：VPC CIDRが不足したら既存CIDRを拡大すればよい

31. このページで最終的に判断できること

主要AWS公式資料

理解確認

失敗2：全アカウントで同じ `10.0.0.0/16`

失敗6：IPv6サブネットは必ず `/64`