Why Can't a VNet Have Only One Subnet?

TL;DR

• A discussion about Azure VNet subnets and their necessity
• It is recommended to properly segment subnets
• I hope this gives you some insights

Introduction

Azure VNet has subnets as a subordinate concept, but why can't we just have one subnet? Well, I suppose at least two are needed, but this is a casual discussion about that.

We'll proceed in a dialogue format between two characters, so please bear with me.

• Senior colleague A
• Junior colleague B

Why can't we just have one subnet?

B: "Senior, is it really not okay to have just one subnet in an Azure VNet?"
A: "Well, if you use ExpressRoute or VPN Gateway, you need a GatewaySubnet, so one subnet isn't really feasible."
B: "Got it. I have some thoughts on this later, but for now, I'll accept that."

Why can't we just have two subnets?

B: "So then, why can't we just have two subnets? If we had a GatewaySubnet and one big subnet, wouldn't that be easier?"
A: "Well, I suppose. But when you think about a three-tier architecture, it's common to split subnets for each tier and attach a Network Security Group (NSG) to each. Whether the three-tier architecture itself is mainstream nowadays is another matter."
B: "NSG, right, that's the thing. But still..."

Why can't we just have one NSG?

B: "I was thinking, why can't we have just one NSG? Setting aside whether it's operationally appropriate or not, purely from a technical standpoint, no matter how many subnets you create, can't you just use a single NSG?"
A: "True."
B: "Plus, there's also Application Security Group (ASG). Ultimately, it's just a matter of which IP addresses, IP ranges, or groups of IP addresses are allowed or denied, and where traffic is directed. Kind of like Azure Firewall IP groups."
A: "I see what you're getting at. The recommendation is what it is, but technically it's possible, right?"

UDR and NAT Gateway

A: "Also, when you consider resources associated with subnets, you have User Defined Routes (UDR) and NAT Gateway."
B: "You hit the nail on the head. That's exactly where a single big subnet becomes a problem. But since UDR is basically like Policy Based Routing (PBR), if the expressiveness of UDR could be expanded, it would be fine."
A: "I see, that's a bigger topic about extending Azure's features."
B: "NAT Gateway is similar. With NSG you can only allow or deny, but if you think about how network devices implement it, why can't NSG just have a checkbox for NAT, like 'enable NAT'?"
A: "You keep expanding the possibilities. I'm curious about the details though."

Subnet delegation

A: "Come to think of it, sometimes you delegate an entire subnet to a PaaS service, like VNet integration."
B: "Exactly! I get that, but it's actually a bit odd. What they really need is just a block of IP addresses, not necessarily a subnet."
A: "Go on."
B: "I'm not ChatGPT, but okay. The point is, as long as you can reserve a range of IP addresses, the number of subnets doesn't really matter. Like, 'I'm handing over 192.168.10.10-30 to App Service.'"
A: "I see. That's true. When you want to scale Application Gateway to 40 instances, allocating a /26 just for that wastes quite a bit of address space."
B: "Glad you catch on so fast. That's exactly what I mean."

GatewaySubnet

B: "The same goes for GatewaySubnet. It just wants about 20 IP addresses for the gateways. So it would be fine if you could say 'Here, take 192.168.30-50.'"
A: "Right. And with IPAM features recently released, for subnet delegation, you could simply reserve an IP range and pass it to each service."

Subnet peering

A: "Also, what about subnet peering?"
B: "Whoa, you really know your stuff. That's exactly the same. Ultimately, it's about connecting specific IP address ranges, not necessarily entire subnets to each other. Does the whole subnet need to be connected?"
A: "True. I get that you're envisioning a highly extensible, flexible world."

VNet peering

A: "What do you think about VNet peering?"
B: "Well, since it doesn't require L3, it's just L2 extension. Even if traffic from 192.168.10.0/24 and 192.168.20.0/24 are mixed within VLAN 10, ultimately it's not a problem."
A: "That's a very avant-garde configuration, but you're right. Normally, to connect 192.168.100.0/24 and 192.168.110.0/24 networks, you'd need at least a /30 subnet, but with VNet peering, you don't."
B: "Exactly. So it feels like L2 extension to me. Having multiple address ranges within VNet #1 doesn't seem that different from adding more through VNet peering."

Summary

When you think about it calmly, subnets should be properly segmented, and you should use NSG, UDR, NAT Gateway, VNet integration, etc., appropriately. Really.

But from a purely technical standpoint, considering ultimate extensibility, I think it's okay to have this kind of "what if" scenario.