Devops Network Calculator For Azure

Azure Network Calculator

Offline Azure network planning tool. Calculates CIDRs, detects overlaps, analyzes VNet utilization, plans AKS networking, and generates Terraform-ready output. Zero external dependencies — uses Python stdlib only.

Quick Start

# What CIDR do I need for 500 hosts?
python3 scripts/network-calc.py calculate --from-hosts 500

# Analyze current VNet
python3 scripts/network-calc.py analyze --from-tfvars terraform/terraform.tfvars

# Validate for overlaps (pre-commit compatible)
python3 scripts/network-calc.py validate --from-tfvars terraform/terraform.tfvars

# Find where to place a new subnet
python3 scripts/network-calc.py first-fit --vnet 10.248.0.0/20 \
  --subnets "10.248.0.0/22,10.248.4.0/22,10.248.8.0/26,10.248.9.0/24" --hosts 500

Commands

Project Context

This project's current VNet: 10.248.0.0/20 (4,096 IPs, 57.8% utilized)

Key files: terraform/terraform.tfvars, terraform/networking.tf, terraform/nsg.tf

Azure Quick Reference

• 5 reserved IPs per subnet (.0, .1, .2, .3, broadcast)
• Bastion: min /26 | Gateway: min /27 | Firewall: min /26
• Max subnets/VNet: 3,000 | Max NSG rules: 1,000
• Full reference: Azure Constraints

Reference Guides

Templates

Execution

Follow the instructions in ./workflow.md.

---

Gotchas

• Azure reserves 5 IPs per subnet, not 2: A standard /29 gives you 3 usable IPs, not 6. Sizing AKS node pools with /29 starves scaling and surfaces as InsufficientFreeAddressesInSubnet mid-scale.
• GatewaySubnet name is literal: Azure refuses VPN Gateway attach unless the subnet is named exactly GatewaySubnet. Same for AzureBastionSubnet and AzureFirewallSubnet. Typo breaks at apply, not plan.
• AKS Azure CNI eats one subnet IP per pod: A 30-node cluster at 30 pods/node needs 900+ subnet IPs, not 30. Plan --max-pods first; switching CNI later requires cluster rebuild.
• first-fit picks lowest gap, not smartest: Places a /24 in a /22 gap and leaves fragmented unusable /25 leftovers. For long-lived VNets, use plan-multi and reserve growth gaps explicitly.
• CIDR overlap with on-prem fails silently until peering: A 10.0.0.0/16 VNet looks fine alone, but ExpressRoute peering black-holes routes overlapping corporate ranges. Validate against full corporate IPAM.
• NSG rule limit is 1,000 total, not per-direction: Inbound + outbound + default + Azure-auto rules share the budget. Leave headroom or hit a hard wall during scale.

AKS Networking Guide

Comprehensive reference for Azure Kubernetes Service networking models, subnet sizing, and integration with Azure VNets.

CNI Comparison Matrix

Node Subnet Sizing Formulas

Azure CNI (VNet-Allocated Pod IPs)

Every pod gets a real VNet IP. This is the most IP-hungry model.

required_IPs = (max_pods_per_node + 1) * node_count + reserved(5)

Default max_pods_per_node = 30, so:

required_IPs = 31 * node_count + 5

Kubenet (NAT Bridge)

Only node IPs come from the VNet. Pods use a private 10.244.0.0/16 overlay.

required_IPs = node_count + 5

CNI Overlay / CNI + Cilium

Like Kubenet for node IPs -- only nodes consume VNet addresses. Pods get overlay IPs.

required_IPs = node_count + 5

Same table as Kubenet, but with higher max_pods_per_node (250 vs 110) and no UDR requirement.

Pod CIDR Planning

The pod CIDR defines the address space for pod IPs in overlay models (Kubenet, CNI Overlay, CNI + Cilium).

Defaults

Sizing the Pod CIDR

pod_cidr_size = nodes * (2^(32 - per_node_prefix))

With default /24 per node:

