なんで VNet の subnet は一つじゃあダメなんですかね

TL;DR

• Azure の VNet、の中の subnet についていろいろ考えてみた話
• 適切に subnet を切っていただくのが推奨です
• あーなるほどねぇ、と思っていただけたら幸いです

はじめに

Azure の VNet の下位概念として subnet がありますが、なんで一つじゃあダメなんですか、いやまぁ二つくらいは最低でも必要かとは思いますが、その辺に関しての与太話です。

2 名の登場人物の会話形式で進めていきますので、まぁ適当にお付き合いくださいまし。

• 先輩的な A さん
• 後輩的な B さん

subnet は一つだけじゃあいけないんすか

B さん「先輩、Azure の VNet って subnet は一つだけじゃあダメなんすか？」
A さん「いや、まぁ ExpressRoute とか VPN Gateway とかで GatewaySubnet 必要だから一つじゃあ無理じゃないかな。」
B さん「そっすね、あとでちょっと持論もあるんですがいったんはそういうことで了解っす。」

subnet は二つだけじゃあいけないんすか

B さん「んじゃ、なんで subnet は二つだけじゃあだめなんすかね。GatewaySubnet ともう一つのでけぇ subnet にしたら楽そうじゃないっすか。」
A さん「そうね、でもまぁ三層アーキテクチャーとか考えたときに、それぞれに subnet 分けて、それぞれに Network Security Group (NSG) つけるのが一般的じゃないかな、三層アーキテクチャー自体が、今、一般的かはさておきとして。」
B さん「NSG、そう、NSG っすよね、でも。」

NSG は一つだけじゃあいけないんすか

B さん「NSG は一つじゃあいけないんすか、って話を思ってるんですよね。運用上適切ではないとかうんぬんは置いておいて、純粋に技術的にどうかって考えたときに、いくつ subnet を切ってようが、NSG は一つでもいいわけじゃあないっすか。」
A さん「たしかにね。」
B さん「あとは Application Security Group (ASG) もあるし、結局はどの IP アドレス、IP アドレスの範囲、IP アドレス群からどこに向かって許可、拒否するか、って話でしかないわけですよ。Azure Firewall の IP グループみたいな話っすよ。」
A さん「言いたいことはわかってきたわ。推奨はそうだけど、技術的にはね、ってことね、うん。」

UDR とか NAT Gateway とか

A さん「あとさ、subnet に紐づけるようなリソースを考えると User Defined Route (UDR) とか NAT Gateway とかもあるよね。」
B さん「いいとこつきますねぇ、そうなんすよ。今のところでけぇ subnet 一つだと困っちゃうのがそこなんすよね。ただ、結局 UDR って Policy Based Routing (PBR) みたいなもんなんで、UDR の表現力が拡張すればいいっすよね。」
A さん「なるほどねぇ、Azure 側の機能の拡張、大きな話になってきたね。」
B さん「NAT Gateway も同じようなもんなんすよ。NSG では allow/deny しかできないですけど、そこら辺のネットワーク機器の実装を考えれば、NSG に NAT っていうチェックボックスつければそれでもよくないっすか、みたいな。」
A さん「どんどん拡張されていくな。細かいところは気になるけど。」

subnet delegation とか

A さん「そういや VNet integration みたいな感じで subnet をまるっと PaaS に委任 (delegation) することもあるよね。」
B さん「いぐざくとりー (exactly)。そうなんすよ、わかるんすよ、でも、あれだって変な話で、IP アドレスの塊が欲しいだけであって subnet が欲しいわけではないんですよ。」
A さん「続けて。」
B さん「オレは ChatGPT じゃないんすけど、、、まぁいいっす。要は、IP アドレスの範囲を確保できればそれでいいわけで、subnet の数がどうこうって話ではないんすよね。"192.168.10.10-30 まで App Service に渡します" みたいな。」
A さん「なるほどねぇ、確かにね。Application Gateway で 40 インスタンスまで増やしたいって時に、わざわざ /26 割り当てるとなるとそこそこ無駄が出るもんね。」
B さん「さすが理解が早いっす、そういうことっす。」

GatewaySubnet とか

B さん「GatewaySubnet もそうなんすよ。Gateway くん達のために、20 こくらいの IP アドレスが欲しいよ、って言われてるだけなんで、192.168.30-50 をあげるよ、ってなればいいんすよ。」
A さん「あーねぇ、IPAM の機能も最近出てきたし、subnet delegation については IP range を予約してそれを各サービスに渡すみたいな方法でもいいってことだよね。」

subnet peering とか

A さん「あとさ、subnet peering みたいな話もあるよね。」
B さん「っはー、さすがっす、よくご存じですね。あれだって、結局 subnet っていうかある IP アドレスの範囲同士でつながればいいだけで、subnet 同士の全体がつながる必要あるんだっけ、って話なんすよね。」
A さん「そうね、とんでもなく拡張性というか自由度の高い世界を思い描いてるんだな、ってことは理解したわ。」

VNet peering とか

A さん「VNet peering についてはどう思うよ。」
B さん「そうっすね、あれだって、結局 L3 が必要ないってことは L2 で拡張されてるだけなんすよね。VLAN 10 の中に 192.168.10.0/24 と 192.168.20.0/24 の通信が混ざってても、究極的には問題ないんすよ。」
A さん「前衛的すぎる構成だけど確かにそうね。192.168.100.0/24 のネットワークと 192.168.110.0/24 のネットワークをつなぐのに、普通なら最低でも /30 のネットワークがいるけど、これが VNet peering だと必要ないんだもんな。」
B さん「そうなんすよ、なんであれはたんに L2 の拡張みたいなもんで、VNet #1 の中でアドレス帯が複数あるのと、VNet peering で増えていくのと、なんかあんまり変わらないような印象を持ってるっす。」

まとめ

冷静に考えれば subnet は適切に分けて、NSG、UDR、NAT Gateway、VNet integration などで適切に使っていくべきではあります。
ほんとうに。

ただ、技術的に、究極の、拡張性を考えると、こういう if があってもいいんじゃあないですか、ということで。