IP addresses, CIDR and an address plan you will not regret

Address planning is the least glamorous decision in a cloud network and one of the most expensive to get wrong. On day one, any range works. Every tutorial uses 10.0.0.0/16, every template defaults to it, and nothing breaks. The bill arrives later, on the day two networks that both chose 10.0.0.0/16 need to talk to each other.

By then the range is written into firewall rules, DNS records, partner allowlists, application configuration and monitoring dashboards. Changing it is a migration, not a setting. That is why mature platform teams treat the address plan as a shared asset with an owner, a register and a few hard rules, long before anyone thinks they need one.

This part explains how to read an address range, what "private" and "public" actually promise, and how Hadeda Freight laid out its plan. Hadeda Freight is fictional, and its address ranges and figures are illustrative.

A suburb, a street and a house

An IP address identifies one network interface. A CIDR block (Classless Inter-Domain Routing) describes a range of addresses. Think of 10.40.0.0/16 as a suburb and 10.40.20.0/24 as one street inside it. 10.40.20.15 is a single house on that street.

The number after the slash says how many of the 32 bits in an IPv4 address are fixed as the network part. The rest are free to number hosts. So a larger number after the slash means a smaller range: fewer free bits, fewer addresses. Each step of one doubles or halves the size.

The rule of thumb: total addresses = 2 to the power of (32 minus the prefix). A /24 is 2⁸ = 256. A /20 is 2¹² = 4,096.

Total is not the same as usable. Every cloud provider reserves some addresses in each subnet for its own routing, DNS and future use. At the time of writing (October 2026), AWS, Azure and Huawei Cloud each reserve five addresses per subnet and Google Cloud reserves four in a subnet's primary IPv4 range. A /28 with 16 addresses therefore gives you 11 or 12 usable ones, which is why the tiniest subnets fill up so quickly. Check the provider's current rules rather than relying on any article, this one included.

Try a few ranges here. The calculator shows the network, the first and last address, the total, and what is left after each provider's reservations.

Private does not mean safe, public does not mean open

Three IPv4 ranges are set aside by RFC 1918 for private networks. They are not routed across the public internet:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

Everything else that is in use is broadly public: globally routable when the routes and controls exist. Two misunderstandings follow from the labels.

"Public IP" does not mean "open to everyone". A public address with a firewall that permits only HTTPS from a content delivery network is far more closed than its label suggests. Exposure is decided by routes and rules, not by the number.

A private address does not prove a workload is safe. Private only means it is not directly reachable from the internet. A compromised laptop on the office network, or a compromised container in the cloud, can attack private services all day. Much of Part 10 is about not trusting "inside".

One more range deserves a mention because it catches people out: 100.64.0.0/10 is reserved (RFC 6598) for carrier-grade NAT, which some internet and mobile providers use between their customers and the internet. It is tempting to borrow because it looks unused. Avoid it unless you are certain it does not appear anywhere on your path, including depot LTE links.

There is also a cost angle. Public IPv4 addresses are scarce, and at the time of writing (October 2026) the major providers charge for them; AWS has charged for every public IPv4 address, in use or idle, since February 2024. A design that hands a public address to every VM because it was convenient now shows up on the bill as well as in the attack surface.

Hadeda's address plan

When Hadeda started Track, the platform team of five made one decision before writing any infrastructure code: the whole cloud estate gets one large block, and every environment is carved from it.

Cloud estate:        10.40.0.0/14
  Production:        10.40.0.0/16
  Non-production:    10.41.0.0/16
  Shared services:   10.42.0.0/16
  Reserved growth:   10.43.0.0/16

Production subnets:
  Web and ingress:   10.40.10.0/24
  Application:       10.40.20.0/24
  Data:              10.40.30.0/24
  Private endpoints: 10.40.40.0/24

Outside the cloud plan:
  Midrand office:    10.10.0.0/16
  Durban depot:      10.11.0.0/20
  Gqeberha depot:    10.11.16.0/20
  Cape Town DR colo: 10.12.0.0/16

A few things about this plan are deliberate.

The cloud estate does not overlap the offices. The depots and the Cape Town colocation facility will connect to the cloud (Part 8), so their ranges were checked first and the cloud block was placed around them.

There is a whole /16 held in reserve. A second region, a new business unit or an acquisition can be given space without anyone being renumbered.

The production subnets leave gaps. 10.40.10, .20, .30 and .40 are spaced so that each tier can grow, or a second subnet per tier can be added for another availability zone, without breaking the pattern a person reads at a glance.