• 256 nodes need 256 * 256 = 65,536 IPs = /16
• 512 nodes need a /15
• 1,000 nodes need a /14

Overlap Rules

• Pod CIDR must not overlap with:
• VNet address space (e.g., 10.248.0.0/20)
• Service CIDR
• Docker bridge CIDR (172.17.0.0/16 by default)
• Any peered VNet address space
• Pod CIDR can overlap with:
• Pod CIDRs in other, non-peered clusters (they are isolated)
• The default 10.244.0.0/16 is safe for this project's 10.248.0.0/20 VNet (no overlap)

Service CIDR Planning

The service CIDR provides ClusterIP addresses for Kubernetes services.

Defaults

Rules

• Service CIDR must not overlap with VNet address space, pod CIDR, or peered networks
• DNS service IP must be within the service CIDR but not the first IP (network address)
• By convention, DNS IP is at the .10 offset (e.g., 10.0.0.10 for 10.0.0.0/16)
• A /16 supports 65,531 services (far exceeding most cluster needs)
• For smaller clusters, /20 (4,091 services) is sufficient

Recommended Values for This Project

Private AKS Cluster Requirements

A private AKS cluster exposes the API server only via a private endpoint inside the VNet.

Mandatory Components

1. Private DNS Zone for the API server

• Zone name: privatelink.<region>.azmk8s.io
• Must be linked to the VNet where the cluster lives
• Must be linked to any VNet that needs to resolve the API server (e.g., CI/CD agents)

2. VNet Link from the private DNS zone to the cluster VNet

• Auto-registration not required (AKS manages the A record)
• Additional VNet links needed for hub VNets in hub-spoke topologies

3. No Public API Endpoint

• public_network_access_enabled = false
• API server accessible only from within the VNet or via peered/VPN-connected networks
• CI/CD pipelines must run from within the network (self-hosted agents, Bastion, VPN)

Network Flow for Private AKS

Developer/CI Agent
  └─> VPN / Bastion / Private Network
       └─> Private Endpoint (10.248.x.x)
            └─> AKS API Server
                 └─> Node Pool (VNet subnet)
                      └─> Pods (overlay or VNet IPs)

Terraform Configuration Pattern

resource "azurerm_kubernetes_cluster" "aks" {
  private_cluster_enabled       = true
  public_network_access_enabled = false
  private_dns_zone_id           = azurerm_private_dns_zone.aks.id

  network_profile {
    network_plugin      = "azure"    # or "none" for CNI Overlay
    network_plugin_mode = "overlay"  # for CNI Overlay
    pod_cidr            = "10.244.0.0/16"
    service_cidr        = "10.245.0.0/16"
    dns_service_ip      = "10.245.0.10"
  }
}

AKS-Specific NSG Rules

Required Outbound Rules

Required Inbound Rules

Service Tags for AKS

Integration with This Project (10.248.0.0/20)

Available Space for AKS

Based on current allocation analysis:

VNet: 10.248.0.0/20 (4,096 IPs total)

Currently allocated:
  GatewaySubnet:      10.248.0.0/22   (1,024 IPs)
  PublicSubnet:        10.248.4.0/22   (1,024 IPs)
  AzureBastionSubnet: 10.248.8.0/26   (64 IPs)
  PrivateSubnet:      10.248.9.0/24   (256 IPs)

Best fit for AKS: 10.248.10.0/23 (512 IPs, 507 usable)

What 10.248.10.0/23 Supports

Recommendation for This Project

• CNI Overlay at 10.248.10.0/23 supports up to 507 nodes with 250 pods each
• Pod CIDR: 10.244.0.0/16 (no overlap with 10.248.0.0/20)
• Service CIDR: 10.245.0.0/16 (no overlap)
• DNS Service IP: 10.245.0.10

Sizing Examples

Small Cluster (10 Nodes)

Medium Cluster (50 Nodes)

Large Cluster (100 Nodes)

AKS Anti-Patterns

1. Using Azure CNI When You Do Not Need VNet-Routable Pods

Azure CNI consumes one VNet IP per pod. A 100-node cluster with 30 pods/node needs 3,105 IPs. CNI Overlay needs 105. Unless you require pods to be directly addressable from the VNet (e.g., legacy integration), use CNI Overlay.

2. Undersizing the Node Subnet

Leaving no room for node pool scaling causes autoscaler failures. Always size for 2x expected peak nodes.

3. Overlapping Pod CIDR with VNet or Peered Networks

The cluster will fail to deploy or pods will have unreachable IPs. Validate all CIDRs with network-calc.py validate before applying.

4. Using Kubenet for Production

Kubenet requires manual UDR management, has lower max pod counts (110), does not support Windows nodes, and lacks dual-stack. Use CNI Overlay instead.

5. Public API Server in Production

Exposing the API server to the internet is a critical security risk. Always use private clusters for production.

6. Hardcoding Service Tag IPs

Azure service tag IP ranges change. Always use service tags (e.g., AzureCloud) in NSG rules rather than hardcoded IP addresses.

7. Ignoring Cluster DNS Resolution

Private clusters need DNS resolution for the API server. Without a properly linked private DNS zone, kubectl commands fail from outside the cluster VNet.

8. Single Subnet for Multiple Node Pools

Using one subnet for system and user node pools prevents independent NSG rules and scaling. Use separate subnets for different pool types when security isolation is required.

9. No Egress Control

Allowing unrestricted outbound from AKS nodes is a data exfiltration risk. Use NAT Gateway for controlled egress and NSG rules with service tags to restrict destinations.

10. Skipping Network Policy

Running without network policy means any pod can reach any other pod. Enable Calico or Cilium network policy from day one -- retrofitting is painful.

Azure Network Constraints Reference

Quick reference for Azure networking hard limits, reserved addresses, and naming rules.

Reserved IP Addresses Per Subnet

Azure reserves 5 IP addresses in every subnet:

Formula: usable_hosts = 2^(32 - prefix_length) - 5

Usable Hosts by Prefix Length

Minimum Subnet Sizes by Purpose

Azure Resource Limits

Naming Constraints

VNet Peering Constraints

• Address spaces of peered VNets must not overlap
• Peering is non-transitive (A peers B, B peers C does not mean A reaches C without NVA/firewall)
• Hub-spoke requires UDRs or Azure Firewall for spoke-to-spoke traffic
• Maximum 500 peerings per VNet

Private DNS Zone Limits

• 25 linked VNets per private DNS zone (with auto-registration)
• 1,000 linked VNets per private DNS zone (without auto-registration)
• Private AKS clusters require a private DNS zone for the API server

CIDR Calculation Guide

Comprehensive reference for IP address planning in Azure environments.

CIDR Notation Fundamentals

A CIDR block 10.248.0.0/20 means:

• Network address: 10.248.0.0
• Prefix length: /20 (20 bits for network, 12 bits for hosts)
• Total addresses: 2^12 = 4,096
• Subnet mask: 255.255.240.0
• Broadcast: 10.248.15.255
• Usable range: 10.248.0.1 - 10.248.15.254

Subnet Sizing Formula

Given N hosts needed:

min_prefix = 32 - ceil(log2(N + 5))

The +5 accounts for Azure's 5 reserved addresses per subnet.

Growth planning: Always plan for 2x current need. If you need 100 hosts today, plan for 200 (use /24 = 251 usable, not /25 = 123 usable).

Examples

Gap Analysis

To find unallocated space within a VNet: 1. List all subnet CIDRs 2. Sort by network address (ascending) 3. Check for gaps between each subnet's broadcast+1 and the next subnet's network address 4. Report gaps as valid CIDR blocks using summarize_address_range()

Real Example: This Project (10.248.0.0/20)

VNet: 10.248.0.0/20 (4,096 IPs)

Allocated:
  GatewaySubnet:        10.248.0.0/22   (1,024 IPs)
  PublicSubnet:          10.248.4.0/22   (1,024 IPs)
  AzureBastionSubnet:   10.248.8.0/26   (64 IPs)
  PrivateSubnet:         10.248.9.0/24   (256 IPs)
  ─────────────────────────────────────────────
  Total allocated:       2,368 IPs (57.8%)

Gaps (unallocated):
  Gap 1: 10.248.8.64  - 10.248.8.255   (192 IPs)
    = 10.248.8.64/26 + 10.248.8.128/25
  Gap 2: 10.248.10.0  - 10.248.15.255  (1,536 IPs)
    = 10.248.10.0/23 + 10.248.12.0/22
  ─────────────────────────────────────────────
  Total unallocated:     1,728 IPs (42.2%)

Overlap Detection

Two CIDRs overlap when either contains the other's network address.

OVERLAP: 10.248.8.0/24 and 10.248.8.0/26
  10.248.8.0/24 range: 10.248.8.0 - 10.248.8.255
  10.248.8.0/26 range: 10.248.8.0 - 10.248.8.63
  Overlap: 64 IPs in conflict

Python: ipaddress.IPv4Network('10.248.8.0/24').overlaps(IPv4Network('10.248.8.0/26')) returns True.

Address Space Planning Best Practices

RFC 1918 Private Address Ranges

Azure-Specific Ranges to Avoid

Recommended Allocation Strategy

1. Assign a /16 per major site or region (65K IPs) 2. Subdivide into /20 per environment (4K IPs per env) 3. Leave /24 gaps between VNets for future peering 4. Document every allocation in your network address inventory

Subnet Alignment Rules

CIDR blocks must be naturally aligned. A /24 must start on a 256-address boundary, a /22 on a 1024-address boundary, etc.

Alignment formula: network_address % (2^(32 - prefix)) == 0

Common Alignment Mistakes

Supernetting and Summarization

When multiple contiguous subnets can be expressed as a single larger block:

10.248.0.0/24 + 10.248.1.0/24 = 10.248.0.0/23
10.248.0.0/23 + 10.248.2.0/23 = 10.248.0.0/22

Rule: Two adjacent CIDRs of the same size can be summarized only if the first starts on a boundary that is a multiple of the combined size.

Conversion Quick Reference

Using the Calculator Script

# Basic CIDR info
python3 scripts/network-calc.py calculate 10.248.0.0/20

# How many hosts fit in a /23?
python3 scripts/network-calc.py calculate 10.0.0.0/23

# What prefix do I need for 500 hosts?
python3 scripts/network-calc.py calculate --from-hosts 500

# Split a /20 into /22 subnets
python3 scripts/network-calc.py calculate 10.248.0.0/20 --split 22

# Analyze current VNet utilization
python3 scripts/network-calc.py analyze --vnet 10.248.0.0/20 \
  --subnets "10.248.0.0/22,10.248.4.0/22,10.248.8.0/26,10.248.9.0/24"

# Find first available gap for 500 hosts
python3 scripts/network-calc.py first-fit --vnet 10.248.0.0/20 \
  --subnets "10.248.0.0/22,10.248.4.0/22,10.248.8.0/26,10.248.9.0/24" \
  --hosts 500

# Validate for overlaps (pre-commit hook)
python3 scripts/network-calc.py validate --vnet 10.248.0.0/20 \
  --subnets "10.248.0.0/22,10.248.4.0/22,10.248.8.0/26,10.248.9.0/24"

Network Segmentation Patterns

Comprehensive guide to Azure VNet segmentation, NSG design, and subnet architecture.

Hub-Spoke vs Flat VNet

When to Use Hub-Spoke

• Multiple workloads or teams sharing centralized services (firewall, DNS, VPN)
• Spoke-to-spoke traffic must be inspected or filtered
• Separate billing or RBAC per spoke
• Multiple environments (dev/staging/prod) sharing a single egress point
• Enterprise environments with 5+ VNets

When to Use Flat VNet (Single VNet)

