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

107. サブネットは1つのAZに閉じた小区画である — AWSが各サブネットで先取りする5つのアドレス

VPCという大きなアドレス空間を、さらに小さな区画に切り分け、その一つひとつを物理の場所(AZ)に貼り付ける——その仕組みを図で追っていきます。

① プレフィックスを1bit伸ばすと、区画が2つに割れる

VPC10.0.0.0/24(256アドレス)
10.0.0.0 〜 10.0.0.255
サブネットA10.0.0.0/25(128アドレス)
10.0.0.0〜10.0.0.127
サブネットB10.0.0.128/25(128アドレス)
10.0.0.128〜10.0.0.255
  • 公式の例そのまま: 10.0.0.0/24のVPC(256アドレス)は、128アドレスずつの2つのサブネットに分割できる
  • サブネットのCIDRは、VPCのCIDRと同じ(=VPC全体で1サブネット)か、その部分集合。複数のサブネットを作るとき、それらのCIDRは重複できない

サブネットはVPCのアドレス空間の部分集合。プレフィックスを1bit伸ばすごとに区画が2つに割れる——DynamoDB編で見た「キー空間をプレフィックスで区切る」のと同じ、2進数の階層分割だ。

② サイズは /28 から /16 まで

サブネットのサイズ小さすぎても大きすぎてもいけない
/2816アドレス
最小。これより小さくは切れない
/2732
/24256
/1732768
/1665536アドレス
最大。これより大きくは切れない
  • 公式: The allowed IPv4 CIDR block size for a subnet is between a /28 netmask and /16 netmask
  • CLI/APIで作ると、CIDRは正規形(canonical form)に自動修正される。例: 100.68.0.18/18 と指定すると 100.68.0.0/18 になる——プレフィックスの外側のビットは切り捨てられる

サブネットのサイズは /28(16アドレス)〜 /16(65536アドレス)の範囲。次のセクションで見るように、この「16アドレス」は額面どおりには使えない。

③ 各サブネットの先頭4つ+末尾1つは、AWSが先取りする

10.0.0.0ネットワークアドレス
区画そのものを指す番地。古典的な約束事
10.0.0.1VPCルーター用にAWSが予約
このサブネットの出口。全通信のゲートウェイ
10.0.0.2DNSサーバー(基点+2)
後のDNSレッスンの主役
10.0.0.3将来のためにAWSが予約
10.0.0.4〜.254自由に使える(251個)
10.0.0.255ブロードキャストアドレス
VPCはブロードキャスト非対応→封印
  • 公式: The first four IP addresses and the last IP address in each subnet CIDR block are not available for your use
  • DNSは「VPCのネットワーク範囲の基点+2」。VPCが複数CIDRを持つ場合、DNSサーバーはプライマリCIDR内にあるが、AWSは全CIDRで「各サブネット範囲の基点+2」も予約する
  • 例外: BYOIPで自分のIPv4レンジを持ち込んだ場合は、ネットワークアドレス・ブロードキャストアドレスも含め全アドレスを使える、と公式は明記している

ネットワークアドレス(先頭)とブロードキャストアドレス(末尾)が使えないのはIPネットワーク共通の古典的な約束事。AWSはそこにルーター(+1)・DNS(+2)・予備(+3)を足して合計5つを予約した——「マネージドサービスの中身」が、予約アドレスという形で顔を出している。

④ だから /28 は「16個中11個」しか使えない — 小さく切りすぎる罠

予約は5個で固定どのサイズのサブネットでも同じ
/2816 − 5 = 11
3割超(5/16)が最初から消える
/2732 − 5 = 27
/2664 − 5 = 59
/24256 − 5 = 251
  • /28は16アドレスだが、予約5を引くと11しか残らない
  • 予約数は5で固定。だから区画が小さいほど、使える比率が下がる

サブネットを小さく切りすぎると、リソースに割り当てられるアドレスがENI(ネットワークインターフェース)ごと足りなくなる。Lambda編・コンテナ運用で「サブネットのIPが枯れてスケールできない」という話の正体は、この固定の予約5と小さいCIDRの掛け算だ。

⑤ 各サブネットは丸ごと1つのAZの中にある — AZをまたげない

サブネットIPアドレスの範囲(論理)
だから定石は「AZごとにサブネットを作り、リソースを分散」
1つのAZ物理の場所。AZ障害はこの単位で起きる
AZ-a10.0.0.0/25(サブネットA)
AZ-c10.0.0.128/25(サブネットB)
  • 公式: Each subnet must reside entirely within one Availability Zone and cannot span zones
  • 公式: リソースを別々のAZに配置すれば、単一AZの障害からアプリケーションを守れる。公式の構成図も、2つのAZそれぞれにパブリック+プライベートのサブネット対を置く

「論理の区画(IP範囲)を、物理の場所(AZ)に貼り付ける」——これはDynamoDB編のパーティション(論理キー空間→物理ストレージ)やKinesisのシャードと同じ設計思想だ。可観測性編・コンテナ編で前提にしてきた「マルチAZ配置」の正体は、実は「サブネットを複数のAZに作る」ことだった、という種明かしでもある。

⑥ 「パブリック/プライベート」はルーティングで決まる — サブネット自体の属性ではない

サブネットのタイプ「パブリック」という属性ボタンはない
すべてのサブネットに共通して、必ず関連付くもの
パブリックIGWへの直接ルートあり
公衆インターネットに出られる
プライベートIGWへの直接ルートなし
外に出るにはNATデバイス経由
VPN専用仮想プライベートGW経由でVPNへ
IGWへのルートなし
隔離(isolated)VPCの外へのルートを一切持たない
同じVPC内としか通信できない
ルートテーブル明示しなければメインルートテーブル
ネットワークACL明示しなければデフォルトNACL(全許可)
  • 公式: The subnet type is determined by how you configure routing for your subnets
  • 現行の公式ページは、この4種に加えてAmazon EVS(VMware環境サービス)が作る特殊な「EVSサブネット」も挙げている。一般のVPC設計で意識するのは4種でよい
  • 公式: Every subnet that you create is automatically associated with the main route table for the VPC
  • 公式: 各サブネットは必ず1つのネットワークACLに関連付く。デフォルトNACLはすべてのインバウンド/アウトバウンドのトラフィックを許可する

サブネットが「パブリック」なのは、その中に属性フラグがあるからではなく、ルートテーブルがIGWを指しているから。次のルーティング編で、この「ルートテーブルが行き先を決める」仕組みを詳しく追う。

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