A large enterprise is designing its cloud network for dozens of business units with connectivity back to on-premises data centres. Which decisions are irreversible, and what is the most common expensive mistake?

The most common expensive mistake

Overlapping IP address space. Two business units independently choose the same private range. They work perfectly in isolation and cannot be connected — not to each other and often not to on-premises, which already uses overlapping ranges from twenty years of acquisitions.

The remedies are all bad: renumber live systems (expensive, disruptive, sometimes impossible for appliances with hard-coded addresses), or deploy network address translation between them permanently (adds a hop, breaks any protocol embedding addresses, complicates every future diagnosis, and becomes load-bearing infrastructure nobody can remove).

This is discovered late — typically when the first cross-business-unit integration is attempted, a year or more into the programme, at which point both estates are in production.

The irreversible decisions

1. Address space allocation. A central plan reserving non-overlapping ranges per region, per business unit, per environment, with room for growth. Allocation must be centrally issued rather than self-selected, and it must account for on-premises ranges and for future acquisitions. This is the single decision most worth spending a week on before anyone deploys.

2. Connectivity topology. Hub-and-spoke with a transit hub is the standard enterprise answer: spokes for workloads, a hub for shared services, inspection and on-premises connectivity. Full mesh becomes unmanageable beyond a handful of networks. Changing topology after dozens of workloads exist is a programme, not a change.

3. Where egress is inspected and controlled. Centralised egress through the hub gives one place for inspection, logging and policy — at the cost of a bottleneck and cross-network transfer charges. Decentralised egress is cheaper and faster and multiplies the control points. Whichever is chosen, changing it later means re-plumbing every route table.

4. Segmentation boundaries. Which environments and data classifications may reach which. Retrofitting segmentation into a flat network is far harder than starting segmented.

5. DNS architecture. Resolution across cloud networks and on-premises, in both directions. Consistently underestimated, and consistently the cause of the most confusing incidents in hybrid estates.

What can safely be deferred

Subnet sizing within an allocated range, security group specifics, load balancer choices, and most per-workload decisions. These are cheap to change and should not delay the programme.

The enterprise-specific failure mode

Central network team as a bottleneck. If every new workload requires a manual network request with a multi-week lead time, business units will find ways around it, and the organisation ends up with an ungoverned shadow estate that has none of the controls the central design exists to provide.

The counter is self-service within pre-approved boundaries: a team can provision a workload network from an allocated range through automation, with connectivity, routing and policy applied by template. The central team owns the address plan, the topology and the templates — not each individual request.

The principle

Distinguish decisions that are structurally irreversible (address space, topology, segmentation) from those that are merely inconvenient to change, invest heavily in the first group before anything deploys, and deliberately defer the second so the programme is not blocked by decisions that do not need making yet.