• Single-purpose infrastructure (this project)
• All subnets serve one workload or one environment
• No spoke-to-spoke routing requirements
• Simpler operations and lower cost (no NVA/firewall required)
• Fewer than 5 distinct network segments

This Project Uses Flat VNet -- Correctly

The project deploys a single /20 VNet with 4 subnets serving one environment. There is no cross-workload routing requirement, no shared services hub, and no multi-team isolation need. A hub-spoke topology would add unnecessary Azure Firewall cost (~$1,000/mo) and operational complexity for zero security benefit.

Subnet Purpose Isolation

Each subnet should serve exactly one purpose. Mixing purposes defeats NSG isolation.

Standard Subnet Taxonomy

Isolation Principles

1. Gateway never mixes with workloads -- GatewaySubnet has Azure-imposed restrictions (no NSG, no UDR) 2. Bastion is always isolated -- its NSG rules are unique and must not leak to other subnets 3. Public and private are always separate -- different inbound exposure profiles 4. Data tier is behind private -- databases should never be in the same subnet as app servers 5. AKS gets its own subnet -- node autoscaling can consume unpredictable IPs

NSG Rule Design Patterns

Priority Spacing

Always space priorities by 10 to allow future insertions:

100  AllowHTTPS
110  AllowHTTP
120  AllowSSHFromBastion
...
4000 DenyAllInbound

Avoid using consecutive priorities (100, 101, 102) -- inserting a rule between them requires renumbering.

Least Privilege Template

Inbound Rules:
  100  Allow [specific source] to [specific port] TCP
  110  Allow [specific source] to [specific port] TCP
  ...
  4000 DenyAllInbound    ← explicit deny-all catchall

Outbound Rules:
  100  Allow [service tag] on [specific port] TCP
  110  Allow [service tag] on [specific port] TCP
  ...
  4000 DenyAllOutbound   ← explicit deny-all catchall

Service Tag Usage

Always prefer service tags over IP addresses:

NSG Per Subnet, Not Per NIC

Associate NSGs at the subnet level, not individual NICs. Per-NIC NSGs create management complexity and make it easy to miss a VM.

Bastion Subnet NSG Pattern

Inbound:
  100  Allow Internet      → 443/TCP    (Bastion portal access)
  110  Allow GatewayManager → 443/TCP   (Azure management)
  120  Allow AzureLoadBalancer → 443/TCP (Health probes)
  130  Allow VirtualNetwork → 8080,5701/TCP (Bastion data plane)
  4000 DenyAllInbound

Outbound:
  100  Allow VirtualNetwork → 22/TCP    (SSH to targets)
  110  Allow VirtualNetwork → 3389/TCP  (RDP to targets)
  120  Allow AzureCloud     → 443/TCP   (Azure diagnostics)
  130  Allow VirtualNetwork → 8080,5701/TCP (Bastion data plane)
  4000 DenyAllOutbound

Private Subnet NSG Pattern

Inbound:
  100  Allow VirtualNetwork → 443/TCP   (Internal HTTPS)
  110  Allow VirtualNetwork → 22/TCP    (SSH from Bastion)
  4000 DenyAllInbound

Outbound:
  100  Allow AzureCloud     → 443/TCP   (Azure services)
  110  Allow Internet       → 443/TCP   (Package repos, APIs)
  120  Allow VirtualNetwork → 1433/TCP  (SQL to DataSubnet)
  4000 DenyAllOutbound

NAT Gateway Placement

Where to Associate NAT Gateway

NAT Gateway Sizing

• 1 NAT GW supports up to 64,000 concurrent SNAT connections per public IP
• Assign 1-16 public IPs per NAT GW
• Each public IP adds 64,000 SNAT connections
• A single NAT GW can serve multiple subnets in the same VNet

Service Endpoint vs Private Endpoint

Decision Matrix

When to Use Service Endpoints

• Budget-constrained environments
• Single-VNet deployments with no hybrid connectivity
• Services that only need VNet-to-Azure-service access
• Quick wins: Storage, SQL, Key Vault, Cosmos DB

When to Use Private Endpoints

• Regulatory requirements for private connectivity
• Hybrid environments (on-prem needs access)
• Multi-VNet architectures (hub-spoke)
• Data exfiltration prevention is a requirement
• Services not supported by service endpoints

This Project's Approach

Service endpoints are appropriate because:

• Single VNet deployment (no cross-VNet access needed)
• No hybrid/on-premises connectivity requirement
• Cost optimization (no per-endpoint charges)
• Simpler DNS (no private DNS zones to manage)

Anti-Patterns

1. 0.0.0.0/0 Ingress on Any Rule Except Bastion HTTPS

Why it is wrong: Opening all internet traffic to any subnet is the most common misconfiguration in Azure. Only AzureBastionSubnet should allow inbound from Internet on port 443.

Fix: Use specific source service tags (VirtualNetwork, AzureLoadBalancer) or source IP ranges. Never use * or 0.0.0.0/0 as source for inbound rules on workload subnets.

2. Wildcard Port Ranges on Inbound Rules

Why it is wrong: * as destination port range allows every port. Attackers scan for open ports and exploit any service they find.

Fix: Specify exact ports (443, 22, 3389) or narrow ranges (8080-8090). If you cannot enumerate the ports, the architecture needs redesign.

3. NSG with No Explicit Deny Rules

Why it is wrong: Azure has an implicit deny at priority 65500, but relying on it means you cannot distinguish "intentionally blocked" from "never considered." Auditors flag this.

Fix: Add explicit DenyAllInbound at priority 4000 and DenyAllOutbound at priority 4000. This documents intent and makes rule ordering visible.

4. Overlapping Subnets

Why it is wrong: Azure rejects overlapping subnets at deployment time, but overlapping CIDRs in Terraform variables cause confusing plan errors.

Fix: Run network-calc.py validate before every terraform plan. Add overlap checks to pre-commit hooks.

5. Bastion Subnet Smaller Than /26

Why it is wrong: Azure requires a minimum /26 (64 IPs) for AzureBastionSubnet. Deployment fails with a cryptic error if undersized.

Fix: Always allocate /26 for Bastion. Do not try to save IPs here.

6. Gateway Subnet Smaller Than /27

Why it is wrong: Azure requires a minimum /27 (32 IPs) for GatewaySubnet. ExpressRoute gateways need /26.

Fix: Allocate /27 minimum, /26 if ExpressRoute is possible in the future.

7. Missing NAT Gateway on Subnets Needing Outbound

Why it is wrong: Without NAT Gateway, VMs use ephemeral SNAT IPs that Azure can reassign. This causes intermittent outbound failures under load and makes IP allow-listing impossible.

Fix: Associate a NAT Gateway with every subnet that needs outbound internet access (public, private, AKS, management).

8. Public IPs on VMs When Bastion Is Available

Why it is wrong: Public IPs expose VMs directly to the internet. Bastion provides authenticated, audited, browser-based access without public IP exposure.

Fix: Remove public IPs from all VMs. Use Bastion for SSH/RDP. Use NAT Gateway for outbound.

9. Flat /16 Without Segmentation

Why it is wrong: A single /16 subnet with all resources has no network isolation. Any compromised VM can reach every other VM on any port.

Fix: Segment into purpose-specific subnets with dedicated NSGs. Even a minimal deployment benefits from gateway/bastion/public/private separation.

10. Hardcoded IPs Instead of Service Tags

Why it is wrong: Azure service IPs change without notice. Hardcoded IPs break when Azure updates its IP ranges, causing outages.

Fix: Always use service tags (AzureCloud, AzureMonitor, Storage, etc.). Azure updates service tag definitions automatically.

This Project's Segmentation Design

Current Layout

