Cloud Network Addressing and Routing Foundations

When you first look at a cloud network, resource names such as VNet, Subnet, NSG, Route Table, Gateway, and Load Balancer first come to mind. However, as we follow the failure or design the structure, we eventually come back to calculating IP addresses and subnets. You need to be able to read the address scheme to determine which resources are on the same network, which requests should go through the gateway, and which load balancers are sending traffic to which backends on which subnets.

When studying network basics separately, decimal and binary conversion, subnet mask, TCP/IP, and gateway seem to be separate topics. In the cloud, these concepts lead to VNet address spaces, subnet separation, routing, security rules, and high availability configuration. Therefore, this article focuses on how address design affects the operating structure rather than the calculation itself.

The IP address lies between the decimal numbers read by humans and the binary numbers calculated by the device.

IPv4 addresses are usually expressed as four decimal numbers separated by periods, such as 192.168.1.10. Each number can range from 0 to 255, and is internally an 8-bit binary number.

192      .168      .1        .10
11000000 .10101000 .00000001 .00001010

When converting a decimal number to binary, divide by 2, record the remainder, and read it backwards at the end. For example, 10 is 1010, and when set to 8 bits, it is 00001010.

10 / 2 = 5 ... 0
5  / 2 = 2 ... 1
2  / 2 = 1 ... 0
1  / 2 = 0 ... 1

reverse: 1010
8-bit:   00001010

The reason this calculation is important is because the subnet mask divides the network and host areas bit by bit. In the cloud Console, you only enter the CIDR notation, but in reality, the bit boundaries determine the address range.

CIDR is shorthand for network boundaries

In 10.0.0.0/16, /16 means that the first 16 bits are the network area. The remaining 16 bits are the host area. In 10.0.1.0/24, the first 24 bits are the network area and the last 8 bits are the host area.

10.0.1.0/24

network bits: 24
host bits:     8
addresses:   256
usable idea: 10.0.1.1 - 10.0.1.254

In the cloud, each provider has a reserved address. Azure reserves some IPs in each subnet. Therefore, the number of theoretical addresses and the number of addresses that can actually be used may be different. Still, if you have a sense of CIDR, you can avoid making the mistake of making the subnet too small and not being able to expand it later.

VNet: 10.16.0.0/16

10.16.1.0/24  gateway subnet
10.16.2.0/24  web subnet
10.16.3.0/24  api subnet
10.16.4.0/24  data subnet
10.16.5.0/27  bastion subnet

The standard for dividing addresses is not the attractive name, but the role. The external entry point, web/API layer, data layer, and management access layer have different communication rules. If you put resources with different roles in the same subnet, NSG and Route Table will also become rough.

The subnet mask determines whether it is “the same network”

The subnet mask tells you which part of the IP address is in the network area. 255.255.255.0 is a binary number where the first 24 bits are 1, and in CIDR it is /24.

IP:      192.168.1.10
Mask:    255.255.255.0
CIDR:    /24
Network: 192.168.1.0

If the two IPs are on the same subnet, they can communicate directly; if they are on different subnets, they must go through a gateway.

192.168.1.10/24 and 192.168.1.20/24
same network: 192.168.1.0/24

192.168.1.10/24 and 192.168.2.20/24
different network
gateway required

Subnetting is the process of dividing a large network into smaller networks. Dividing 192.168.1.0/24 by /26 creates four subnets.

192.168.1.0/26     192.168.1.0   - 192.168.1.63
192.168.1.64/26    192.168.1.64  - 192.168.1.127
192.168.1.128/26   192.168.1.128 - 192.168.1.191
192.168.1.192/26   192.168.1.192 - 192.168.1.255

In the cloud, this calculation becomes a resource deployment plan. For example, place Azure Application Gateway in a dedicated subnet and backend VMSS in another subnet. Bastion requires a dedicated name of AzureBastionSubnet and sufficient address space. If you plan to create many private endpoints, you need address space in the data subnet.

A gateway is a gateway to another network.

A gateway is a gateway that connects communications between different networks. You can communicate directly within the same subnet, but going out to another network requires a next hop in the routing table.

client: 10.16.2.4/24
target: 10.16.3.4/24

source subnet: 10.16.2.0/24
target subnet: 10.16.3.0/24
next hop: virtual network router

