Cloud Networks

Cloud networks span AWS VPCs, Azure VNets, and GCP VPCs across many accounts and regions. Learn multi-cloud IPAM, landing zone address design, VPC peering overlap prevention, public IPv4 cost control, and IPv6 transition with LightMesh IPAM.

Cloud networks span AWS VPCs, Azure VNets, GCP VPCs, and the connectivity that joins them to on-premises data centres, branches, and edge sites. Each cloud account or subscription owns its own address space, change process, and ownership model. Cloud network IPAM is the practice of planning, governing, and reconciling that address space across all of them from a single source of truth.

LightMesh provides read-only sync from AWS and Azure, documents planned allocations, detects cross-account and cross-cloud overlap, and tracks public IPv4 usage and cost. It does not push VPC, VNet, route table, or security group changes. It is a documentation and planning layer, not a control plane.

This guide covers cloud network architecture, common operational challenges, and practical LightMesh modelling recommendations. For on-premises plus cloud scenarios, see Hybrid Networks. For industry applications, see the Industry Guides.

Why cloud networks matter

Cloud adoption added address space, it did not replace what came before. A mature estate now runs dozens of AWS accounts, several Azure subscriptions, and a growing GCP footprint, each with its own VPCs, VNets, subnets, peering, and transit. Without a unified view, address planning becomes guesswork and overlaps surface during peering or migration, not during design.

Three pressures make cloud IPAM strategic:

  • Peering and transit depend on non-overlapping CIDRs. AWS VPC peering, Azure VNet peering, and Transit Gateway attachments all fail or degrade when CIDR blocks overlap. A team that provisions a 10.0.1.0/24 in a new account without checking the estate blocks peering with the production VPC that already owns that range. The conflict is usually discovered at cutover, when the cost of renumbering is highest.
  • Public IPv4 carries real cost. AWS charges approximately $0.005 per hour per public IPv4 address on EC2 instances, NAT gateways, and Elastic Load Balancers. An account with 50 unused Elastic IPs costs roughly $180 per month, or $2,160 per year, for addresses that do nothing. Azure charges for public IPs on a similar per-hour basis. Without a single view of public IP usage across accounts, cost accumulates invisibly and IPv6 transition stays stalled.
  • Landing zones multiply the surface. AWS Control Tower and Azure landing zones provision new accounts with baseline VPCs. Each new account inherits address space that must fit the existing plan. Spreadsheets and per-account console views do not catch conflicts across the estate.

Cloud teams need a trusted, auditable view of address space that spans every account, every region, and every cloud, with planned-vs-live reconciliation built in.

Common cloud architecture

flowchart TB
  subgraph AWS["AWS Organizations"]
    Core["Core / Shared Services VPC"]
    Prod["Production VPC"]
    NonProd["Non-Production VPC"]
    Sandbox["Sandbox VPC"]
  end
  subgraph Azure["Azure Landing Zone"]
    Hub["Hub VNet"]
    Spoke1["Production Spoke VNet"]
    Spoke2["Dev/Test Spoke VNet"]
  end
  subgraph OnPrem["On-Premises"]
    DC["Data Centre"]
  end
  Core <-->|"Transit Gateway"| Prod
  Core <-->|"Transit Gateway"| NonProd
  Core <-->|"Transit Gateway"| Sandbox
  Hub <-->|"VNet Peering"| Spoke1
  Hub <-->|"VNet Peering"| Spoke2
  DC -->|"Direct Connect"| Core
  DC -->|"ExpressRoute"| Hub
  Core <-->|"Cross-cloud transit"| Hub

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

Common operational challenges

  • Overlapping CIDRs across accounts and clouds. Teams provision VPCs and VNets independently, often reusing the same RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). By the time the overlap is discovered, multiple accounts are live and peering is blocked.

  • No single view across the estate. AWS accounts are managed by platform teams. Azure subscriptions by a different platform team. GCP projects by a third. None has visibility into the others’ address space, and on-prem is invisible to all of them.

  • Public IPv4 cost drift. Elastic IPs, NAT gateway public IPs, and load balancer public IPs accumulate across accounts. Without a consolidated view, unused public IPs stay allocated for months. A single cleanup sweep across 20 accounts often reclaims hundreds of dollars per month.

  • Landing zone sprawl. Each new account or subscription gets a baseline VPC or VNet. Without a central plan, the baseline ranges collide with existing allocations or with future reservations.

  • Terraform and IaC drift. Infrastructure-as-code pipelines hard-code CIDRs in variables. When the central plan changes, the code does not update automatically. Planned state in Terraform diverges from live state in the cloud.

  • Provider-reserved ranges. AWS reserves the first four and last IP of every subnet. Azure reserves five IPs per subnet. Some AWS services (Cloud9, SageMaker) use 172.17.0.0/16 by default and conflict with VPC ranges. Teams that do not track these reservations miscount usable capacity.

  • IPv6 adoption stalls without a plan. IPv6 removes the scarcity pressure that forces careful IPv4 planning, but only if someone tracks which VPCs and VNets have IPv6 enabled and which ranges are assigned. Without IPAM, IPv6 becomes a per-account decision that never scales.