10.248.0.0/20 (4,096 IPs)
├── GatewaySubnet        10.248.0.0/22   (1,024 IPs) - VPN termination
├── PublicSubnet          10.248.4.0/22   (1,024 IPs) - Internet-facing, NAT GW
├── AzureBastionSubnet   10.248.8.0/26   (64 IPs)    - Bastion jump host
├── PrivateSubnet         10.248.9.0/24   (256 IPs)   - Backend services, NAT GW
├── [gap]                10.248.8.64/26  (192 IPs)   - Available
└── [gap]                10.248.10.0/23  (1,536 IPs) - Available (AKS candidate)

Why This Design Is Correct

1. Proper isolation: Gateway, Bastion, public, and private subnets are fully separated with independent NSGs 2. Mandatory names honored: GatewaySubnet and AzureBastionSubnet use Azure's required exact names 3. Minimum sizes met: Bastion is /26 (meets /26 minimum), Gateway is /22 (exceeds /27 minimum) 4. NAT Gateway correctly placed: Associated with PublicSubnet and PrivateSubnet, not with GatewaySubnet or Bastion 5. Growth room preserved: 42% of address space (1,728 IPs) remains unallocated for future AKS or additional workloads 6. Flat topology appropriate: Single-purpose infrastructure with no cross-workload routing needs does not benefit from hub-spoke overhead 7. No anti-patterns present: No public IPs on VMs, no wildcard port rules, no overlapping subnets, explicit deny rules in all NSGs

Network Calculator Workflow

Initialization

Detect the user's request type from their input and route to the appropriate action.

Command Dispatch

Calculate (CIDR info, host sizing)

1. Run: python3 ./scripts/network-calc.py calculate <CIDR> or --from-hosts N 2. Present results in a formatted table 3. If --split requested, show all resulting subnets

Analyze (VNet utilization, gaps)

1. Run: python3 ./scripts/network-calc.py analyze --vnet <CIDR> --subnets <list> 2. Or: python3 ./scripts/network-calc.py analyze --from-tfvars <path> 3. Present allocation table, utilization %, and gap analysis 4. Highlight gaps suitable for new workloads (AKS, containers, databases)

Validate (overlap detection, Azure constraints)

1. Run: python3 ./scripts/network-calc.py validate --vnet <CIDR> --subnets <list> 2. Report all violations with severity (CRITICAL, ERROR, WARNING) 3. If valid, confirm with green status 4. Exit code 1 = violations found (compatible with pre-commit hooks)

First-Fit (find optimal subnet placement)

1. Run: python3 ./scripts/network-calc.py first-fit --vnet <CIDR> --subnets <list> --hosts N 2. Returns the optimal CIDR for the requested host count 3. Shows placement within available gaps

Plan AKS Network

1. Read references/aks-networking-guide.md for CNI comparison and sizing formulas 2. Ask user for: CNI type, max nodes, max pods per node 3. Calculate node subnet size, pod CIDR, service CIDR 4. Run first-fit against current VNet to place AKS subnet 5. Generate NSG rules from templates/nsg-rules-aks.tfvars.tpl

Plan Multi-Environment

1. Run: python3 ./scripts/network-calc.py plan-multi --base <CIDR> --envs N --prefix P 2. Present environment allocation table 3. Fill templates/multi-env-plan.md.tpl with results 4. Validate no overlaps between environments

Best Practices Query

Route to the appropriate reference file:

• CIDR math → references/cidr-calculation-guide.md
• AKS networking → references/aks-networking-guide.md
• Segmentation → references/segmentation-patterns.md
• Azure limits → references/azure-constraints.md

Output Rules

• Always present CIDR calculations in structured tables
• When generating Terraform output, follow terraform/variables.tf variable naming
• Always run validate after any calculation before presenting final results
• Include utilization percentage in all analysis outputs

Integration

Users can add these targets to their justfile:

net-calc *ARGS:
    python3 .claude/skills/devops-network-calculator-for-azure/scripts/network-calc.py {{ARGS}}

net-validate:
    python3 .claude/skills/devops-network-calculator-for-azure/scripts/network-calc.py validate --from-tfvars terraform/terraform.tfvars