Network Architecture Design: [Organisation, platform or region name]
Design document for an enterprise cloud and hybrid network: topology
(hub and spoke, provider-managed WAN or transit), the IPv4 and IPv6
address plan, routing, hybrid connectivity, DNS resolution, ingress
and egress with inspection, segmentation and micro-segmentation,
private access to managed services, high availability and failover,
monitoring and operations. Provider-neutral, with an equivalents table
for AWS (Transit Gateway, Cloud WAN, Direct Connect), Microsoft Azure
(hub-spoke, Virtual WAN, ExpressRoute) and Google Cloud (Network
Connectivity Center, Shared VPC, Cloud Interconnect). Address planning
follows RFC 1918 (private IPv4), RFC 6598 (shared address space) and
RFC 4193 (unique local IPv6). Replace every [bracketed] value and
every row marked Example; the examples follow an organisation with
two data centres and two cloud regions on one provider.
Document control
| Field | Value |
|---|
| Document ID | [NAD-001] |
| Network domain | [Name] |
| Providers and regions | [Provider], [Region 1], [Region 2] |
| On-premises sites | [Data centre A], [Data centre B], [Offices] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@network-architect] |
| Approvers/reviewers | [@network-lead], [@security-architect], [@platform-lead], [@operations-lead] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| IPAM system | [Tool and instance] |
| Related documents | [Landing zone design], [Security architecture], [Network IaC repository] |
Approvals
| Role | Name | Decision | Date |
|---|
| Network architecture | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Security | [@name] | [Decision] | YYYY-MM-DD |
| Platform | [@name] | [Decision] | YYYY-MM-DD |
| Operations | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved; hub in Region 1 live, private connectivity from data centre A |
| 1.1 | YYYY-MM-DD | [@name] | Example: Region 2 hub and IPv6 dual-stack for internet-facing spokes added |
Contents
1. Scope, requirements and principles
1.1 Scope
| In scope | Out of scope |
|---|
| Example: Cloud hubs and spokes in two regions, hybrid links to two data centres, DNS, inspection, private service access | Campus and branch LAN design |
| Example: Address plan for cloud and for the cloud-facing parts of the data centres | Workload subnets inside a spoke (Infrastructure Design) |
| [Item] | [Item] |
1.2 Requirements
| ID | Requirement | Measure |
|---|
| NRQ-001 (Example) | Support growth to [150] workload spokes per region | Address plan and topology limits checked in section 3 |
| NRQ-002 (Example) | Inspect all traffic between environments of different trust (production, non-production, on premises, internet) | Every such route passes a firewall in section 8 |
| NRQ-003 (Example) | Hybrid link availability for Tier 1 flows | [99.99 %] design target, provider model in section 6 |
| NRQ-004 (Example) | Hybrid latency from data centre A to Region 1 | Under [5 ms] round trip |
| NRQ-005 (Example) | No public endpoints for managed data services | Policy denies; private access per section 10 |
| NRQ-006 (Example) | Name resolution in both directions between cloud and on premises | Section 7 |
| NRQ-007 (Example) | IPv6 for internet-facing services | Dual-stack for spokes in the "public" segment |
| NRQ-008 (Example) | All network changes deployed from code | No console changes in production |
| [NRQ-NNN] | [Requirement] | [Measure] |
1.3 Principles
| ID | Principle | Consequence |
|---|
| NWP-001 (Example) | One hub per region; spokes attach only to their regional hub | A regional hub failure does not affect other regions |
| NWP-002 (Example) | Default deny between spokes; allow by exception through the hub | Flows are documented in section 9 |
| NWP-003 (Example) | Unique, summarisable addresses across every connected environment | One IPAM, no overlaps; exceptions need NAT and approval |
| NWP-004 (Example) | Private by default | Public IP addresses only on approved ingress and egress points |
| NWP-005 (Example) | Prefer provider-managed network functions where they meet the requirement | Fewer appliances to patch; appliances only for gaps |
| [NWP-NNN] | [Principle] | [Consequence] |
2. Provider equivalents
| Neutral term | AWS | Microsoft Azure | Google Cloud |
|---|
| Virtual network | VPC | Virtual network (VNet) | VPC network |
| Regional transit hub, customer-managed | Transit Gateway with an inspection VPC | Hub virtual network with Azure Firewall or a network virtual appliance | Network Connectivity Center hub with VPC spokes, or a hub VPC with appliances |
| Provider-managed global WAN | AWS Cloud WAN (core network, segments, policy) | Azure Virtual WAN (Standard) with virtual hubs | Network Connectivity Center as a global hub |
| Centrally owned network shared to many teams | VPC sharing through AWS RAM | Hub and spokes in a Connectivity subscription | Shared VPC (host and service projects) |
| Dedicated private connectivity | AWS Direct Connect | Azure ExpressRoute | Cloud Interconnect (Dedicated or Partner) |
| Encrypted internet connectivity | AWS Site-to-Site VPN | Azure VPN Gateway | HA VPN |
| Private access to provider and partner services | AWS PrivateLink (interface endpoints) | Azure Private Link (private endpoints) | Private Service Connect |
| Hybrid DNS forwarding | Route 53 VPC Resolver inbound and outbound endpoints with rules | Azure DNS Private Resolver with forwarding rulesets | Cloud DNS forwarding zones and inbound server policies |
| Address management | Amazon VPC IP Address Manager | IPAM in Azure Virtual Network Manager | [Provider IPAM or third-party IPAM] |
| Central managed firewall | AWS Network Firewall | Azure Firewall | Cloud Next Generation Firewall |
3. Topology
3.1 Options
| Option | Description | For | Against |
|---|
| TOP-A (Example) | Customer-managed hub and spoke per region, hubs connected to each other | Full control of appliances and routing; familiar model | More components to operate; peering and route limits to watch |
| TOP-B (Example) | Provider-managed WAN with policy-defined segments | Global transit and segmentation from a policy document; less routing work | Less control of appliance choice; provider-specific feature set |
| TOP-C (Example) | Spoke-to-spoke full mesh, no hub | Lowest latency between spokes | 100 spokes need 100 x 99 / 2 = 4,950 links; no central inspection |
| [TOP-N] | [Description] | [For] | [Against] |
| Decision | Choice | Rationale |
|---|
| Topology (Example) | TOP-A in two regions, review TOP-B when the third region is added | Need for a specific firewall product in the hub; two regions only |
| Inter-region | Hub-to-hub connection over the provider backbone, inspected at the source hub | Keeps regional fault domains separate |
| Spoke-to-spoke | Through the hub firewall; direct connection only for approved high-volume pairs in the same environment | NWP-002, cost of firewall processing for bulk flows |
3.2 Topology diagram
The diagram shows the chosen topology with the example ranges from
section 4. Each data centre has two dedicated links to its nearest
region, and data centre A also has a VPN backup path to Region 2.
3.3 Scale check
| Limit to watch | Design value | Provider limit (check current) | Headroom |
|---|
| Spokes per regional hub (Example) | 150 planned | [Limit] | [Value] |
| Routes advertised from on premises (Example) | 2 data centre summaries (10.0.0.0/13, 10.8.0.0/13); maximum prefix limit set at 50 per session | [Limit per link or gateway] | [Value] |
| Routes advertised to on premises (Example) | 2 summaries (one per region: 10.64.0.0/14, 10.68.0.0/14) | [Limit] | [Value] |
| Firewall throughput per hub (Example) | 8 Gbit/s peak | [SKU limit] | [Value] |
| [Limit] | [Value] | [Limit] | [Headroom] |
4. IP address plan
4.1 IPv4 allocation
Private IPv4 space comes from RFC 1918 (10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16). This plan uses 10.0.0.0/8 only and reserves
172.16.0.0/12 for partner NAT. RFC 6598 shared address space
(100.64.0.0/10) is reserved for carrier-grade NAT; use it inside the
estate only as a conscious, documented decision (for example for
non-routed Kubernetes pod ranges) and never where it could meet a
carrier or partner that uses it.
| Range | Addresses | Use | Summarised as |
|---|
| Example: 10.0.0.0/13 | 524,288 | Data centre A (existing) | 10.0.0.0/13 |
| Example: 10.8.0.0/13 | 524,288 | Data centre B (existing) | 10.8.0.0/13 |
| Example: 10.16.0.0/12 | 1,048,576 | Offices and campus, out of scope | 10.16.0.0/12 |
| Example: 10.64.0.0/12 | 1,048,576 | All cloud space (10.64.0.0 to 10.79.255.255) | 10.64.0.0/12 |
| Example: 10.64.0.0/14 | 262,144 | Region 1 | 10.64.0.0/14 |
| Example: 10.68.0.0/14 | 262,144 | Region 2 | 10.68.0.0/14 |
| Example: 10.72.0.0/14 | 262,144 | Reserved for a third region or second provider | Not advertised |
| Example: 10.76.0.0/14 | 262,144 | Reserved for growth | Not advertised |
| [Range] | [Count] | [Use] | [Summary] |
4.2 Region 1 breakdown
| Range | Addresses | Use |
|---|
| Example: 10.64.0.0/22 | 1,024 | Hub |
| Example: 10.64.4.0/22 | 1,024 | Shared services (domain controllers, tooling) |
| Example: 10.64.8.0/21 | 2,048 | Reserved for a second hub or appliance scale-out |
| Example: 10.64.16.0/20 to 10.64.240.0/20 | 61,440 (15 x 4,096) | Reserved platform growth |
| Example: 10.65.0.0/16 | 65,536 | Production spokes, allocated in /22 blocks (64 spokes) |
| Example: 10.66.0.0/16 | 65,536 | Non-production spokes, allocated in /22 blocks (64 spokes) |
| Example: 10.67.0.0/16 | 65,536 | Reserved: more spokes or larger spokes |
Check: 1,024 + 1,024 + 2,048 + 61,440 = 65,536, the whole of
10.64.0.0/16; the four /16 blocks total 262,144, the whole /14. Region 2
mirrors this layout from 10.68.0.0/14 (hub 10.68.0.0/22, production
spokes 10.69.0.0/16, non-production 10.70.0.0/16, reserve 10.71.0.0/16).
Spoke capacity per region: 10.65.0.0/16 and 10.66.0.0/16 give 128 /22
spokes (64 production, 64 non-production); adding the 10.67.0.0/16
reserve gives 192, which covers the 150 spokes of NRQ-001 with 42 to
spare. Larger spokes or growth beyond that use 10.72.0.0/14. Record the
figures in the scale check (section 3.3).
4.3 Hub subnets (Region 1)
| Subnet | Range | Addresses | Purpose |
|---|
| Firewall (Example) | 10.64.0.0/26 | 64 | Managed firewall (Azure requires at least /26 named AzureFirewallSubnet) |
| Gateway (Example) | 10.64.0.64/26 | 64 | VPN and private connectivity gateways (Azure requires /27 or larger for GatewaySubnet and needs /26 for 16 ExpressRoute circuits; the hub-spoke reference uses /26) |
| DNS inbound (Example) | 10.64.0.128/28 | 16 | Resolver inbound endpoint (Azure DNS Private Resolver needs /28 to /24, dedicated) |
| DNS outbound (Example) | 10.64.0.144/28 | 16 | Resolver outbound endpoint |
| Unused (Example) | 10.64.0.160/27 | 32 | Reserved |
| Bastion (Example) | 10.64.0.192/26 | 64 | Managed remote access |
| Management (Example) | 10.64.1.0/24 | 256 | Network management and appliance interfaces |
| Shared private endpoints (Example) | 10.64.2.0/23 | 512 | Private endpoints for shared managed services |
Check: 64 + 64 + 16 + 16 + 32 + 64 = 256 (10.64.0.0/24), plus 256 and
512 gives 1,024, the whole hub /22. Subnet names and minimum sizes
above are Azure examples; follow the equivalent rules of your provider
and remember that providers reserve some addresses in every subnet.
4.4 Standard spoke layout (/22)
| Subnet | Example range (spoke 10.65.0.0/22) | Addresses | Purpose |
|---|
| Ingress (Example) | 10.65.0.0/24 | 256 | Load balancers and web tier |
| Application (Example) | 10.65.1.0/24 | 256 | Application tier |
| Data (Example) | 10.65.2.0/25 | 128 | Self-managed data stores |
| Private endpoints (Example) | 10.65.2.128/25 | 128 | Private endpoints for managed services |
| Reserved (Example) | 10.65.3.0/24 | 256 | Growth inside the spoke |
4.5 IPv6
| Decision | Choice |
|---|
| Scope (Example) | Dual-stack for internet-facing spokes first; internal spokes IPv4 until required |
| Source of addresses (Example) | Provider-assigned global unicast blocks per virtual network where offered; RFC 4193 unique local addresses (fc00::/7, in practice fd00::/8 with a random 40-bit Global ID) for internal-only ranges |
| Subnet size (Example) | /64 per subnet, as providers allocate it |
| Example allocation (Example) | AWS assigns a /56 per VPC from its pool on request and lets you create /64 subnets from it; record the assigned blocks in IPAM |
| Security (Example) | IPv6 rules written alongside IPv4 rules in the same policy; no implicit allow because a rule set is IPv4-only |
5. Routing
| Item | Design |
|---|
| Route domains (Example) | Separate route tables or segments for production, non-production, shared services and hybrid; on-premises routes visible to production and shared services only |
| Advertisement to on premises (Example) | Region summaries only (10.64.0.0/14, 10.68.0.0/14); never individual spokes. Each summary also covers its region's non-production pool (10.66.0.0/16 in Region 1, 10.70.0.0/16 in Region 2), so the hub firewall denies traffic between on premises and non-production unless a rule allows it |
| Advertisement from on premises (Example) | Data centre summaries (10.0.0.0/13, 10.8.0.0/13); a default route is not accepted from on premises |
| Default route in spokes (Example) | 0.0.0.0/0 and ::/0 to the hub firewall |
| Inspection symmetry (Example) | Both directions of every inspected flow pass the same firewall instance set; appliance clusters use flow-symmetric load balancing |
| Dynamic routing (Example) | BGP on all hybrid links with BFD where supported; AS path prepending to prefer primary links |
| Route filters (Example) | Inbound prefix lists allow only the summaries above; maximum prefix limits configured |
| [Item] | [Design] |
6. Hybrid connectivity
| Link ID | From | To | Type | Bandwidth | Location | Resilience role |
|---|
| HYB-001 (Example) | Data centre A router 1 | Region 1 hub | Dedicated private connection | 10 Gbit/s | Provider edge location L1 | Primary |
| HYB-002 (Example) | Data centre A router 2 | Region 1 hub | Dedicated private connection | 10 Gbit/s | Provider edge location L2 | Primary, diverse location |
| HYB-003 (Example) | Data centre B router 1 | Region 2 hub | Dedicated private connection | 10 Gbit/s | L2 | Primary |
| HYB-004 (Example) | Data centre B router 2 | Region 2 hub | Dedicated private connection | 10 Gbit/s | L3 | Primary, diverse location |
| HYB-005 (Example) | Data centre A | Region 2 hub | IPsec VPN over internet | 1 Gbit/s | Internet | Backup for non-latency-sensitive flows |
| [HYB-NNN] | [From] | [To] | [Type] | [Bandwidth] | [Location] | [Role] |
| Provider resilience models (verify current terms) | Summary |
|---|
| AWS Direct Connect Resiliency Toolkit | Maximum resiliency (separate connections on separate devices in more than one location), High resiliency (connections in multiple locations), Development and test (separate devices, one location) |
| Azure ExpressRoute | Maximum resiliency (circuits in two distinct peering locations), High resiliency (ExpressRoute Metro, one circuit split across two sites in a metro), Standard resiliency (one site, not recommended for critical workloads) |
| Google Cloud Interconnect | 99.99 % topology for Dedicated Interconnect: at least four connections, two in each of two metros across both edge availability domains, with Cloud Routers in two regions and global dynamic routing (a single-region variant also exists) |
Microsoft advises against site-to-site VPN as the backup for
latency-sensitive or bandwidth-intensive workloads; in this design
HYB-005 carries only the flows listed as tolerant in section 9.
Example sizing: peak hybrid traffic is 3.2 Gbit/s; with one of two
10 Gbit/s links failed, the remaining link runs at 32 % load, inside the
50 % planning limit.
7. DNS
| Zone or pattern | Authoritative | Resolution from cloud | Resolution from on premises |
|---|
corp.example.com (Example) | On-premises DNS servers | Outbound resolver endpoint with forwarding rule to data centre DNS | Native |
cloud.example.com (Example) | Cloud private DNS zones linked to hub and spokes | Native | Conditional forwarder on premises to the inbound resolver endpoint (10.64.0.132) |
| Private endpoint zones (Example) | Cloud private DNS zones per service, one central set | Native, linked to all spokes | Conditional forwarders for each private endpoint zone to the inbound endpoint |
| Public zones (Example) | Public DNS service with DNSSEC | Recursive | Recursive |
| [Zone] | [Authoritative] | [From cloud] | [From on premises] |
Rules: one central set of private endpoint zones per environment, never
one per spoke; the hub firewall, if it filters by FQDN, uses the same
resolver as the workloads; DNS changes go through the network pipeline.
8. Ingress, egress and inspection
| Path ID | Path | Control | Logging |
|---|
| PTH-001 (Example) | Internet to public web services | Global or regional load balancer with WAF and DDoS protection in the spoke, or central ingress in the hub for shared front doors | WAF logs to central store |
| PTH-002 (Example) | Spokes to internet | Central egress through the hub firewall with FQDN and URL filtering; NAT to a small set of fixed public IPs that partners can allow-list | Firewall logs |
| PTH-003 (Example) | Spoke to spoke | Through hub firewall, default deny, rules per flow in section 9 | Firewall logs |
| PTH-004 (Example) | On premises to cloud | Through hub firewall, intrusion prevention on | Firewall logs |
| PTH-005 (Example) | Administrative access | Managed bastion or identity-aware proxy; no SSH or RDP from the internet | Session logs |
| PTH-006 (Example) | Spoke to managed services | Private endpoints (section 10); public service endpoints denied by policy | Endpoint and flow logs |
| [PTH-NNN] | [Path] | [Control] | [Logging] |
9. Segmentation
9.1 Macro segments
| Segment | Members | May reach | May be reached from |
|---|
| Production (Example) | Production spokes | Shared services, approved on-premises ranges, internet via egress | Ingress path, approved production spokes |
| Non-production (Example) | Non-production spokes | Shared services, internet via egress | Developers through bastion |
| Regulated (Example) | Cardholder data and similar spokes | Only listed flows | Only listed flows |
| Shared services (Example) | Directory, DNS, tooling | On premises directory | All segments on listed ports |
| Hybrid (Example) | Data centre ranges | Production and shared services | Production and shared services |
9.2 Flow register
| Flow ID | Source | Destination | Protocol and port | Purpose | Inspected | Tolerates VPN backup | Owner |
|---|
| FLW-001 (Example) | Orders prod spoke | Data centre A ERP 10.2.14.0/24 | TCP 443 | Order to ERP integration | Yes | No (latency) | @orders-lead |
| FLW-002 (Example) | Orders prod spoke | Payments prod spoke | TCP 8443 | Payment authorisation | Yes | Not applicable | @payments-lead |
| FLW-003 (Example) | All spokes | Shared services directory | TCP/UDP 53, 88, 389, 636 | Name resolution and authentication | Yes | Yes | @identity-lead |
| FLW-004 (Example) | Data centre B backup servers | Region 2 object storage private endpoint | TCP 443 | Backup copies | Yes | Yes | @backup-lead |
| [FLW-NNN] | [Source] | [Destination] | [Port] | [Purpose] | [Yes / No] | [Yes / No] | [@owner] |
9.3 Micro-segmentation
Inside a spoke, use security groups or network security groups per tier
and, where the platform supports it, rules based on workload identity or
tags rather than addresses. Kubernetes clusters apply network policies
with default deny per namespace. Align the target with the network
pillar of the Zero Trust Architecture Plan
(security/zero-trust-architecture).
10. Private access to managed services
| Service class | Access method | Public endpoint | DNS | Created by |
|---|
| Managed databases (Example) | Private endpoint in the spoke private endpoint subnet | Disabled by policy | Central private zone | Workload pipeline |
| Object storage (Example) | Private endpoint; gateway-type endpoint where the provider offers one | Restricted to private access by policy | Central private zone | Workload pipeline |
| Secrets and keys (Example) | Private endpoint in shared services | Disabled | Central private zone | Platform pipeline |
| Partner SaaS offered through private service access (Example) | Private endpoint to the partner's published service | Not applicable | Partner-specific private zone | Network team on request |
| [Class] | [Method] | [State] | [DNS] | [Creator] |
11. High availability and failover
| Component | Failure mode | Design | Expected failover time | Test |
|---|
| Hub firewall (Example) | Instance or zone failure | Managed firewall across zones, or appliance pair behind a load balancer | Under [30 s] | Quarterly instance failure test |
| Dedicated link (Example) | Fibre cut, device or location failure | Two links in two locations per data centre (section 6) | BGP with BFD, under [5 s] | Provider failover test twice a year |
| Region hub (Example) | Regional outage | Region 2 hub serves DR spokes; on-premises routes re-converge to HYB-003 and HYB-004 | Per DR runbook | Yearly DR exercise |
| DNS resolver (Example) | Endpoint failure | Two IP addresses per endpoint across zones; on-premises forwarders list both | Client retry | Quarterly |
| Egress NAT (Example) | Zone failure | NAT per zone with zone-local routes | Under [60 s] | Quarterly |
| [Component] | [Failure] | [Design] | [Time] | [Test] |
Link these tests to the Disaster Recovery Plan (ops/disaster-recovery-plan)
and to resilience tiers in the Resilience Tiering and HA/DR Design
(architecture/resilience-tiering-ha-dr-design).
12. Monitoring and operations
| Signal | Source | Threshold or use | Destination |
|---|
| Hybrid link state and BGP sessions (Example) | Provider metrics | Alert on any session down | Network on-call |
| Link utilisation (Example) | Provider metrics | Alert above 50 % for 15 minutes (planning limit in section 6) | Network on-call, capacity review |
| Firewall throughput and drops (Example) | Firewall metrics | Alert on 70 % of SKU capacity | Network on-call |
| Flow logs (Example) | Hub and regulated spokes | Retained [90 days], queried for investigations | Central log store |
| DNS query logs (Example) | Resolvers | Security analytics | Security operations |
| IP utilisation (Example) | IPAM | Alert at 70 % of any pool | Network team |
| Synthetic path tests (Example) | Connection monitoring from on premises to each region | Latency over [5 ms] round trip | Network on-call |
| Operation | Cadence | Owner |
|---|
| Firewall rule review and clean-up (Example) | Quarterly | Security and network |
| Flow register review with workload owners (Example) | Twice a year | Network architect |
| Provider network release review (Example) | Monthly | Network architect |
| Capacity review (Example) | Quarterly, see Capacity Plan (ops/capacity-plan) | Network lead |
13. Security controls and compliance
| Control ID | Control | Implementation | Evidence |
|---|
| NSC-001 (Example) | Deny public IP addresses on workload interfaces except approved ingress | Preventive policy at hierarchy level | Policy compliance report |
| NSC-002 (Example) | Deny public endpoints on managed data services | Preventive policy | Same |
| NSC-003 (Example) | DDoS protection on all public endpoints, including gateways and firewall addresses | Provider DDoS service | Configuration report |
| NSC-004 (Example) | Encryption on hybrid links | MACsec or IPsec where the link type supports it; TLS for all application traffic | Configuration, test record |
| NSC-005 (Example) | Segmentation of regulated scope | Dedicated segment, flows only from FLW register | Quarterly rule-to-register reconciliation |
| NSC-006 (Example) | Administrative ports not exposed to the internet | Detective control, see landing zone guardrails | Posture findings |
| [NSC-NNN] | [Control] | [Implementation] | [Evidence] |
For a regulated scope (for example payment card data), record the
standard and version you are assessed against in the Security
Architecture (security/security-architecture) and keep the network
evidence here current.
14. Implementation, change and risks
14.1 Implementation and change
| Item | Design |
|---|
| Repository (Example) | platform-network: hubs, links, DNS, firewall policy, IPAM pools |
| Pipeline (Example) | Plan on pull request with policy checks; apply on merge inside a change window |
| Rollout order (Example) | Non-production route domain first, then Region 2, then Region 1 |
| Change classes (Example) | Standard (new spoke, new flow), normal (new link, new route domain), major (topology or address plan) |
| Approvals (Example) | Network and security for all; architecture board for major changes, via Change Request (ops/change-request) |
14.2 Risks
| ID | Risk | Likelihood | Impact | Response | Owner |
|---|
| RSK-001 (Example) | Acquired company uses overlapping 10.64.0.0/12 ranges | Medium | High | Reserved 172.16.0.0/12 for NAT; re-addressing plan | @network-architect |
| RSK-002 (Example) | Hub firewall becomes a throughput bottleneck | Medium | Medium | Monitoring at 70 %, direct paths for approved bulk flows | @network-lead |
| RSK-003 (Example) | Both links of data centre A share a carrier duct | Low | High | Carrier path diversity confirmed in writing | @network-lead |
| RSK-004 (Example) | Private endpoint DNS not reachable from a new office | Medium | Medium | Forwarder template in office build checklist | @network-lead |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |
15. Glossary and references
15.1 Glossary
| Term | Meaning |
|---|
| Hub and spoke | Topology where workload networks (spokes) connect through a central network (hub) that holds shared services and inspection |
| Transit | Carrying traffic between two networks through a third |
| Route domain | Set of networks that share one routing table or segment |
| Summarisation | Advertising one larger prefix instead of many smaller ones |
| Private endpoint | Private IP address in your network that reaches a managed service without the internet |
| Conditional forwarding | DNS rule that sends queries for one domain to a specific resolver |
| BGP | Border Gateway Protocol, used for dynamic routing on hybrid links |
| BFD | Bidirectional Forwarding Detection, fast link failure detection |
| IPAM | IP address management tool |
| ULA | Unique local IPv6 address (RFC 4193) |
15.2 References
| Reference | Version or date checked | Use |
|---|
| RFC 1918, Address Allocation for Private Internets (BCP 5), rfc-editor.org | February 1996 | Private IPv4 ranges |
| RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space (BCP 153) | April 2012 | 100.64.0.0/10 rules |
| RFC 4193, Unique Local IPv6 Unicast Addresses | October 2005 | IPv6 internal ranges |
| AWS whitepaper, Building a Scalable and Secure Multi-VPC AWS Network Infrastructure, docs.aws.amazon.com | Published April 2024 | Transit, inspection, DNS and IPAM practices |
| AWS Cloud WAN, What is AWS Cloud WAN, docs.aws.amazon.com | Current web edition | Provider-managed WAN concepts |
| AWS Direct Connect, Resiliency Toolkit, docs.aws.amazon.com | Current web edition | Section 6 |
| Amazon VPC User Guide, VPC CIDR blocks | Current web edition | Address sizes and reserved ranges |
| Route 53 VPC Resolver, docs.aws.amazon.com | Current web edition | Section 7 |
| Azure Architecture Center, Hub-spoke network topology in Azure, learn.microsoft.com | Page dated April 2026 | Hub design, subnet sizes, spoke connectivity |
| Azure Virtual WAN overview, learn.microsoft.com | Page dated March 2025 | Provider-managed hub option |
| Design and architect Azure ExpressRoute for resiliency, learn.microsoft.com | Page dated March 2026 | Section 6 |
| Azure DNS Private Resolver overview, learn.microsoft.com | Page dated June 2026 | Section 7, subnet sizes |
| Google Cloud, Network Connectivity Center overview, docs.cloud.google.com | Page updated October 2026 | Hub and spoke types |
| Google Cloud, Shared VPC, docs.cloud.google.com | Page updated October 2026 | Shared network model |
| Google Cloud, Establish 99.99 % availability for Dedicated Interconnect | Page updated October 2026 | Section 6 |
| Google Cloud, Private Service Connect | Page updated October 2026 | Section 10 |
Standard and licence note
Based on RFC 1918, RFC 6598 and RFC 4193 for address planning, with
structure aligned with the reference network topologies published by
AWS, Microsoft and Google Cloud. Provider product names, resilience
model names and subnet sizing rules are cited for mapping only and must
be checked against current documentation, because limits and features
change often. All text, tables and examples are original and were
written for this collection; no provider text or diagram is reproduced.
AWS, Microsoft Azure, Google Cloud and the products named are
trademarks of their owners; this template is not affiliated with or
endorsed by them. Template licence: MIT.