How LightMesh helps

Unified multi-cloud view

LightMesh syncs AWS and Azure accounts read-only, pulling VPCs, VNets, subnets, IP assignments, and resource metadata into a single search. On-prem and GCP 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 account, every cloud, every team.

Landing zone address planning

Model cloud accounts as Sites and VPCs or VNets as Zones. Use Network Containers as a view feature to group similar subnets across accounts for visibility:

Network Container Purpose
AWS Production Production VPC subnets across accounts
AWS Non-Production Dev, test, staging VPC subnets
Azure Production Production VNet subnets
Azure Non-Production Dev/test VNet subnets
Shared Services Core, transit, shared-services VPCs/VNets
On-Prem DC Data centre subnets

Custom attributes on Zones and Subnets capture account ID, subscription ID, environment, owner, cost centre, and application ID.

Cross-account 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 a new AWS account, LightMesh flags it if 10.0.1.0/24 is already allocated in another account, an Azure VNet, or on-prem.

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

Public IPv4 cost tracking

LightMesh documents public IP allocations across synced cloud accounts. Use it to:

  • Identify unused or stale Elastic IPs and public IPs
  • Track public IP count per account, team, or application
  • Plan IPv6 adoption by showing where public IPv4 pressure is highest
  • Support FinOps reviews with ownership and cost attribution

Planned-vs-live reconciliation

Compare planned allocations in LightMesh against live state from cloud sync. Before any peering exercise, migration wave, or landing zone expansion, 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 accounts or clouds
  • Stale reservations past their expiry date

This workflow is described in Getting Started.

API and CLI for IaC integration

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

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

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

Best practices

  1. Design top down. Start with Sites (cloud accounts, subscriptions, regions), then Zones (VPCs, VNets, environments), then subnets. Top-down design prevents overlap and makes ownership clear.

  2. Sync cloud accounts before planning. Connect AWS and Azure before designing new address space. 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. Use a consistent CIDR allocation scheme. Assign a top-level block (for example, 10.0.0.0/16) to each account or subscription, then carve subnets from it. A consistent scheme makes overlap detection reliable and peering safe.

  5. Separate provider-reserved ranges. AWS reserved IPs (first four and last per subnet), Azure reserved IPs (five per subnet), and AWS service defaults like 172.17.0.0/16 should be documented separately from your allocated space to avoid capacity surprises.

  6. Review public IP usage monthly. Run a public IP report across accounts each month. Reclaim unused Elastic IPs and public IPs. Track the savings. Use the data to prioritise IPv6 adoption.

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

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

What LightMesh does not do

LightMesh is a read-only source of network intelligence for cloud environments. 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, Terraform, and CloudFormation manage cloud resources. LightMesh complements them with cross-environment visibility.

  • Execute Terraform or IaC. LightMesh provides an API and CLI for address planning. IaC 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.

  • Bill for public IP usage. LightMesh tracks public IP allocations for cost attribution. Cloud provider invoices remain the source of billing truth.

FAQ

What is a cloud network? A cloud network is the collection of VPCs, VNets, subnets, peering, transit, and connectivity that spans AWS, Azure, GCP, and their links to on-premises. Each cloud account or subscription owns address space that must fit a single estate-wide plan to avoid overlaps and peering failures.

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 AWS accounts? Yes. LightMesh checks cross-account and cross-cloud overlap when you plan new subnets. If a planned CIDR conflicts with an existing allocation in another account, Azure VNet, or on-prem range, 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 does LightMesh help with public IPv4 cost? LightMesh documents public IP allocations across synced cloud accounts. You can identify unused Elastic IPs and public IPs, track usage per account or team, and prioritise IPv6 adoption where public IPv4 pressure is highest. Cloud provider invoices remain the billing source of truth.

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 a cloud landing zone and how does IPAM help? A landing zone is a governed multi-account environment (AWS Control Tower, Azure landing zone) that provisions new accounts with baseline networking. IPAM helps by holding the central address plan, reserving CIDRs for each new account, and detecting overlaps before the account is provisioned.

How do I plan IPv6 adoption across cloud accounts? LightMesh documents which VPCs and VNets have IPv6 enabled and which IPv6 CIDRs are assigned. Use this view to plan a phased IPv6 rollout, track adoption per account or region, and ensure IPv6 ranges do not conflict across peered networks.

References

Previous
Next