# Cloud networking 101: read an address plan An original 45-minute introduction for an engineer who knows applications but has not designed a cloud network. Start with addresses and ranges, follow the visual example, then run actual calculations before opening a cloud console. The addresses and routers below are fictional planning inputs. ## 1. Give the numbers a meaning An **Internet Protocol (IP) address** identifies an interface for network communication. Think of a building's delivery address: it helps locate a destination, but it does not give a courier permission to enter every room. An address can change, an interface can have more than one, and translating addresses can hide an internal address. It is not a permanent identity for a person, application or customer. **IP version 4 (IPv4)** represents an address with 32 bits, commonly written as four numbers from 0 to 255: `10.24.1.10`. **CIDR**, Classless Inter-Domain Routing, writes an address range as a starting network address and a prefix length. In `10.24.1.0/24`, the first 24 bits identify the block; 8 bits remain, so the range contains 2 to the power of 8, or 256, addresses. The slash number is not a count of servers. A longer prefix describes a smaller range. | Notation | What it means | Total IPv4 addresses | | --- | --- | --- | | `10.24.0.0/16` | Range from 10.24.0.0 to 10.24.255.255 | 65,536 | | `10.24.1.0/24` | Range from 10.24.1.0 to 10.24.1.255 | 256 | | `10.24.1.128/25` | Range from 10.24.1.128 to 10.24.1.255 | 128 | | `10.24.1.10/32` | Exactly one address | 1 | A **subnet** assigns a range to part of a network. A **route** maps a destination range to a next hop, the next place traffic should go. A firewall or traffic policy answers a different question: whether that traffic is allowed. Application authorization decides whether the caller may read a particular document. The 10.0.0.0/8 range is private address space; it is not globally routed as an ordinary public destination. Private does not mean encrypted, trusted or authorized. Two disconnected networks can use the same numbers. Connecting them requires a deliberate plan for overlaps and routing, not just matching names. ## 2. Separate placement from the address plan A **Virtual Private Cloud (VPC)** is a provider-defined virtual network. Azure calls its equivalent a **Virtual Network (VNet)**. These are software-defined network environments, not physical servers. A region or zone describes where a resource runs and its failure boundaries. A subnet describes addresses and has a provider-specific scope. Neither fact alone establishes high availability or end-to-end connectivity. | Provider | Network and subnet scope | Standard IPv4 example | | --- | --- | --- | | Google Cloud | Global VPC; regional subnet | A primary /24 reserves four addresses: 252 remain before allocations | | AWS | Regional VPC; subnet in one Availability Zone | A standard /24 reserves five: 251 remain before allocations | | Azure | Regional VNet; subnet within the VNet | A /24 reserves five: 251 remain before allocations | The reservation profiles are deliberately narrow. Google Cloud secondary ranges have different rules, and AWS bring-your-own-IP ranges can differ. Check the current service and range type. Remaining addresses are not verified VM capacity: existing allocations, extra interfaces, endpoints, service-specific reservations, quota and growth all matter. Python's generic host iterator is not a cloud IP allocator. The `10.24.0.0/16` envelope in this lab is a planning choice, not a claim that every provider assigns a CIDR directly to its VPC object. A **default route**, `0.0.0.0/0`, matches every IPv4 destination. In the lab's simple static table, the longest matching prefix wins: /24 before /16 before /0. A /24 route can intentionally sit inside a /16 route. That is different from two subnets competing for the same addresses. Real platforms add route types, priorities, policy routing and other selection rules; this lab implements none of those and refuses an equal-prefix tie. ## 3. Predict and run seven cases Download `fde-cloud-address-lab.py`. Use Python 3.11 or later; no package install, account, credentials or network access is needed. The program uses Python's `ipaddress` library. It creates no sockets, sends no packets, changes no routes and writes no files. The output is a calculation, not evidence from your cloud. ```sh python3 --version python3 fde-cloud-address-lab.py compare python3 fde-cloud-address-lab.py specific-route ``` Write a prediction before running each case. Keep the actual JSON beside it. | Case | Input to notice | Expected observation | | --- | --- | --- | | `inside` | 10.24.1.10 against 10.24.1.0/24 | Membership true; /24 contained in the planned /16 | | `outside` | 10.24.2.15 against the same /24 | Membership false; a shared 10.24 prefix is not enough | | `overlap` | 10.24.1.0/24 and 10.24.1.128/25 | 128 shared addresses, ending at 10.24.1.255 | | `unaligned` | 10.24.1.7/24 supplied as a network | Refused: host bits are set; containing block is 10.24.1.0/24 | | `specific-route` | 10.24.2.15; matching /0, /16 and /24 | /24 selects inspection-router; no connection tested | | `no-route` | 198.51.100.20; only a 10.24.0.0/16 route | No matching route in the supplied table | | `capacity` | /24 plus the three declared reservation profiles | 256 total; 252 or 251 before allocations; actual free count unknown | The unaligned case is a strict teaching check. A host address with a prefix is a valid interface notation, but it is not a canonical network address. Some cloud APIs normalize such inputs; do not silently copy their behavior into a planning validator. Inspect the intended range before accepting it. The no-route destination is reserved for documentation and is never contacted. No match in this supplied table does not prove anything about your machine's actual routes. Similarly, selecting inspection-router does not show that a router exists, accepts traffic or can deliver a request. ## 4. Change the plan and explain the consequence Make two separate copies of the program and keep the reference unchanged. **Experiment A — separate the subnets.** Change `SECOND_SUBNET` from `10.24.1.128/25` to `10.24.2.0/24`. Run `overlap`. Expect `overlaps: false`, `shared: null` and `second_within_plan: true`. The new block avoids the conflict and remains inside the planned /16. Nothing was allocated or deployed. Draw both ranges and name one other connected network you would check before using them. **Experiment B — remove a more specific route.** Set `INCLUDE_SPECIFIC_ROUTE = False` in another copy. Run `specific-route`. The same destination now selects the /16 internal-router instead of the /24 inspection-router. No address changed; the routing decision did. Restoring the specific entry restores the selection. This is a local table exercise, not a recommendation to remove an inspection path in a deployed environment. Explain why overlapping routes can express a useful preference while overlapping subnets can create an allocation conflict. Then add a second route with the same prefix to `choose_route` in your own experiment. This lab refuses ambiguity; a production provider needs its documented tie-breaking rules. ## 5. Apply it to an agent service A fictional agent worker at 10.24.1.10 needs a records API at 10.24.2.15. The caller asks for a document belonging to a different customer. Separate these questions before proposing a repair: 1. Are the interface addresses in their intended, non-overlapping subnets? 2. Which destination route applies from this caller's environment, and what is the return path? The local selection exercise does not verify either path. 3. Do effective traffic rules allow only the intended destination and port? 4. Does Transport Layer Security (TLS) establish the intended service identity? 5. Does the API authenticate the worker and authorize this document read? An allowed network path must not turn a forbidden document into a permitted one. A timeout alone does not identify a firewall problem. Use the provider's existing private-request exercise to inspect separate DNS, connection, TLS and application evidence before changing any live access rule. Keep an address plan with the owner, location, range, current allocation evidence, reserved capacity, connected networks and the next test. Explain it to a teammate without starting with the abbreviation. A useful first sentence is: “These numbers identify where our worker and API live; this range reserves room for instances, and these separate controls decide which requests may pass.” ## 6. Continue in your cloud Choose the environment you are learning. Each existing network lesson adds its own placement, private-request cases and workbook. Advanced instruction still uses the existing training access checks. - [Google Cloud network lesson](/app/academy?course=gcp-infrastructure&lesson=regions-networks&view=focus) - [AWS network lesson](/app/academy?course=aws-infrastructure&lesson=regions-networks&view=focus) - [Azure network lesson](/app/academy?course=azure-infrastructure&lesson=regions-networks&view=focus) - [Free networking practice: DNS, TCP, TLS and HTTP](/training/guides/networking) Primary references checked 21 October 2026. The explanation, fictional examples and program are original LockedIn Labs instruction. - [Python: IP address and network calculations](https://docs.python.org/3.11/library/ipaddress.html) - [Google Cloud: subnet scope and reserved addresses](https://docs.cloud.google.com/vpc/docs/subnets) - [AWS: subnet CIDR blocks and reservations](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-sizing.html) - [AWS: route priority](https://docs.aws.amazon.com/vpc/latest/userguide/route-tables-priority.html) - [Microsoft: Virtual Network and subnet FAQ](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq)