クラウド

AWS VPC設計入門：CIDRの決め方とサブネットの分け方

2026/10/16 シリーズ「AWS 入門」 第4回 / 全6回

🤖 AIを使用して執筆

VPC のアドレス：CIDR の範囲と、その中のサブネット

VPC を作るときには、使う IPv4 アドレスの範囲を CIDR の形で指定する。CIDR は、アドレスと「/」の後ろの数で範囲を表す書き方で、IPv4 のアドレスは 32 ビットの数で、10.0.0.0/16 なら、先頭の 16 ビットが固定で、残りの 16 ビットが自由に変わる。そのため 2 の 16 乗、つまり 65,536 個のアドレスを含む。数が大きいほど範囲は狭い。VPC に指定できる大きさは、/16（65,536 個）から /28（16 個）までである⁴。範囲は、RFC 1918 が社内などで使うために定めたプライベートアドレスの三つの範囲（10.0.0.0/8 など）から選ぶよう、AWS は勧めている⁴。ただし 172.17.0.0/16 は SageMaker AI など一部の AWS のサービスが使うので、ぶつからないように VPC には使わないことを求めている⁴。

サブネットの範囲は、VPC の範囲の中から、互いに重ならないように切り出す⁵。各サブネットでは、先頭の四つと最後の一つのアドレスを AWS が予約するため、サーバーなどには割り当てられない。たとえば /24（256 個）のサブネットで使えるのは 251 個である⁵。

後から変えられない範囲と、後から足せる範囲

VPC を作ったときの最初の範囲は、後から変えることも外すこともできない⁴⁶。サブネットの IPv4 の範囲も変えられない⁶。

一方、重ならない範囲を、二つ目以降の範囲（セカンダリ CIDR）として足すことはできる。範囲の数は、最初の範囲を含めて、既定では一つの VPC に五つまでである⁷。この機能は 2017 年 8 月に加わり、AWS はそのとき、これからは必要な分だけを割り当て、後で広げればよいと説明した⁸。

ただし、範囲を足しても、最初の範囲がほかのネットワークと重なっているという問題は消えない。足した重ならない範囲は、private NAT ゲートウェイを置いてアドレスを変換する場所としては使える⁹。とはいえ、後で広げられることは、最初の範囲を重ならないように選ばなくてよい理由にはならない。

範囲が重なると、つなげない

VPC をほかのネットワークとつなぐときは、サブネットの経路表（ルートテーブル）に、相手の範囲あての通信をその接続へ送る経路を書く。たとえば VPC が 10.0.0.0/16、社内のネットワークが 172.16.0.0/16 なら、経路表は次のようになる。

宛先が 172.16.1.20 の通信は 2 行目に当たり、社内へ送られる。宛先が VPC の範囲に入る通信は、1 行目の local の経路で、VPC の中で届けられる¹⁰。local より狭い範囲の経路も書けるが、その宛先は VPC の中のサブネットに限られる¹¹。そのため、社内も 10.0.0.0/16 を使っていると、社内のそのアドレスあての通信を社内へ送る経路は書けず、通信は社内に届かない。重なりで困るのは、このようにプライベートなアドレスのまま通信する場合である。インターネット上の相手と公開のアドレスでやりとりする通信は、影響を受けない。

範囲が一致する VPC や、一部でも重なる VPC のあいだには、ピアリングを作れない。VPC に範囲が複数あるときは、そのうち一つでも重なれば作れない¹²。

多くの VPC をまとめてつなぐ Transit Gateway も、範囲が一致する VPC や、範囲が重なる VPC のあいだの経路を扱わない¹³。重なる VPC を Transit Gateway に接続すること自体はできるが、後から接続した VPC の経路は、Transit Gateway の経路表に伝わらない¹³。

AWS の Well-Architected フレームワークは、ピアリング、Transit Gateway、VPN（インターネット越しの暗号化された接続）のどれでつなぐ場合も、VPC どうしの範囲は重なってはならないとしている。重なってしまった場合は、新しい範囲に移るか、アドレスを変換する private NAT ゲートウェイや、アドレスに頼らずに特定のサービスだけを公開する AWS PrivateLink を使う³。AWS のプリンシパル・ソリューションアーキテクト Brett Looney は 2022 年に、重なりは会社の買収でよく起きると書き、長い目で見れば安く簡単なので、できる限りアドレスを付け直すよう強く勧めている⁹。