Every allocation is recorded. A simple register (a spreadsheet is fine at Hadeda's size; an IP address management tool later) holds the owner, purpose, region, environment and lifecycle of each range. The rule is that teams request space from the register; they never pick a range themselves.

None of these values are universal defaults. The qualities that matter are non-overlap, room for growth, clear ownership and a central register.

Why overlap becomes expensive

Eighteen months after Track went live, Hadeda acquired Swift Couriers, a smaller courier business. Swift's cloud network also used 10.40.0.0/16. Both choices had been perfectly reasonable in isolation. Then the two companies needed Swift's billing system to talk to Track.

A router that can reach both networks cannot decide which 10.40.20.15 a packet is meant for. There is no clever routing trick that fixes this. There are three ways out, and all of them cost something:

• Renumber one side. The cleanest end state, and the most work: every firewall rule, DNS record, certificate, configuration file, partner allowlist and diagram that mentions the old range has to change, in a coordinated cut-over.
• Translate one range with NAT. Swift's network appears to Hadeda as some other range. It works, and it is common, but it adds a stateful device to the path, makes logs show addresses that do not match reality, and turns every future incident into a translation puzzle.
• Publish a service instead of joining the networks. If Hadeda only needs Swift's billing API, Swift can publish that one service through a private endpoint (Part 6) and the two networks never exchange routes at all. This is often the narrowest and best answer, and it works even when ranges overlap.

Hadeda chose the third for the billing integration and scheduled a renumbering of Swift's network for its next platform refresh. The lesson they wrote into their platform standards: check address ranges during due diligence, not after the deal closes.

IPv6 is a design decision, not an accident

IPv6 offers a vastly larger address space, which removes the pressure to conserve addresses and can remove some forms of NAT. It should be part of every new platform plan. It does not remove the need for routing, firewalls, DNS, identity or observability.

Most organisations run dual stack, IPv4 and IPv6 side by side, during the transition. That eases compatibility and doubles parts of the policy and troubleshooting surface. The specific risk is an IPv6 path that nobody designed: a provider enables it by default, the firewall rules only cover IPv4, the flow logs are only queried for IPv4, and an unmonitored route quietly exists. If you enable IPv6, make sure your security tools, logging, applications and runbooks handle it. If you do not, make sure it is really off.

Address-planning rules

• Allocate centrally, even when teams deploy independently.
• Reserve ranges for future regions, environments and acquisitions.
• Never copy the same default CIDR into every project or template.
• Size for scaling behaviour. Containers, managed services and some load balancers consume many addresses per instance.
• Record owner, purpose, region and lifecycle for every allocation.
• Treat IPv6 as a decision, not a provider default.

Common mistakes

• Accepting the template default. Every project that keeps 10.0.0.0/16 is a future overlap.
• Sizing subnets for today's VM count. Container platforms and autoscaling can exhaust a /26 in an afternoon.
• Forgetting the reserved addresses. A /28 is 16 addresses on paper and 11 or 12 in practice.
• Planning the cloud without the offices. The overlap only appears on the day the VPN comes up.
• Leaving IPv6 to chance. An undesigned path is an unmonitored path.

Try it yourself

Hadeda plans a second cloud region for Track in two years, with production and test environments in each region. Using only the reserved growth block 10.43.0.0/16, propose non-overlapping environment and subnet ranges for the new region. State how much space remains afterwards, and show that none of your ranges collide with the Midrand, depot or Cape Town ranges.

Test your understanding

Which is larger, a /20 or a /24, and by how much?

Answer: A /20, with 4,096 addresses against 256. Four fewer prefix bits means 2⁴ = 16 times as many addresses.

A team wants a /28 for a set of private endpoints that will grow to 15. Is that enough on AWS?

Answer: No. A /28 has 16 addresses, of which AWS reserves five, leaving 11. They need at least a /27.

Two networks both use 10.40.0.0/16 but only one API needs to be shared. What is usually the narrowest fix?

Answer: Publish that API through a private endpoint, so the networks never exchange routes. Renumbering or NAT are only needed if broader connectivity is required.

Why is a private address not proof that a workload is safe?

Answer: Private only means not directly reachable from the internet. Anything already inside the network, including a compromised machine, can still reach it.

What to take from this part

A bigger number after the slash means a smaller range. Each step halves or doubles it.

Usable is less than total. Providers reserve four or five addresses in every subnet.

Overlap is cheap to avoid and expensive to fix. Allocate centrally and check ranges before networks, or companies, join.

Public and private describe routing, not safety. Exposure is decided by routes and rules.

Next in the series: DNS, routes and gateways: how a name becomes a reachable destination.

How CloudNala can help

We help platform teams build an address plan and register before the estate grows into one: checking existing office, data-centre and partner ranges, reserving space for regions and acquisitions, and setting the request process that stops teams picking their own ranges. Where overlap already exists, we help choose between renumbering, translation and publishing services, and sequence the work.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Request a Cloud Network Review or write to us at consult@cloudnala.co.za