In home networks, the default gateway is often a router. In a cloud VNet, Azure acts as a virtual router, and VPN Gateway, ExpressRoute Gateway, NAT Gateway, Azure Firewall, and user-defined Route Table change routes as needed.

There are several types of resources named Gateway. VPN Gateway connects on-premises and VNet. Application Gateway is the L7 HTTP/HTTPS entry point. NAT Gateway provides an outbound Internet route for a private subnet. The names are similar, but their roles are different.

VPN Gateway          network-to-network private connectivity
Application Gateway  HTTP/HTTPS layer 7 entry point
NAT Gateway          outbound internet path for private subnet
Load Balancer        layer 4 traffic distribution

If you miss this distinction, you're left with just saying, "I created a gateway," and it becomes difficult to explain the actual traffic path.

Load Balancer and Application Gateway have different layers

Azure Load Balancer distributes TCP/UDP traffic at the L4 layer. If you create an internal Load Balancer, you can use a private IP that is accessible only within the VNet as an entry point.

Internal Load Balancer
- frontend IP: 10.16.3.99
- backend pool: 10.16.3.4, 10.16.3.5
- rule: TCP 80 -> TCP 80
- probe: HTTP /

Application Gateway is an L7 entry point that understands HTTP/HTTPS. It is connected to functions such as host header, path, TLS, and WAF. It is suitable as the first entry point for external users in web services.

Application Gateway
- public frontend IP
- listener: HTTP/HTTPS 80/443
- backend pool: web VMs or VMSS
- routing rule: path/host based
- optional WAF

The two resources are not substitutes for each other, but rather tools from different layers. External HTTP requests are received from Application Gateway, and an Internal Load Balancer can be installed in the internal API layer.

With this structure, NSG rules become much easier to read. Traffic coming directly from the Internet to the web VM is blocked, and only traffic going from the Application Gateway to the web subnet is allowed. In the web subnet, only necessary ports are allowed to the API subnet through the Internal Load Balancer address.

VNet is a logical network and security perimeter

VNet is a logical network created within the cloud. Resources such as VMs, Databases, Web Apps, Private Endpoints, and Load Balancers communicate within this network boundary. Basically, VNets are isolated from each other and connected via Peering, VPN, or ExpressRoute if necessary.

VNet responsibilities
- IP address space
- subnet segmentation
- private IP communication
- DNS integration
- NSG and route table association
- peering or hybrid connectivity

The important thing in VNet design is not to subdivide everything from the beginning, but to first establish boundaries that are difficult to change.

Recommended separation
- ingress subnet
- application subnet
- data/private endpoint subnet
- management subnet
- optional firewall subnet

When divided like this, security rules and routing naturally follow. Conversely, if you put all resources in one subnet, it becomes difficult to later lock down only a specific layer or send only a specific route to the firewall.

NSG rules are a result of address design

NSG (Network Security Group) may look like a “configuration that opens a port,” but it is actually a device that represents a network trust boundary. Even the same 443 port has different meaning depending on whether it is 443 coming from the Internet, 443 going from Application Gateway to the web subnet, or 443 going from the web subnet to the API subnet.

NSG rules are usually read with the following elements:

priority
direction
source
source port
destination
destination port
protocol
action

For example, external users can only access the Application Gateway, and the web subnet can only be accessed by the Application Gateway.

allow
  source: Internet
  destination: ApplicationGatewaySubnet
  port: 443

allow
  source: ApplicationGatewaySubnet
  destination: WebSubnet
  port: 443

deny
  source: Internet
  destination: WebSubnet
  port: any

The API layer becomes narrower. Configure so that users do not access the API VM directly, but only through the web subnet or internal load balancer.

allow
  source: WebSubnet
  destination: APISubnet
  port: 8080

allow
  source: APISubnet
  destination: DataSubnet
  port: 5432

deny
  source: Internet
  destination: APISubnet, DataSubnet
  port: any

Application Security Group (ASG) allows you to read rules based on application roles rather than IP ranges.

asg-web
  -> asg-api : tcp/8080

asg-api
  -> asg-db : tcp/5432

If the address design is organized, the NSG will be easier to read. Conversely, if addresses are mixed up, the NSG rule gradually becomes a list of exceptions. As the list of exceptions grows, both failure analysis and security reviews become difficult.

Private Endpoint reduces public entry points

PaaS resources such as Storage Account, SQL Database, and Key Vault have public endpoints by default. This is convenient for the lab phase, but in production it may require configuration to reduce the public Internet path and make it accessible from inside the VNet. At this time, Private Endpoint is used.

If you attach a Private Endpoint, the application accesses PaaS resources through a private IP inside the VNet rather than a public IP. This is where DNS becomes important. Even if the same mystorage.blob.core.windows.net is searched, it must be interpreted as a private endpoint IP in the internal network.

public path
  app -> public internet -> storage public endpoint

private endpoint path
  app -> VNet private IP -> storage private endpoint

Private endpoints enhance security but also increase operational complexity. Private DNS Zone connection, DNS resolution between VNet peering, firewall exceptions, and local development environment approach must be designed together.

VNet Peering and routing boundaries

As the service grows, a hub-spoke structure is reviewed rather than putting all resources in one VNet. Common resources such as firewall, bastion, VPN gateway, and public DNS/monitoring are placed in the hub VNet, and workload-specific applications are placed in the spoke VNet.

Peering connects two VNets like a private network, but it does not automatically solve all problems. If address spaces overlap, peering itself becomes difficult, and if the routing path is unclear, traffic may flow through an unintended path. Additionally, security rules still need to be managed separately in the NSG and route table of each subnet.

avoid overlap
  hub:    10.0.0.0/16
  spoke1: 10.10.0.0/16
  spoke2: 10.20.0.0/16

problem
  spoke1: 10.10.0.0/16
  spoke2: 10.10.0.0/16

Address duplication later becomes a major limitation in VPN, ExpressRoute, M&A, and external partner integration. So, even for small projects, rather than carelessly writing the entire 10.0.0.0/16, it is necessary to get into the habit of reserving address space considering the network to be connected in the future.

Traffic Manager is DNS-based routing

Azure Traffic Manager is not an L7 reverse proxy but a DNS-based traffic routing service. Understanding this difference makes failure analysis easier. When a user queries a domain, Traffic Manager returns an endpoint that matches the policy as a DNS response, and then the actual HTTP request goes directly to that endpoint.

The operational purpose varies depending on the routing method.

Priority
  primary/secondary failover

Weighted
  gradual rollout or traffic split

Performance
  route to low-latency region

Geographic
  route by user region

MultiValue
  return multiple healthy endpoints

Subnet
  route by client IP range

When using Traffic Manager, you must also look at the DNS TTL. If a failure occurs, the switch may not be immediately visible if the client or ISP's DNS cache still contains old responses. Therefore, when designing global failover, health probe, TTL, application session, and data replication delay must be considered together.

Address design reduces fault analysis time

If the address system is consistent, decisions can be made faster in failure situations. If there is a rule that 10.16.1.0/24 is gateway, 10.16.2.0/24 is web, and 10.16.3.0/24 is api, you can guess which layer it is just by looking at the IP recorded in the log.

10.16.1.12 -> Application Gateway instance
10.16.2.4  -> web VM
10.16.3.5  -> api VM
10.16.3.99 -> internal load balancer

The following steps are helpful when narrowing down the obstacle:

1. DNS resolves to the expected entry point?
2. Entry point health probe is green?
3. NSG allows the source and destination?
4. Route table sends traffic to the intended next hop?
5. Backend process listens on the expected port?
6. Application logs show request arrival?

This sequence is more of a mindset than a tool. curl, dig, nslookup, ss, NSG Flow Logs, Load Balancer probe, and Application Gateway backend health all check the same question in different locations.

Cleanup

Network fundamentals aren't abstracted away in the cloud; they're just hidden behind more resource names. Decimal and binary numbers help us understand the bit boundaries of the IP address, and CIDR and subnet mask help us determine whether it is the same network or a different network. A gateway is a route to another network, and Load Balancer and Application Gateway distribute traffic at different layers.

When designing VNets and Subnets, it is more important to divide roles and security boundaries than to neatly divide addresses. If you separate the user's entry point, application layer, data layer, and management access path, NSG, Route Table, Bastion, Private Endpoint, and Load Balancer configuration naturally follow. Ultimately, a good network design is a structure that can quickly explain “where this traffic should go” when a failure occurs.