最初に決めること：重ならず、成長を見込んだアドレス計画

ネットワークの構成を計画するときの最初の一歩は、アドレス空間そのものを決めることである。Well-Architected フレームワークの信頼性の柱は、そう位置づけたうえで、アドレスの計画に二つのことを求めている⁶。

• 成長とゾーンを見込む。 VPC の範囲は、将来の拡張と、複数のアベイラビリティーゾーンに置くサブネットの分まで入る大きさにする。ただし、見込みをはるかに超えた大きすぎる範囲も、ほかのネットワークと重なりやすくなるので避ける。一方で、伸びが読めないときは、作り直しを避けるために大きめの範囲を取ることも勧めている⁶。
• 重ならないようにする。 社内のネットワークや、ほかのクラウドで使っている範囲を VPC に使わない。後でそれらとつなぐときに重なるからである。誰がどの範囲を使っているかを、表計算のような手作業で管理することにも頼らない³。

複数の VPC の設計を扱う AWS のホワイトペーパーも、アドレスの計画と管理は欠かせないとし、計画には社内とクラウドの両方と、新しいリージョンや買収のような将来の拡張を含めるよう書いている。そのうえで、隔離したネットワークのように、あえて範囲を重ねる場合は、経路とセキュリティと費用への影響を承知して決めるよう求めている¹⁴。手作業の管理に代わる仕組みとして、AWS は 2021 年 12 月に、VPC へのアドレスの割り当てを自動で行う IPAM（IP Address Manager）を公開した¹⁵。

サブネットは、アベイラビリティーゾーンごとに分ける

AWS では、一つのサブネットは一つのアベイラビリティーゾーンに収まり、ゾーンをまたげない。AWS は、リソースを別々のゾーンに置けば、一つのゾーンの障害からアプリを守れると説明している¹⁶。そのため、複数のゾーンを使うには、ゾーンごとにサブネットを作る。

サブネットには、役割の違いもある。インターネットゲートウェイ（VPC とインターネットの出入り口）への経路があるサブネットをパブリックサブネット、無いサブネットをプライベートサブネットと呼ぶ。どちらになるかは、サブネットの経路の設定で決まる¹⁶。たとえば、外に公開するサーバー用と、データベース用の二種類を三つのゾーンに置けば、サブネットは六つになる。VPC の範囲は、この六つが入り、さらに後でサブネットを増やせる大きさにしておく。

プライベートサブネットからインターネットに出るには、アドレスを変換して外へ通す NAT ゲートウェイを通る。NAT ゲートウェイは一つのゾーンに作られるので、AWS は、ゾーンごとに一つ作り、各ゾーンのリソースが同じゾーンの NAT ゲートウェイを使うよう勧めている¹⁷。2025 年 11 月からは、ゾーンをまたいで自動で広がる NAT ゲートウェイも選べる¹⁸。

サブネットがゾーンをまたげるかは、クラウドによって違う。Azure のサブネットは、すべてのゾーンにまたがる¹⁹。ネットワークの専門家 Ivan Pepelnjak は 2021 年に、Azure のようにサブネットの中も IP で経路を決める作りなら、ゾーンをまたいでも障害を分ける点では差がなく、違いはアプリの置きやすさに出ると書いている¹⁹。

アドレスの範囲は、最初に重ならないように決める

VPC の設計で最初に決めるのは、アドレスの範囲である。最初の範囲とサブネットの IPv4 の範囲は後から変えられない。範囲を足すことはできるが、ほかのネットワークとの重なりは、足しても消えない。重なった VPC はピアリングを作れず、Transit Gateway もそのあいだの経路を扱わない。

そのため AWS は、将来の拡張とゾーンの数を見込み、社内やほかの VPC と重ならない範囲を、初めに割り当てるよう勧めている。サブネットはゾーンごとに作り、その数と大きさも、範囲の中に見込んでおく。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。