ARO Subnet Calculator (Azure Red Hat OpenShift)
Planning an Azure Red Hat OpenShift (ARO) cluster requires correct sizing of:
- Master subnet (control plane)
- Worker subnet
- Pod cluster network CIDR (OpenShift cluster network)
Azure reserves 5 IP addresses per subnet, and ARO typically uses separate subnets for control plane and workers.
This calculator helps you determine safe CIDR prefixes for Azure Red Hat OpenShift, including growth headroom and warnings for undersized existing ranges.
Recommended Defaults for ARO Planning
If you’re unsure what values to use, these are safe planning assumptions for many real-world ARO deployments:
Control plane nodes
- Default: 3
- Most production ARO clusters use 3 control plane nodes.
Max pods per worker node
- Conservative planning value: 50
- Many environments run 30–50 pods per node.
- If you’re unsure, use 50 to avoid under-sizing the pod CIDR.
Growth buffer
- Recommended: 20–30%
- Use 25% if you expect workload growth.
- Increase to 40%+ in fast-scaling environments.
Worker subnet sizing rule of thumb
If you expect:
- 20–30 workers → plan at least /24
- 50+ workers → consider /23
- 100+ workers → consider /22
The calculator computes exact minimum prefixes, but these rules help during early VNet design discussions.
How ARO networking works
An ARO cluster commonly uses three distinct address “buckets”:
1) Master subnet (control plane)
- Usually 3 control plane nodes
- Runs core cluster components
- Azure reserves 5 IPs in the subnet
- Extra room is recommended beyond just 3 IPs
2) Worker subnet
- Scales with worker node count
- Azure reserves 5 IPs
- Most common failure point when scaling
3) Pod cluster network CIDR (overlay)
- OpenShift cluster network
- Does NOT consume Azure subnet IPs
- Must be sized based on:
- Worker count
- Max pods per worker
- Growth buffer
This differs from AKS Azure CNI (flat) where pods consume subnet IPs.
What this ARO calculator does
The planner:
- Calculates planned worker nodes
- Applies growth buffer
- Calculates:
- Master subnet CIDR
- Worker subnet CIDR
- Pod cluster network CIDR
- Adds Azure reserved IP impact
- Warns if existing prefixes are too small
How the planner calculates sizing
Worker planning
Planned workers = workers + future growth Buffer factor = 1 + (buffer % / 100)
Worker subnet IP requirement
ceil(plannedWorkers × bufferFactor)
Azure reserved IPs (5) are included when determining usable capacity.
Pod CIDR requirement
ceil(plannedWorkers × maxPodsPerWorker × bufferFactor)
Pods do NOT consume Azure subnet IPs in ARO.
Master subnet requirement
ceil(controlPlaneNodes × bufferFactor)
Azure reserved IPs (5) are included when determining usable capacity.
Example: typical ARO sizing
Scenario
- Control plane: 3 nodes
- Worker nodes: 25
- Max pods per worker: 40
- Buffer: 25%
Expected output
- Master subnet recommendation (small, but safe)
- Worker subnet recommendation sized for growth
- Pod CIDR sized for total potential pod count
- Azure reserved IP impact included
Why correct ARO subnet sizing matters
Common issues:
- Worker subnet exhaustion during scaling
- Under-sized master subnet blocking changes
- Pod CIDR too small → scheduling failures
- Expensive VNet redesign later
Fixing subnet sizing after deployment is disruptive.
ARO vs AKS subnet sizing differences
Many engineers confuse ARO and AKS networking models.
Key differences:
ARO
- Separate master and worker subnets
- Pods use overlay cluster network
- Pods do NOT consume Azure subnet IPs
AKS Azure CNI (flat)
- Nodes and pods share the same subnet
- Pod density directly impacts subnet size
If you are planning AKS instead of ARO, use the dedicated: → AKS Subnet Calculator
For other kubernetes solutions, look at the tool: → Kubernetes Subnet Calculator (AKS, EKS, GKE)
FAQ
How many IPs does Azure reserve per subnet?
Azure reserves 5 IP addresses per subnet.
Do ARO pods consume Azure subnet IPs?
No. Pods use the OpenShift cluster network (overlay CIDR).
What is the most common ARO subnet mistake?
Under-sizing the worker subnet.
Can I resize ARO subnets later?
Subnets are difficult to change after deployment. Plan correctly up front.
Does this calculator replace official documentation?
No. It’s a practical capacity planning tool. Always validate against:
- Your organization’s IP standards
- Microsoft ARO requirements
- OpenShift cluster network design guidance