クラウド時代のサブネット設計完全ガイド：知っておくべきベストプラクティス集 🌐

クラウドコンピューティングの普及に伴い、ネットワークインフラの構築・管理方法は大きく変化しました。特に、仮想プライベートクラウド（VPC）や仮想ネットワーク（VNet）といったクラウド上のプライベートネットワーク空間におけるサブネット設計は、システムの可用性、セキュリティ、拡張性、そしてコスト効率に直結する非常に重要な要素です。

オンプレミス環境でのネットワーク設計経験がある方も、クラウド特有の考慮事項やベストプラクティスを理解しておく必要があります。クラウドでは、物理的な制約から解放される一方で、IPアドレス空間の管理、セキュリティ境界の設定、可用性ゾーン（AZ）の活用など、新たな課題や設計ポイントが登場します。🚀

本記事では、AWS (Amazon Web Services), Azure (Microsoft Azure), GCP (Google Cloud Platform) といった主要なクラウドプラットフォームに共通して適用できる、サブネット設計のベストプラクティスを順序立てて、丁寧に解説していきます。適切なサブネット設計を行うことで、将来の拡張や変更にも柔軟に対応できる、堅牢で効率的なクラウドネットワーク基盤を構築しましょう。

サブネット設計の詳細に入る前に、基本的なネットワークの概念を簡単におさらいしておきましょう。💡

IPアドレス (IPv4)

インターネットやローカルネットワーク上で、コンピュータやデバイスを識別するための番号です。通常、192.168.1.1 のように、0から255までの数値を4つ、ドット（.）で区切って表現されます（32ビット）。

サブネットマスク

IPアドレスのどこまでがネットワーク部（グループ全体のアドレス）で、どこからがホスト部（グループ内の個々のアドレス）かを区別するための値です。255.255.255.0 のように表現されます。この例では、最初の24ビットがネットワーク部、残りの8ビットがホスト部を示します。

CIDR (Classless Inter-Domain Routing) 表記

IPアドレスとサブネットマスクをより簡潔に表現する方法です。「サイダー」と読みます。192.168.1.0/24 のように、IPアドレスの後ろにスラッシュ（/）とネットワーク部のビット数を記述します。/24 は、サブネットマスク 255.255.255.0 と同じ意味で、先頭から24ビットがネットワーク部であることを示します。このネットワークには、192.168.1.0 から 192.168.1.255 までの256個のIPアドレスが含まれます（ただし、ネットワークアドレスとブロードキャストアドレスを除く）。

CIDRの数値が小さいほど（例：/16）、ネットワーク部のビット数が少なくなり、ホスト部のビット数が多くなるため、より多くのIPアドレスを含む大きなネットワーク範囲を示します。逆に、数値が大きいほど（例：/28）、ネットワーク範囲は狭くなります。

• /16: 65,536個のIPアドレス (例: 10.0.0.0/16)
• /24: 256個のIPアドレス (例: 192.168.1.0/24)
• /28: 16個のIPアドレス (例: 172.16.0.0/28)

クラウド環境でサブネットを設計する際には、オンプレミスとは異なるいくつかの重要な点を考慮する必要があります。

1. VPC/VNet の CIDR 設計：将来を見据えた計画 🔭

VPC (AWS, GCP) や VNet (Azure) は、クラウド上に構築するプライベートなネットワーク空間です。このVPC/VNetに割り当てるCIDRブロックは、後から変更することが非常に困難（または不可能）な場合が多いです。そのため、初期設計が極めて重要になります。

• 将来の拡張性： 現在必要なIPアドレス数だけでなく、将来的なサービス拡大、リージョン展開、M&Aによるネットワーク統合などを考慮し、十分に大きなCIDRブロックを確保します。一般的には、/16 などの大きな範囲を割り当てることが推奨されます。
• 重複の回避： オンプレミス環境や、接続可能性がある他のVPC/VNet、パートナー企業のネットワークなどとIPアドレス範囲が重複しないように、慎重にCIDRブロックを選定する必要があります。特に、RFC 1918で定義されているプライベートIPアドレス範囲 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) を使用する場合、組織内で利用する範囲を計画的に管理することが重要です。

2. サブネット分割の目的：境界と可用性 🛡️

VPC/VNet内に作成するサブネットは、ネットワークをより小さなセグメントに分割します。この分割には、主に以下の目的があります。

