Hybrid Networks

Hybrid networks combine on-premises and cloud infrastructure. Learn how to plan hybrid address space, prevent CIDR overlap, reconcile planned-vs-live state, and govern IP assignments across environments with LightMesh IPAM.

Hybrid networks combine on-premises infrastructure with cloud providers. A typical estate includes a data centre, branch offices, AWS VPCs, Azure VNets, and connectivity via Direct Connect, ExpressRoute, VPN, or internet. The core challenge is maintaining a single source of address truth across all environments.

LightMesh provides a unified view of address space across on-prem, AWS, and Azure. It syncs read-only from cloud accounts, documents planned allocations, and detects drift between planned and live state. LightMesh does not push VPC, VNet, route, or security group changes. It is a documentation and planning layer, not a control plane.

For OT-specific hybrid scenarios, see OT Networks. For industry applications, see Water & Wastewater, Manufacturing, and Utilities & Energy.

Why hybrid networks matter

Cloud adoption added to on-premises infrastructure, not replaced it. Most organisations operate a mix of data centres, branch offices, AWS accounts, and Azure subscriptions, each with its own address space, ownership model, and change process. Without a unified view, address planning becomes guesswork.

The cost of address conflicts in a hybrid environment is high. Overlapping CIDR blocks prevent VPC/VNet peering, delay cloud migrations, and force emergency renumbering during incidents. M&A activity compounds the problem: acquired companies bring their own address space, often with overlapping RFC1918 ranges that were never designed to coexist.

Public IP scarcity adds another dimension. AWS charges for IPv4 addresses on EC2 instances and NAT gateways. Organisations need visibility into public IP usage across cloud accounts to manage costs and plan IPv6 adoption. Without a single view, public IP allocation becomes fragmented across teams and accounts.

Common hybrid architecture

flowchart TB
  subgraph OnPrem["On-Premises"]
    DC["Data Centre"]
    Branch["Branch Offices"]
  end
  subgraph AWS["AWS"]
    VPC1["VPC - Production"]
    VPC2["VPC - Non-Production"]
    VPC3["VPC - Shared Services"]
  end
  subgraph Azure["Azure"]
    VNet1["VNet - Production"]
    VNet2["VNet - Dev/Test"]
  end
  DC -->|"Direct Connect"| VPC1
  DC -->|"ExpressRoute"| VNet1
  Branch -->|"VPN"| VPC1
  VPC1 <-->|"VPC Peering"| VPC3
  VNet1 <-->|"VNet Peering"| VNet2
  VPC3 <-->|"Transit"| VNet1

LightMesh sits above this topology as the IPAM authority. It reads cloud account state via AWS integration and Azure integration, documents on-prem allocations via import or DHCP discovery, and provides the single view that makes address planning possible.

Common operational challenges

  • Overlapping CIDR blocks across cloud and on-prem. Teams provision cloud networks independently, often reusing RFC1918 ranges that conflict with on-prem allocations. By the time the overlap is discovered, multiple VPCs or VNets are live.

  • No single view across AWS, Azure, and on-prem. Cloud accounts are managed by platform teams. On-prem is managed by network teams. Neither has visibility into the other’s address space.

  • Planned vs. live drift. A subnet is reserved in LightMesh, but the provisioning pipeline creates a different CIDR. Or a cloud VPC is deleted but the reservation is never released. Over time, planned state diverges from live state.

  • M&A address integration. Acquired companies bring overlapping RFC1918 ranges. Rationalizing address space across merged estates takes months and requires a clear view of what exists, what is in use, and what can be retired.

  • Public IP cost and scarcity. AWS charges $0.005/hr per IPv4 address on most EC2 instances. A single account with 50 EIPs costs ~$180/month. Organisations need visibility into public IP usage to manage costs and plan IPv6 transitions.

  • Ownership ambiguity. In hybrid environments, address ownership spans network teams, platform teams, application teams, and DevOps. Without clear ownership records, incident response requires phone calls to identify who owns a given IP.

  • Terraform drift. Infrastructure-as-Code pipelines hard-code CIDRs in Terraform variables. When plans change, the code does not update automatically. The result is planned state in Terraform that diverges from actual state in cloud accounts.

How LightMesh helps

Unified multi-cloud and on-prem view

LightMesh syncs AWS and Azure accounts read-only, pulling VPCs, VNets, subnets, IP assignments, and resource metadata into a single search. On-prem address space is imported via spreadsheet, DHCP discovery, or nmap scan sync.

The result is one place to answer: “What is using 10.0.1.0/24?”, across every environment, every account, every team.

Cross-environment visibility

Model physical locations (data centres, branches) as Sites and logical network areas (on-prem VLANs, AWS VPCs, Azure VNets) as Zones. Use Network Containers as a view feature to group similar subnets across environments for visibility, not as a modelling primitive:

Network Container Purpose
On-Prem DC Data centre subnets
AWS Production Production VPC subnets
AWS Non-Production Dev/test/staging VPC subnets
Azure Production Production VNet subnets
Branch Branch office subnets
Acquired Estate Pre-rationalization acquired subnets

Custom attributes on Zones and Subnets capture ownership, environment, and cost centre metadata.

Planned-vs-live reconciliation

Compare planned allocations in LightMesh against live state from cloud sync and DHCP discovery. Before any migration or peering exercise, review:

  • Planned subnets with no live resources (candidates for release)
  • Live subnets with no planned allocation (documentation gaps)
  • Overlaps detected between planned ranges in different environments
  • Stale reservations past their expiry date

