The question this answers
What exactly do I get when a provider gives me a "network", and which of its properties can I never change?
The application and its database must be able to talk to each other over private addresses, and nothing outside the company should be able to address either of them directly — including other tenants on the same physical hardware.
A private address space that is yours alone, isolated by default from every other network including the provider's other customers, with explicit, auditable attachments as the only way in or out.
Isolation by default, attachment by exception
A virtual network is created empty and closed. It has an address range and nothing else: no path to the internet, no path to another network, no path to your office. Every connection it will ever have is an object you create — an internet gateway, a NAT device, a peering connection, a private endpoint, a VPN or a transit attachment — and every one of those is visible in the API and in an audit log. That is the property worth internalizing: reachability is enumerable. You can list the doors.
The isolation is enforced below your workloads, in the provider's software-defined network, not by rules you configure. Two instances in two different customers' networks can hold the same private address and never see each other. This is why the default posture in cloud is stronger than the default posture in a traditional flat corporate network, where a machine plugged into a switch can usually reach far more than anyone intended.
What you assemble inside it is the rest of this module: subnets that pin resources to zones, route tables that decide next hops, and firewalls that filter. The network itself is mostly a container and an address range — but the address range is the decision that outlives everything else in the account.
The address plan is the decision you cannot take back
Choosing 10.0.0.0/16 because it is the default in every tutorial is the single most common permanent mistake in cloud networking. The range cannot be meaningfully changed once workloads run in it, and it determines whether this network can ever be joined to another one. Two networks with overlapping ranges cannot peer, cannot share a transit hub, and cannot be connected to the same corporate VPN — and the day that matters is the day of an acquisition, a merge of two teams' accounts, or a migration, all of which arrive without warning.
The sizing question underneath it is how many addresses each subnet needs and how many subnets each zone needs. Providers reserve a handful of addresses in every subnet for their own use, so a /28 yields far fewer usable addresses than sixteen. Container platforms make this dramatically worse: when every pod gets an address from the subnet rather than from an overlay, a modest cluster consumes thousands of addresses, and a subnet that looked generous for virtual machines is exhausted in a week. Address exhaustion does not present as a network error — it presents as a deployment that cannot place new instances.
The workable discipline is boring: allocate a large private range for the whole organization, carve non-overlapping blocks per environment and per region from it, write it down, and never let a network be created outside the plan. It costs an afternoon and it is worth years.
ORGANIZATION SUPERNET 10.0.0.0/8 (never assigned directly)
prod / eu-region 10.20.0.0/16 65,536 addresses
public-a 10.20.0.0/20 zone A, internet-facing entry points
public-b 10.20.16.0/20 zone B, internet-facing entry points
private-a 10.20.32.0/20 zone A, application and workers
private-b 10.20.48.0/20 zone B, application and workers
data-a 10.20.64.0/22 zone A, databases
data-b 10.20.68.0/22 zone B, databases
reserved 10.20.72.0/21 <= deliberately unused; growth without a redesign
prod / us-region 10.21.0.0/16 non-overlapping, so the two can be joined later
staging / eu-region 10.30.0.0/16
corporate VPN pool 10.90.0.0/16 never reused by any workload network
RULE: no two ranges anywhere in the organization may overlap, including the ones
belonging to companies you have not acquired yet.One network, or many?
The instinct to give every service its own network is usually wrong, and the instinct to put everything in one is usually wrong too. The honest criterion is the blast radius of a mistake and the strength of the boundary you actually need. Subnets and security groups already provide segmentation *inside* a network; a separate network buys you a separate address space, a separate set of route tables, and the guarantee that a misconfigured rule in one cannot expose the other.
That guarantee is worth paying for between environments — production and staging should not share a network, because a staging change that opens a rule too far must not be able to reach production data. It is rarely worth paying for between services in the same environment, where it produces a peering mesh, duplicated gateways and NAT devices, and a set of route tables nobody can reason about.
The cost of many networks is concrete and recurring: cross-network traffic is metered, each network that needs internet egress needs its own NAT devices, peering is non-transitive so the mesh grows quadratically, and a transit hub — the fix for that — is itself a billed component with a per-attachment and per-gigabyte charge. See Private Connectivity and Scoring Operational Complexity.
| Split | What it buys | What it costs | Usually right? |
|---|---|---|---|
| One network per environment (prod / staging / dev) | A staging misconfiguration cannot reach production; separate blast radius, separate audit. | Duplicated gateways and NAT per environment. | Yes — this is the default worth adopting. |
| One network per region | Regional failure isolation and a local address block. | Cross-region connectivity and its per-gigabyte charge. | Yes, when you actually run in more than one region. |
| One network per team or service | Strong isolation between services; independent address space. | Peering mesh, duplicated egress, quota pressure, and routing nobody understands. | Rarely — subnets and security groups already do this. |
| One network for everything | Simplest possible routing; no peering, one NAT per zone. | A single rule change can expose anything to anything. | Only for a single environment, single team, early stage. |
| A shared-services network joined to the others | One place for logging, monitoring and directory services. | A transit hub, and a dependency every environment now shares. | Yes, once there are more than three networks. |
Key points
- A virtual network starts fully isolated; every path in or out is an explicit, enumerable, auditable attachment.
- The address range is effectively permanent and decides whether this network can ever be peered, merged or joined to a corporate VPN.
- Overlapping ranges are the classic unfixable mistake, and they are discovered during an acquisition or migration, never before.
- Address exhaustion presents as a deployment that cannot place instances, not as a network error — container platforms hit it fastest.
- Split networks by environment, not by service; subnets and security groups already segment within one.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • You declare a private address range; the provider reserves it inside a region and isolates it in the software-defined network below your workloads.
- • Subnets carve the range into per-zone blocks, and each resource gets an address from the subnet it is placed in.
- • A default local route makes every subnet in the network reachable from every other, which is why intra-network traffic needs no configuration.
- • Nothing outside is reachable until an attachment exists — gateway, endpoint, peering, VPN or transit — and a route points at it.
- • Isolation between tenants is enforced by the provider's network fabric, so identical private addresses in two customers' networks never collide.
- • Own the address plan document and the rule that no network is created outside it.
- • Own subnet sizing with deliberate spare capacity, especially wherever a container platform assigns per-pod addresses.
- • Own the inventory of attachments — this is the definitive answer to "what can reach this network".
- • Own flow logs, their destination and their retention, before you need them for an investigation.
- • Own the network definition in infrastructure code; a hand-created network is the one that is undocumented three years later. See Infrastructure as Code.
- • Overlapping address ranges discovered when a peering or VPN connection is attempted, with no fix short of re-addressing a live environment.
- • Subnet address exhaustion, surfacing as failed instance launches or pods stuck pending rather than as anything network-shaped.
- • A peering connection assumed to be transitive, so A→B and B→C exist and A→C silently does not.
- • Quota limits on subnets, route-table entries or peering connections blocking a change in a mature account.
- • A "temporary" internet gateway attached during debugging and never removed, quietly making a private tier reachable.
- • Addresses run out first, and the fix — a new range — is far more disruptive than adding capacity anywhere else in the stack.
- • Object quotas (subnets, route entries, security-group rules, peerings) constrain large environments long before throughput does.
- • A peering mesh grows quadratically with network count; a transit hub converts that to linear at the price of a billed component.
- • Bandwidth inside a network is effectively not a constraint at ordinary scale; cross-zone and cross-region *cost* is.
- • Default isolation is the strongest and cheapest control in the domain: a workload with no attachment is unreachable regardless of its software.
- • The security question is therefore "list the attachments and justify each", not "is the firewall configured".
- • Environment separation by network prevents a staging misconfiguration from reaching production data — a boundary that rules alone cannot guarantee.
- • Network isolation is one layer. It does not authenticate, and it does not stop lateral movement from a compromised workload inside the same network. See Infrastructure Trust Boundaries.
- • The network, its subnets, its route tables and its security groups are typically free.
- • Cost enters with the attachments: NAT devices, gateways with hourly charges, transit-hub attachments, and VPN tunnels.
- • Every additional network multiplies the fixed egress components, which is the real bill behind "a network per service".
- • Cross-zone and cross-region data transfer inside the network is metered even though it never touches the internet.
- • Available addresses per subnet, alerted well before exhaustion.
- • Flow logs with accept and reject decisions, which are both the debugging tool and the audit record.
- • Configuration change events on the network, its gateways and its route tables — who attached what, and when.
- • The signal that lies: "the network is up". A virtual network is essentially always up; what breaks is a route, a rule or an attachment, and none of those has a health state.
- • The provider's default network, for a first deployment or a demo — it exists, it works, and designing one by hand teaches nothing at that stage.
- • A platform-as-a-service that owns networking entirely, when the application has no private components to isolate.
- • A single subnet with strict security groups, for a stateless public service — the public/private split earns its complexity only when something must stay private.
- • A managed Kubernetes cluster with an overlay network, when per-pod addresses would otherwise force a much larger address plan.
- • Buys strong default isolation for free; costs an address plan that is expensive to get wrong and impossible to change quietly.
- • Buys auditable, enumerable reachability; costs a set of objects that must be understood before anything can be debugged.
- • More networks buy stronger boundaries; they cost duplicated egress infrastructure, a peering mesh and real money.
What people believe, and what is true
The address range can be changed later if it becomes a problem.
Re-addressing a network with live workloads means re-creating every resource in it. In practice the range is permanent from the first production deploy.
A virtual network is a security boundary on its own.
It is an isolation boundary that removes reachability by default. Inside it, everything can reach everything unless security groups say otherwise.
Peering is transitive, so a hub-and-spoke works with plain peering.
Peering is point-to-point. A spoke reaches another spoke only through an explicit peering or a transit hub that routes between them.