• セキュリティ境界の確立： サブネットごとに異なるネットワークアクセスコントロールリスト (NACL) やルートテーブルを適用することで、通信を制御し、セキュリティを高めます。例えば、インターネットからアクセス可能なWebサーバーを配置する「パブリックサブネット」と、データベースサーバーなど内部リソースのみを配置する「プライベートサブネット」を分離します。
• ルーティング制御： サブネットごとにルートテーブルを関連付けることで、トラフィックの経路を制御します。例えば、プライベートサブネットからのインターネットアクセスはNATゲートウェイを経由させる、オンプレミスへの通信はVPN/専用線ゲートウェイを経由させる、といった制御が可能です。
• 可用性の向上 (可用性ゾーン)： 多くのクラウドプロバイダーは、物理的に独立したデータセンター群である「可用性ゾーン (AZ)」を提供しています。重要なシステムを複数のAZに分散配置し、各AZにサブネットを作成することで、単一AZの障害に対する耐性を高めることができます。例えば、WebサーバーをAZ-AのサブネットとAZ-Bのサブネットに配置し、ロードバランサーで負荷分散します。
• リソース種別/役割による分割： Web層、アプリケーション層、データベース層、管理用、監視用など、リソースの役割や種類に応じてサブネットを分割することで、管理性やセキュリティポリシーの適用が容易になります。

3. IPアドレスの枯渇対策：計画的な管理 🔢

特に大規模な環境や、急速にサービスが拡大する場合、IPアドレスの枯渇は深刻な問題となり得ます。

• 適切なサブネットサイズ： サブネットを作成する際、将来的なリソース増加を見越して、小さすぎないCIDRサイズを選定します。例えば、/24 (約250ホスト) を基本とし、必要に応じて調整します。ただし、無駄に大きすぎるサブネットはIPアドレス空間の浪費につながるため、バランスが重要です。
• IPアドレス管理 (IPAM – IP Address Management)： どのVPC/VNet、どのサブネットで、どのCIDR範囲が使用されているかを一元的に管理する仕組み（Excel、専用ツール、クラウドプロバイダーのサービスなど）を導入します。これにより、重複の防止や空き状況の把握が容易になります。
• IPv6の検討： IPv4アドレスの枯渇が懸念される場合や、IoTデバイスなど大量のIPアドレスが必要な場合は、IPv6の導入を検討します。多くのクラウドプロバイダーはVPC/VNetでのIPv6利用をサポートしています。

4. クラウドプロバイダー固有の予約アドレス 🔒

各クラウドプロバイダーは、サブネット内の特定のIPアドレスを自身のサービス（ルーター、DNSなど）のために予約しています。サブネット設計時には、これらの予約アドレスを考慮し、実際に利用可能なホストアドレス数を計算する必要があります。

• AWS: 各サブネットのCIDR範囲内の最初の4つのIPアドレスと最後の1つのIPアドレス (計5つ) を予約します。
• Azure: 各サブネットのCIDR範囲内の最初の4つのIPアドレスと最後の1つのIPアドレス (計5つ) を予約します。
• GCP: 各サブネットのCIDR範囲内の最初の2つのIPアドレスと最後の2つのIPアドレス (計4つ) を予約します。

例えば、/24 (256アドレス) のサブネットを作成した場合、AWSやAzureでは 256 – 5 = 251 個、GCPでは 256 – 4 = 252 個のIPアドレスがホストに割り当て可能です。

5. 命名規則：分かりやすさと一貫性 🏷️

VPC/VNet、サブネット、ルートテーブル、セキュリティグループなどに一貫性のある命名規則を適用することは、運用管理の効率化とミスの防止に繋がります。

• リージョン、AZ、環境（本番/開発/ステージング）、役割（web/app/db/public/private）、連番などを含む、分かりやすい名前を付けます。
• 例: vpc-prod-apne1, subnet-private-app-apne1a-01, rtb-public-apne1, sg-web-common
• 組織内でルールを定め、徹底することが重要です。

6. オンプレミス/他クラウドとの接続：ハイブリッド構成 🤝

VPN接続、専用線接続 (AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect)、VPC/VNetピアリング、Transit Gatewayなどを利用して、オンプレミス環境や他のクラウド環境と接続する場合、IPアドレスの重複は絶対に避けなければなりません。

• 接続する可能性のあるすべてのネットワークのIPアドレス空間を事前に調査し、重複しないCIDRブロックをクラウド側に割り当てます。
• 中央でのIPアドレス管理 (IPAM) が、ここでも重要になります。

これまでの考慮点を踏まえ、具体的なベストプラクティスをまとめます。

簡単なシナリオに基づいて、ここまでのベストプラクティスを適用した設計例を考えてみましょう。ここではAWSを例にしますが、基本的な考え方は他のクラウドでも同様です。

シナリオ：一般的なWebアプリケーション（高可用性構成）

2つのAZを利用して冗長化されたWebアプリケーション（Webサーバー、Appサーバー、DBサーバー）を構築する場合。