This workflow is described in Getting Started.

Subnet planning and overlap prevention

Use the visual planner and TreeView to design address space before provisioning. LightMesh checks cross-environment overlap: if you plan a 10.0.1.0/24 in AWS Production, LightMesh flags it if 10.0.1.0/24 is already allocated in On-Prem DC.

Reserve before you provision. The reservation is the source of truth. The Terraform variable should reference the reserved CIDR, not the other way around.

NAT documentation across environments

Document NAT rules at the IP level (SNAT, DNAT, and static NAT) across on-prem firewalls, AWS NAT gateways, and Azure NAT gateways. When the SOC asks “what is behind 203.0.113.5?”, LightMesh answers in seconds.

API and CLI for IaC integration

Use the GraphQL API and lightmesh CLI to integrate address planning into Terraform pipelines:

export LIGHTMESH_API_TOKEN="your-token"
lightmesh subnet list --json | jq '.[].networkAddress'

Reserve an IP programmatically before Terraform provisions a resource. This keeps planned state in LightMesh aligned with live state in cloud accounts.

Best practices

  1. Design from top down. Start with Sites (physical locations) and cloud accounts, then Zones (functional areas), then subnets. Top-down design prevents overlap and makes ownership clear.

  2. Sync cloud accounts early. Connect AWS and Azure before importing on-prem. Discovering existing cloud state first prevents planning around gaps.

  3. Reserve before you provision. Every CIDR should have a reservation in LightMesh before it appears in Terraform or a cloud console. Reservation is the planning step; provisioning is the execution step.

  4. Review drift weekly. Run planned-vs-live reconciliation at least weekly. Catching drift early prevents cascading issues during migrations and peering exercises.

  5. Document NAT in IPAM, not just firewalls. NAT rules on firewalls are hard to search during incidents. LightMesh NAT records are searchable and attributed.

  6. Use custom attributes for ownership. Assign an owner, cost centre, and environment to every subnet. When the SOC calls, the answer should be in the IPAM, not in a phone call.

  7. Import acquired estates as separate Sites or Zones. Do not mix acquired address space into production zones. Model it separately, identify overlaps, and rationalize before merging.

  8. Separate provider-owned and customer-owned ranges. Some cloud providers reserve address ranges for their own infrastructure (e.g., AWS DNS, Azure infrastructure). Document these separately from your allocated space.

What LightMesh does not do

LightMesh is a read-only source of network intelligence. It does not:

  • Push VPC, VNet, route table, or security group changes. LightMesh documents address space and provides planning tools. It does not modify cloud infrastructure.

  • Replace native cloud tools. AWS VPC Manager, Azure Network Watcher, and Terraform are the tools that manage cloud resources. LightMesh complements them with cross-environment visibility.

  • Execute Terraform. LightMesh provides an API and CLI for address planning. Terraform execution remains in your CI/CD pipeline.

  • Manage DNS as authoritative. LightMesh documents DNS entries and links them to IP assignments. It is not an authoritative DNS server.

  • Guarantee connectivity. LightMesh documents address space and planned allocations. Network reachability depends on routing, firewall rules, and cloud configuration, not IPAM.

FAQ

What is a hybrid network? A hybrid network combines on-premises infrastructure (data centres, branches) with cloud providers (AWS VPCs, Azure VNets). The challenge is maintaining a single source of address truth across all environments, each with its own ownership model and change process.

How does LightMesh sync with AWS and Azure? LightMesh connects to AWS via IAM role and to Azure via service principal. It reads VPCs, VNets, subnets, IP assignments, and resource metadata on a configurable schedule (Enterprise: 5 min, Pro/Team: 60 min, Free: on-demand). All sync is read-only. LightMesh does not modify cloud resources.

Can LightMesh prevent CIDR overlap across cloud and on-prem? Yes. LightMesh checks cross-environment overlap when you plan new subnets. If a planned CIDR conflicts with an existing allocation in another environment (on-prem, AWS, or Azure), LightMesh flags the overlap before you provision.

Does LightMesh write changes to my cloud infrastructure? No. LightMesh is a read-only source of network intelligence. It documents address space and provides planning tools. It does not modify VPCs, VNets, route tables, security groups, or any cloud resources.

How do I handle overlapping RFC1918 from an acquisition? Model the acquired estate as a separate Site or Zone. Identify overlaps between the acquired and existing address space. Plan a rationalization strategy (renumbering, NAT, or segmentation) before merging into production zones. LightMesh Data Migration workflows support phased rationalization.

Can I use LightMesh with Terraform? Yes. Use the GraphQL API or lightmesh CLI to query and reserve address space programmatically. Your Terraform pipeline can reserve a CIDR in LightMesh before provisioning it in cloud infrastructure, keeping planned and live state aligned.

What is planned-vs-live reconciliation? Planned-vs-live reconciliation compares what LightMesh says should be in use (reservations, planned subnets) against what cloud sync and DHCP discovery report as actually in use. Gaps indicate documentation drift: subnets that exist but are not planned, or reservations that are no longer live.

Can LightMesh track NAT across hybrid environments? Yes. LightMesh NAT records document SNAT, DNAT, and static NAT rules at the IP level. You can record NAT mappings across on-prem firewalls, AWS NAT gateways, and Azure NAT gateways. During incident response, search the translated IP to find the original source.

References

Next