1. VPC CIDRの決定: 将来の拡張性を考慮し、10.0.0.0/16 を選択。オンプレミス等との重複がないことを確認。
2. サブネット分割計画 (AZ-A と AZ-B を利用):
   • パブリックWebサブネット (AZ-A): 10.0.0.0/24 (Webサーバー用LB, NAT GWなど)
   • パブリックWebサブネット (AZ-B): 10.0.1.0/24 (Webサーバー用LB, NAT GWなど)
   • プライベートAppサブネット (AZ-A): 10.0.10.0/24 (Appサーバー)
   • プライベートAppサブネット (AZ-B): 10.0.11.0/24 (Appサーバー)
   • プライベートDBサブネット (AZ-A): 10.0.20.0/24 (DBサーバー)
   • プライベートDBサブネット (AZ-B): 10.0.21.0/24 (DBサーバー)
   • (オプション) プライベート管理サブネット (AZ-A): 10.0.100.0/27 (踏み台サーバーなど)
   • (オプション) プライベート管理サブネット (AZ-B): 10.0.101.0/27 (踏み台サーバーなど)
   CIDRの割り当て方には様々な流儀がありますが、AZや層ごとに範囲を分かりやすく区切るのが一般的です。ここでは、AZ-Aに偶数、AZ-Bに奇数の第3オクテットを割り当てる例を示しました。
3. ルートテーブルの設定:
   • パブリック用ルートテーブル: デフォルトルート (0.0.0.0/0) をインターネットゲートウェイ (IGW) に向ける。パブリックサブネットに関連付け。
   • プライベートApp用ルートテーブル: デフォルトルート (0.0.0.0/0) をNATゲートウェイに向ける。プライベートAppサブネットに関連付け。
   • プライベートDB用ルートテーブル: デフォルトルートは設定しないか、NATゲートウェイに向ける（DBが外部アクセス不要なら不要）。プライベートDBサブネットに関連付け。
   • (オプション) プライベート管理用ルートテーブル: NATゲートウェイやオンプレミスへのVPNゲートウェイなど、必要に応じたルートを設定。
4. NACLとセキュリティグループの設定:
   • NACL: サブネット間の大まかな通信ルールを設定（例: WebサブネットからAppサブネットへの許可、DBサブネットへの直接アクセス拒否など）。
   • SG: 各インスタンスに必要な最小限のポート（例: WebサーバーSGは80/443を許可、AppサーバーSGはWebサーバーSGからの特定ポートを許可、DBサーバーSGはAppサーバーSGからのDBポートを許可）を設定。
5. NATゲートウェイの配置: 高可用性のため、各AZのパブリックサブネットにNATゲートウェイを配置し、それぞれのAZのプライベートサブネットからの通信が同じAZのNATゲートウェイを通るようにルートテーブルを設定します。
6. IPAMでの管理: 上記で決定したCIDR範囲と用途をIPAMツール（または管理台帳）に記録します。
7. 命名規則の適用: subnet-public-web-apne1a-01, sg-app-prod-apne1 のような一貫した名前を付けます。

この設計により、AZ障害時にもサービスを継続でき、セキュリティ境界も明確になります。また、IPアドレス空間にも余裕があるため、将来的なリソース増加にも対応しやすくなります。😊

# Python (ipaddressモジュール) を使ったCIDR計算の例
import ipaddress

vpc_cidr = ipaddress.ip_network('10.0.0.0/16')
print(f"VPC CIDR: {vpc_cidr}")

# /24 サブネットの候補を生成 (一部)
subnets = list(vpc_cidr.subnets(new_prefix=24))

print("\n--- サブネット割り当て例 ---")
print(f"Public Web AZ-A: {subnets[0]}")
print(f"Public Web AZ-B: {subnets[1]}")
# ... (間のサブネットは予備や他の用途に)
print(f"Private App AZ-A: {subnets[10]}")
print(f"Private App AZ-B: {subnets[11]}")
print(f"Private DB AZ-A: {subnets[20]}")
print(f"Private DB AZ-B: {subnets[21]}")

# 特定サブネットの利用可能IPアドレス数 (AWS/Azureの場合 -5)
private_app_subnet_a = subnets[10]
usable_ips = private_app_subnet_a.num_addresses - 5
print(f"\n{private_app_subnet_a} で利用可能なIP数 (AWS/Azure): {usable_ips}")

上記のコードは、ipaddressライブラリを使用してCIDRからサブネットを計算する簡単な例です。実際の設計では、これらの計算を基に、管理ツールやドキュメントで計画的にIPアドレス空間を管理します。

クラウドにおけるサブネット設計は、一度行ったら終わりではありません。ビジネスの成長、新しいサービスの導入、セキュリティ要件の変化、クラウド技術の進化などに合わせて、継続的に見直し、改善していく必要があります。

今回紹介したベストプラクティスは、堅牢でスケーラブルなクラウドネットワーク基盤を構築するための出発点です。

• 計画性: 将来を見据えたVPC/VNet CIDR設計とIPAMの導入。
• 階層化と分離: 目的（セキュリティ、可用性、役割）に応じたサブネット分割。
• セキュリティ: NACLとSG/NSGの適切な利用、パブリック/プライベートの分離。
• 自動化: IaCによる構成管理。
• 管理: 一貫した命名規則とIPAMによる情報の一元化。

これらの原則を守ることで、クラウドのメリットを最大限に活かし、安全で効率的なシステム運用を実現できるでしょう。ぜひ、ご自身の環境に合わせてこれらのベストプラクティスを適用してみてください。💪